Hello to all speex developers,
I have question regarding payload length of narrowband speex in RTP.
I were watching tcpdump of the xlite softphone and have found that
it uses weird payload length namely 75 Bytes
I went through various source and without success.
To be clear:
For 8000Hz sample in 20 ms that is 160 samples per frame.
This makes 50 frames per sec.
modes bit-rate 8 kbit/s (narrowband mode 3) = 20 bytes per frame
11 kbit/s (narrowband mode 4) = 28 bytes per frame
15 kbit/s (narrowband mode 5) = 38 bytes per frame
18,2 kbit/s (narrowband mode 6) = 46 bytes per frame
24,6 kbit/s (narrowband mode 7) = 62 bytes per frame
And for VBR frame size is from a set of {6,11,16,21,29,39}
So, X-lite uses 75 Bytes and this does not look as multiplication of 2
frames.
Additionally, timestamp between consecutive rtp frames is exactly 20ms, so
this implies that this 75 Bytes is only one frame plus maybe bits of
padding.
Can one of you tell me what kind of mode this is?
Thank you in advance.
Pawel
ps. IMHO some kind of table that I've shown should be included in RFC
so in Table 1 in draft-ietf-avt-rtp-speex-03 there should be additional
column.
Namely frame size.
Pawel Cyrta <pawel@cyrta.com <mailto:pawel@cyrta.com>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: apolinaire.vcf
Type: text/x-vcard
Size: 116 bytes
Desc: not available
Url :
http://lists.xiph.org/pipermail/speex-dev/attachments/20070917/d8ddcba0/apolinaire.vcf
Not sure what a payload of 75 bytes could be. Are you sure that doesn't include the 12-byte RTP header? Other than that, maybe it's using wideband (although there's nothing that corresponds exactly to 75 bytes. If you send me the hexdump for one packet, I may be able to find out what it is. Jean-Marc Pawel Cyrta wrote:> Hello to all speex developers, > > I have question regarding payload length of narrowband speex in RTP. > I were watching tcpdump of the xlite softphone and have found that > it uses weird payload length namely 75 Bytes > I went through various source and without success. > > To be clear: > For 8000Hz sample in 20 ms that is 160 samples per frame. > This makes 50 frames per sec. > > modes bit-rate 8 kbit/s (narrowband mode 3) = 20 bytes per frame > 11 kbit/s (narrowband mode 4) = 28 bytes per frame > 15 kbit/s (narrowband mode 5) = 38 bytes per frame > 18,2 kbit/s (narrowband mode 6) = 46 bytes per frame > 24,6 kbit/s (narrowband mode 7) = 62 bytes per frame > > > And for VBR frame size is from a set of {6,11,16,21,29,39} > > So, X-lite uses 75 Bytes and this does not look as multiplication of 2 > frames. > Additionally, timestamp between consecutive rtp frames is exactly 20ms, so > this implies that this 75 Bytes is only one frame plus maybe bits of > padding. > > > Can one of you tell me what kind of mode this is? > > Thank you in advance. > > Pawel > > ps. IMHO some kind of table that I've shown should be included in RFC > so in Table 1 in draft-ietf-avt-rtp-speex-03 there should be additional > column. > Namely frame size. > > > > > Pawel Cyrta <pawel@cyrta.com <mailto:pawel@cyrta.com>> > > _______________________________________________ > Speex-dev mailing list > Speex-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/speex-dev
Hi, (moving back to the list as some bits can be useful to everyone)> I am sure that 75 is the length of payload only.Confirmed> I also don't have idea for the package containing data of a length 46. > > To make everything more clear, Payload type in rtp packages is 97. > SDP defines the stream as > a=rtpmap: 97 SPEEX/8000That's a dynamic payload number, so it doesn't really change anything.> As a attachment I am sending both binary and hexdump: > whole packets (hexdump of packets ip/udp/rtp/data) > speex_payload-length75.txt > speex_payload-length46.txt > binary files with payload of length 75 (only data): > speex_payload-length75.bin > binary files with payload of length 46(only data): > speex_payload-length46.binOK, so I was able to identify the 75-byte and the 46-byte payloads. The 75-byte one actually contains two frames encoded with the 15 kbps mode, while the 46-byte payload is simply one frame encoded with the 18.2 kbps mode. The trick is to look at the first 5 bits in the payload (starting from the MSB). The first one should normally be zero. The next four are the id of the mode being used. In the case of the 75-byte payload, the first byte was "2b", which means the first 5 bits are 00101=5. Mode 5 is 15 kbps. At 15 kbps, each frame is 37.5 bytes. Advancing in the payload by 37.5 bytes, we see another 2b sequence, except that this one is split across two bytes. So that's how you tell the content of a Speex frame. If anyone wants to build that knowledge into wireshark, I'd be willing to help by providing the rest of the knowledge required. Cheers, Jean-Marc> Regards, > Pawel Cyrta > > Jean-Marc Valin pisze: >> Not sure what a payload of 75 bytes could be. Are you sure that doesn't >> include the 12-byte RTP header? Other than that, maybe it's using >> wideband (although there's nothing that corresponds exactly to 75 bytes. >> >> If you send me the hexdump for one packet, I may be able to find out >> what it is. >> >> Jean-Marc >> >> Pawel Cyrta wrote: >> >>> Hello to all speex developers, >>> >>> I have question regarding payload length of narrowband speex in RTP. >>> I were watching tcpdump of the xlite softphone and have found that >>> it uses weird payload length namely 75 Bytes >>> I went through various source and without success. >>> >>> To be clear: >>> For 8000Hz sample in 20 ms that is 160 samples per frame. >>> This makes 50 frames per sec. >>> >>> modes bit-rate 8 kbit/s (narrowband mode 3) = 20 bytes per >>> frame >>> 11 kbit/s (narrowband mode 4) = 28 bytes per frame >>> 15 kbit/s (narrowband mode 5) = 38 bytes per frame >>> 18,2 kbit/s (narrowband mode 6) = 46 bytes per frame >>> 24,6 kbit/s (narrowband mode 7) = 62 bytes per frame >>> >>> >>> And for VBR frame size is from a set of {6,11,16,21,29,39} >>> >>> So, X-lite uses 75 Bytes and this does not look as multiplication of 2 >>> frames. >>> Additionally, timestamp between consecutive rtp frames is exactly >>> 20ms, so >>> this implies that this 75 Bytes is only one frame plus maybe bits of >>> padding. >>> >>> >>> Can one of you tell me what kind of mode this is? >>> >>> Thank you in advance. >>> >>> Pawel >>> >>> ps. IMHO some kind of table that I've shown should be included in RFC >>> so in Table 1 in draft-ietf-avt-rtp-speex-03 there should be additional >>> column. >>> Namely frame size. >>> >>> >>> >>> Pawel Cyrta <pawel@cyrta.com <mailto:pawel@cyrta.com>> >>> >>> _______________________________________________ >>> Speex-dev mailing list >>> Speex-dev@xiph.org >>> http://lists.xiph.org/mailman/listinfo/speex-dev >>> >> >> >> >
Thank you for help.
I have prepared table summarising :
+------+------------------+-------------+------------------------+
| mode | first 5 bit flag | bitrate | frame
size |
+------+------------------+-------------+------------------------+
| 1 | 0 0001 (x8) | 2.15 kbit/s | 43
bits (5.375 Bytes) |
| | | |
|
| 2 | 0 0010 (x10) | 5.95 kbit/s | 119 bits
(14.875 Bytes)|
| | | |
|
| 3 | 0 0011 (x18) | 8.00 kbit/s | 160 bits
(20 Bytes) |
| | | |
|
| 4 | 0 0100 (x20) | 11.0 kbit/s | 220 bits
(27,5 Bytes) |
| | | |
|
| 5 | 0 0101 (x28) | 15.0 kbit/s | 300
bits (37.5 Bytes) |
| | | |
|
| 6 | 0 0110 (x30) | 18.2 kbit/s | 364 bits
(45.5 Bytes) |
| | | |
|
| 7 | 0 0111 (x38) | 24.6 kbit/s | 492
bits (5.375 Bytes) |
| | | |
|
| 8 | 0 1000 (x40) | 3.95 kbit/s | 79 bits
(9.875 Bytes)|
+------+---------------+----------------+------------------------+
*in VBR all of modes from 1 to 7 are possible
>If anyone wants to build that knowledge into wireshark, I'd be willing
>to help by providing the rest of the knowledge required.
What kind effect would like to obtain? A plugin to visualize rtp frame
payload when It is speex?
I think wireshark do not give any visualization for codecs or rtp
payload content.
Pawel
-------------- next part --------------
+------+------------------+-------------+------------------------+
| mode | first 5 bit flag | bitrate | frame size |
+------+------------------+-------------+------------------------+
| 1 | 0 0001 (x8) | 2.15 kbit/s | 43 bits (5.375
Bytes) |
| | | | |
| 2 | 0 0010 (x10) | 5.95 kbit/s | 119 bits (14.875
Bytes)|
| | | | |
| 3 | 0 0011 (x18) | 8.00 kbit/s | 160 bits (20 Bytes)
|
| | | | |
| 4 | 0 0100 (x20) | 11.0 kbit/s | 220 bits (27,5
Bytes) |
| | | | |
| 5 | 0 0101 (x28) | 15.0 kbit/s | 300 bits (37.5
Bytes) |
| | | | |
| 6 | 0 0110 (x30) | 18.2 kbit/s | 364 bits (45.5 Bytes)
|
| | | | |
| 7 | 0 0111 (x38) | 24.6 kbit/s | 492 bits (5.375
Bytes) |
| | | | |
| 8 | 0 1000 (x40) | 3.95 kbit/s | 79 bits (9.875
Bytes)|
+------+---------------+----------------+------------------------+
*in VBR all of modes from 1 to 7 are possible
-------------- next part --------------
A non-text attachment was scrubbed...
Name: apolinaire.vcf
Type: text/x-vcard
Size: 116 bytes
Desc: not available
Url :
http://lists.xiph.org/pipermail/speex-dev/attachments/20070919/dbaa49b8/apolinaire.vcf
I have another question:) What is decoder doing when he will receive the padding bits? e.g.: 39 is the size in bytes of one payload given to decoder in mode 5 (37,5 bytes + padding) Does he recognise the padding bits (by this magic 0 bit and all 1's afterwards)? Or Does decoder produce output with all the bits Pawel -------------- next part -------------- A non-text attachment was scrubbed... Name: apolinaire.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20070919/e29e5fc6/apolinaire.vcf
The way it works is that Speex defines a special mode number 15 (encoded as 01111) that means "this is the end". Also, it knows that no frame can be encoded in less than 5 bits (mode 0, encoded as 00000 means "silence"). That way, the idea is to pad the last byte with a zero, followed (until the byte is complete) with ones. If there are less than 5 padded bits, Speex knows it can't be a real frame. If there are 5 bits or more, it ends up reading the terminator code (mode 15) and knows there's nothing else. That way, you can pack as many frames as you like in one packet and Speex will always be able to tell how many there are. Jean-Marc Pawel Cyrta wrote:> > I have another question:) > > What is decoder doing when he will receive the padding bits? > e.g.: > 39 is the size in bytes of one payload given to decoder in mode 5 (37,5 > bytes + padding) > > Does he recognise the padding bits (by this magic 0 bit and all 1's > afterwards)? > Or > Does decoder produce output with all the bits > > Pawel > > _______________________________________________ > Speex-dev mailing list > Speex-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/speex-dev