Wireshark mailing list archives
Re: G.722 and G.726 decoders for Wireshark
From: Dietfrid Mali <karx11erx () hotmail com>
Date: Wed, 26 Jan 2011 18:24:47 +0100
There are no problems with my implementation of the G.726 decoder. It works fine the way I have delivered it in the bug ticket containing my related patch.
Date: Wed, 26 Jan 2011 17:28:41 +0100 From: jaap.keuter () xs4all nl To: wireshark-dev () wireshark org Subject: Re: [Wireshark-dev] G.722 and G.726 decoders for Wireshark Hi, Well, Wireshark should pick up on SDP negotiations for your RTP stream, and set the correct payload type interpretation. I would have to look at the specific capture file to see what's happening. The fact that "The G.726 decoder function returns twice the number of bytes fed to it as output buffer size" is indeed to cause of your problems. You have decoded from 4 bit (ADPCM) samples to 8 bit (companded PCM) samples, while the player expects 16 bit (linear PCM) samples. So your output size should be four times your input size. Thanks, Jaap On Wed, 26 Jan 2011 09:23:58 +0100, Dietfrid Mali wrote:Yeah, I wasn't expressing this quite right. What I basically wanted to say is that Wireshark doesn't assign a payload type using the SDP but just forwards the payload type given in the RTP packets (102, which Wireshark wraps into a define that basically says "undefined packet type").Date: Wed, 26 Jan 2011 00:09:50 +0100 From: jaap.keuter () xs4all nl To: wireshark-dev () wireshark org Subject: Re: [Wireshark-dev] G.722 and G.726 decoders for Wireshark On 01/25/2011 05:48 PM, Dietfrid Mali wrote:The problem with e.g. G.726 is that Wireshark gives those packetsRTPtype 102 which afaik is an error code ("unknown encoding").No, that's your RTP endpoint configured to label these as such. RFC3550 says:"A profile MAY specify a default static mapping of payload type codesto payloadformats. Additional payload type codes MAY be defined dynamicallythroughnon-RTP means (see Section 3)." RFC 1890/RFC 3551 defines the "RTP Profile for Audio and VideoConferences withMinimal Control", which lists several static payload types. The oldRFC listsG.721 (aka G.726-32), while the new one dropped that one and addedreferences toG.726 at various bit rate, with a dynamic payload type. RFC 3550 says in Section 3: "Non-RTP means: Protocols and mechanismsthat may beneeded in addition to RTP to provide a usable service. In particular,..., anddefine dynamic mappings between RTP payload type values and thepayload formatsthey represent for formats that do not have a predefined payload typevalue."with reference to Session Description Protocol (SDP) So, payload type 102 is a dynamic payload type which has to be givenmeaning(through SDP for instance) within the session. In your case Wiresharkdidn'tpick that up from the trace, hence cannot give you the properinterpretation ofthat payload type within that session.I would need to know where and how Wireshark maps dynamic payloadtypes(negotiated via SDP) to internal static ones. Above that RFC3551notes thatstatic G.726 payload types are obsolete, and afaik there aren'teven(obsolete) static payload types for all G.726 variants, soWiresharkwould need to take care of that by using some (more or less arbitrary) internalstatictype numbers.Yep, that is done by the SDP dissector. It tries to interpret the SDPoffer(should be the answer, but that a whole other story) and createconversations(see doc/README.developer, section 2.2) for the RTP dissector, feedingitdynamic payload type information it has learned from the mediaattributes.The RTP dissector does then the heavy lifting on the RTP packets,based on theinformation feed in by the SDP dissector.I will do my best to provide a patch once I have fully integratedallcodecs (currently only G.726-32 has been implemented as proof of concept, but since this is working adding more is no big deal).Just one to get started is fine. Does it integrate into codecs/directorybesides G711a and G711u (and G729 and G723, if you have them)?Getting G.726 to work was a bit of a pain btw because of the weirdframesync calculation in rtp_player.c::play_channels() as this functionseems toassume 1:1 relationships of decoder input and output stream sizesandthus simply halves the decoder output batch sizes to determinewhetherframes are properly sync'd. This doesn't work for compressed audio. To compensate, my decodeG726_32() function doubles the number ofbytesreturned(as it has a 1:2 relationship of input and output buffer sizes).Beforeit did that, lots of silence frames were inserted and half of theaudiodata was dropped by the player.The G.726 decoder function returns twice the number of bytes fed to it as output buffer size. Just returning that number leads to incorrect audio playback. I had to double that number once more to make it work. This has something to do with how rtp_player() determines whether it has received enough packets for the given time frame and that it inserts silence frames when it thinks it hasn't. There is no (inline) documentation of what rtp_player() expects. Maybe this is described in some Wireshark programming or API documentation?I'm no sure if I understand you correctly. Working with these decodefunctionsthere is an input buffer with its length as input, and two outputparameters,being the output buffer and it a pointer to store its size. This sizeof theoutput buffer has to be set, by the decoder, to the number of samplesin outputbuffer. That should be enough, see for instancertp_player.c:decode_rtp_packet()the handling of G.279 and G.723. Be aware that you have to store 16 bit linear samples in the outputbuffer,maybe that's your factor 2? Thanks, JaapDietfridFrom: jaap.keuter () xs4all nl Date: Tue, 25 Jan 2011 16:54:25 +0100 To: wireshark-dev () wireshark org Subject: Re: [Wireshark-dev] G.722 and G.726 decoders forWiresharkHi, That would be interesting. Can you put the code in a patch onbugzilla?Can't work on it right now, but would be nice to have. btw: their are already static RTP types assigned for bothcodecs.Thedynamic types should come in through protocols like SDP, or adissectorpreference.Thanks, Jaap Send from my iPhone On 25 jan. 2011, at 16:07, Dietfrid Mali wrote:Hi, using spandsp, I have added G.722 and G.726 decoders toWireshark.Currently this is a bit of a hack job, particularly regardinginclusion of the spandsp lib, and I could need a bit help toproperlyintegrate it into Wireshark's automake hell (configure.in).There also isn't a proper Wireshark signature for that RTPtype(Iam simply reacting to RTP type 102, which actually is an errorcode), sosome help getting this straight and introducing proper codec typeswouldbe appreciated, too.___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- G.722 and G.726 decoders for Wireshark Dietfrid Mali (Jan 25)
- Re: G.722 and G.726 decoders for Wireshark Jaap Keuter (Jan 25)
- Re: G.722 and G.726 decoders for Wireshark Dietfrid Mali (Jan 25)
- Re: G.722 and G.726 decoders for Wireshark Jaap Keuter (Jan 25)
- Re: G.722 and G.726 decoders for Wireshark Dietfrid Mali (Jan 26)
- Re: G.722 and G.726 decoders for Wireshark Jaap Keuter (Jan 26)
- Re: G.722 and G.726 decoders for Wireshark Dietfrid Mali (Jan 26)
- Re: G.722 and G.726 decoders for Wireshark Dietfrid Mali (Jan 25)
- Re: G.722 and G.726 decoders for Wireshark Dietfrid Mali (Jan 26)
- Re: G.722 and G.726 decoders for Wireshark Jaap Keuter (Jan 26)
- Re: G.722 and G.726 decoders for Wireshark Kukosa, Tomas (Jan 27)
- Re: G.722 and G.726 decoders for Wireshark Dietfrid Mali (Jan 27)
- Re: G.722 and G.726 decoders for Wireshark Kukosa, Tomas (Jan 27)
- Re: G.722 and G.726 decoders for Wireshark Dietfrid Mali (Jan 27)
- Re: G.722 and G.726 decoders for Wireshark Jaap Keuter (Jan 25)