if the new draft in the manual is used. I don't find how to tell the decoder which mode(NB/WB/UWB) is used in the encoder. The RTP header don't contain the mode field and I don't find the mode information in the coded frame either. Does this mean we have to use NB decoder in all cases? Lianghu On 11/22/06, Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote:> > > > lianghu xu wrote: > > In a word, I don't what's the standard of speex payload format. > > The file doc/rtp.txt is for what? Is it not for rtp payload? > > I find that rtp.txt is more detail that draft02.txt > > > > Which rtp docment should be followed? > > Anyone else has written the RTP wrapper already? > > Oh, I see. doc/rtp.txt was a very, very early draft. See the manual for > a newer one. > > Jean-Marc > > > Lianghu > > > > On 11/22/06, *Jean-Marc Valin* <jean-marc.valin@usherbrooke.ca > > <mailto:jean-marc.valin@usherbrooke.ca>> wrote: > > > > > 1) First, I think there is a bug in libspeex/lsp.c line 512. > > > > > > /* hard limit ak's to +/- 32767 */ > > > if (a < -32767) a =32767; // This line should be changed > to if > > > (a < -32767) a = -32767; > > > if (a > 32767) a = 32767; > > > ak[j-1] = (short)a; > > > > Oops. Thanks for pointing that out. It's fixed in svn. > > > > > 2) About the RTP wrapper for VoIP > > > > > > I'd like to use the payload format defined in the SVN document > rtp.txt > > > as below. > > > > > > What I'm worry about is the interoperability with other > > implementations. > > > > > > What's your opinion on that? > > > > Can you summarize what the issue is? > > > > Jean-Marc > > > > > Best Regards, > > > > > > Lianghu > > > > > > > > > //************************from the SVN /doc/rtp.txt begin > > > *************************************// > > > The Speex RTP payload is defined as a header, followed by any > > number of > > > requests to the remote encoder and all encoded speech frames. > > > > > > +--------+----------+----------------+ > > > | Header | Requests | Speech data... | > > > +--------+----------+----------------+ > > > > > > The header contains only the number of frames sent > > > encoded in 6 bits > > > > > > 0 1 2 3 4 5 > > > +-+-+-+-+-+-+ > > > | NB frames | > > > +-+-+-+-+-+-+ > > > > > > There can be any number of requests of the form > > > > > > 0 1 2 3 4 5 6 7 0 1 > > > +-+-+-+-+-+-+-+-+-+-+ > > > |R| ReqID | ReqVal | > > > +-+-+-+-+-+-+-+-+-+-+ > > > > > > where R is 1 when a request is following and 0 when there is no > more > > > request. Each request (if R=1) is composed of a 4-bit request ID > > (ReqID) and > > > a 5-bit value (ReqVal) > > > > > > Possible values for ReqID are: > > > 0: REQ_PERSIST ReqVal=1 for persistent requests/mode selection, > > > 0 otherwise > > > 1: PERSIST_ACK Acknowledge a REQ_PERSIST from the other end, > > > ReqVal equals the value received > > > 2: MODE Choose the encoder mode directly > > > 3: QUALITY Choose the encoder quality > > > 4: VBR Set VBR on (ReqVal=1) or off (ReqVal=2) > > > 5: VBR_QUALITY Set the encoder quality for VBR mode > > > 6: LOW_MODE Set the encoder mode for low-band (wideband > only) > > > 7: HIGH_MODE Set the encoder mode for high-band (wideband > only) > > > > > > All requests should be considered at the receiver as a suggestion > and > > > compliance is not mandatory. The PERSIST_ACK should be sent upon > > receiving a > > > REQ_PERSIST request to indicate that the request has been > received. > > > > > > The speech data part contains speech frames one after the other. > > The size of > > > the encoded frames can be found since the mode is directly encoded > > into each > > > frame. > > > > > > For example, a frame where we request VBR to be on with quality 8 > > and we > > > transmit two frames encoded at 8.35 kbps (167 bits/frame) will be: > > > > > > 0 1 2 3 > > > 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | NB=2 |1|ReqID=2| ReqVal=0|1|ReqID=3|ReqVal=8 |0| frame 1 | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | frame 1 | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | frame 1 | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | frame 1 | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | frame 1 | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | frame 1 | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |end| frame 2 | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | frame 2 | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | frame 2 | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | frame 2 | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | frame 2 | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | end frame 2 |P|P|P|P|P|P| > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > //************************from the SVN /doc/rtp.txt end > > > *************************************// > > > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/speex-dev/attachments/20061122/d014f781/attachment.html
Jean-Marc Valin
2006-Nov-21 18:52 UTC
[Speex-dev] Re: One bug in the SVN and rtp wrapper issue
There's a field in the SDP description for narrowband/wideband/ultrawideband. Jean-Marc lianghu xu wrote:> if the new draft in the manual is used. I don't find how to tell the > decoder which mode(NB/WB/UWB) is used > in the encoder. The RTP header don't contain the mode field and I don't > find the mode information in the > coded frame either. > > Does this mean we have to use NB decoder in all cases? > > Lianghu > > On 11/22/06, *Jean-Marc Valin* <jean-marc.valin@usherbrooke.ca > <mailto:jean-marc.valin@usherbrooke.ca>> wrote: > > > > lianghu xu wrote: > > In a word, I don't what's the standard of speex payload format. > > The file doc/rtp.txt is for what? Is it not for rtp payload? > > I find that rtp.txt is more detail that draft02.txt > > > > Which rtp docment should be followed? > > Anyone else has written the RTP wrapper already? > > Oh, I see. doc/rtp.txt was a very, very early draft. See the manual for > a newer one. > > Jean-Marc > > > Lianghu > > > > On 11/22/06, *Jean-Marc Valin* <jean-marc.valin@usherbrooke.ca > <mailto:jean-marc.valin@usherbrooke.ca> > > <mailto: jean-marc.valin@usherbrooke.ca > <mailto:jean-marc.valin@usherbrooke.ca>>> wrote: > > > > > 1) First, I think there is a bug in libspeex/lsp.c line 512. > > > > > > /* hard limit ak's to +/- 32767 */ > > > if (a < -32767) a =32767; // This line should be > changed to if > > > (a < -32767) a = -32767; > > > if (a > 32767) a = 32767; > > > ak[j-1] = (short)a; > > > > Oops. Thanks for pointing that out. It's fixed in svn. > > > > > 2) About the RTP wrapper for VoIP > > > > > > I'd like to use the payload format defined in the SVN > document rtp.txt > > > as below. > > > > > > What I'm worry about is the interoperability with other > > implementations. > > > > > > What's your opinion on that? > > > > Can you summarize what the issue is? > > > > Jean-Marc > > > > > Best Regards, > > > > > > Lianghu > > > > > > > > > //************************from the SVN /doc/rtp.txt begin > > > *************************************// > > > The Speex RTP payload is defined as a header, followed by any > > number of > > > requests to the remote encoder and all encoded speech frames. > > > > > > +--------+----------+----------------+ > > > | Header | Requests | Speech data... | > > > +--------+----------+----------------+ > > > > > > The header contains only the number of frames sent > > > encoded in 6 bits > > > > > > 0 1 2 3 4 5 > > > +-+-+-+-+-+-+ > > > | NB frames | > > > +-+-+-+-+-+-+ > > > > > > There can be any number of requests of the form > > > > > > 0 1 2 3 4 5 6 7 0 1 > > > +-+-+-+-+-+-+-+-+-+-+ > > > |R| ReqID | ReqVal | > > > +-+-+-+-+-+-+-+-+-+-+ > > > > > > where R is 1 when a request is following and 0 when there is > no more > > > request. Each request (if R=1) is composed of a 4-bit request ID > > (ReqID) and > > > a 5-bit value (ReqVal) > > > > > > Possible values for ReqID are: > > > 0: REQ_PERSIST ReqVal=1 for persistent requests/mode > selection, > > > 0 otherwise > > > 1: PERSIST_ACK Acknowledge a REQ_PERSIST from the other end, > > > ReqVal equals the value received > > > 2: MODE Choose the encoder mode directly > > > 3: QUALITY Choose the encoder quality > > > 4: VBR Set VBR on (ReqVal=1) or off (ReqVal=2) > > > 5: VBR_QUALITY Set the encoder quality for VBR mode > > > 6: LOW_MODE Set the encoder mode for low-band > (wideband only) > > > 7: HIGH_MODE Set the encoder mode for high-band > (wideband only) > > > > > > All requests should be considered at the receiver as a > suggestion and > > > compliance is not mandatory. The PERSIST_ACK should be sent > upon > > receiving a > > > REQ_PERSIST request to indicate that the request has been > received. > > > > > > The speech data part contains speech frames one after the other. > > The size of > > > the encoded frames can be found since the mode is directly > encoded > > into each > > > frame. > > > > > > For example, a frame where we request VBR to be on with > quality 8 > > and we > > > transmit two frames encoded at 8.35 kbps (167 bits/frame) > will be: > > > > > > 0 1 2 3 > > > 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | NB=2 |1|ReqID=2| ReqVal=0|1|ReqID=3|ReqVal=8 |0| > frame 1 | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | frame > 1 | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | frame > 1 | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | frame > 1 | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | frame > 1 | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | frame > 1 | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |end| frame > 2 | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | frame > 2 | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | frame > 2 | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | frame > 2 | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | frame > 2 | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | end frame 2 |P|P|P|P|P|P| > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > //************************from the SVN /doc/rtp.txt end > > > *************************************// > > > > > >
Does SDP exist defninitely in the VoIP application? Any document on SDP? Lianghu On 11/22/06, Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote:> > There's a field in the SDP description for > narrowband/wideband/ultrawideband. > > Jean-Marc > > lianghu xu wrote: > > if the new draft in the manual is used. I don't find how to tell the > > decoder which mode(NB/WB/UWB) is used > > in the encoder. The RTP header don't contain the mode field and I don't > > find the mode information in the > > coded frame either. > > > > Does this mean we have to use NB decoder in all cases? > > > > Lianghu > > > > On 11/22/06, *Jean-Marc Valin* <jean-marc.valin@usherbrooke.ca > > <mailto:jean-marc.valin@usherbrooke.ca>> wrote: > > > > > > > > lianghu xu wrote: > > > In a word, I don't what's the standard of speex payload format. > > > The file doc/rtp.txt is for what? Is it not for rtp payload? > > > I find that rtp.txt is more detail that draft02.txt > > > > > > Which rtp docment should be followed? > > > Anyone else has written the RTP wrapper already? > > > > Oh, I see. doc/rtp.txt was a very, very early draft. See the manual > for > > a newer one. > > > > Jean-Marc > > > > > Lianghu > > > > > > On 11/22/06, *Jean-Marc Valin* <jean-marc.valin@usherbrooke.ca > > <mailto:jean-marc.valin@usherbrooke.ca> > > > <mailto: jean-marc.valin@usherbrooke.ca > > <mailto:jean-marc.valin@usherbrooke.ca>>> wrote: > > > > > > > 1) First, I think there is a bug in libspeex/lsp.c line > 512. > > > > > > > > /* hard limit ak's to +/- 32767 */ > > > > if (a < -32767) a =32767; // This line should be > > changed to if > > > > (a < -32767) a = -32767; > > > > if (a > 32767) a = 32767; > > > > ak[j-1] = (short)a; > > > > > > Oops. Thanks for pointing that out. It's fixed in svn. > > > > > > > 2) About the RTP wrapper for VoIP > > > > > > > > I'd like to use the payload format defined in the SVN > > document rtp.txt > > > > as below. > > > > > > > > What I'm worry about is the interoperability with other > > > implementations. > > > > > > > > What's your opinion on that? > > > > > > Can you summarize what the issue is? > > > > > > Jean-Marc > > > > > > > Best Regards, > > > > > > > > Lianghu > > > > > > > > > > > > //************************from the SVN /doc/rtp.txt begin > > > > *************************************// > > > > The Speex RTP payload is defined as a header, followed by > any > > > number of > > > > requests to the remote encoder and all encoded speech > frames. > > > > > > > > +--------+----------+----------------+ > > > > | Header | Requests | Speech data... | > > > > +--------+----------+----------------+ > > > > > > > > The header contains only the number of frames sent > > > > encoded in 6 bits > > > > > > > > 0 1 2 3 4 5 > > > > +-+-+-+-+-+-+ > > > > | NB frames | > > > > +-+-+-+-+-+-+ > > > > > > > > There can be any number of requests of the form > > > > > > > > 0 1 2 3 4 5 6 7 0 1 > > > > +-+-+-+-+-+-+-+-+-+-+ > > > > |R| ReqID | ReqVal | > > > > +-+-+-+-+-+-+-+-+-+-+ > > > > > > > > where R is 1 when a request is following and 0 when there is > > no more > > > > request. Each request (if R=1) is composed of a 4-bit > request ID > > > (ReqID) and > > > > a 5-bit value (ReqVal) > > > > > > > > Possible values for ReqID are: > > > > 0: REQ_PERSIST ReqVal=1 for persistent requests/mode > > selection, > > > > 0 otherwise > > > > 1: PERSIST_ACK Acknowledge a REQ_PERSIST from the other > end, > > > > ReqVal equals the value received > > > > 2: MODE Choose the encoder mode directly > > > > 3: QUALITY Choose the encoder quality > > > > 4: VBR Set VBR on (ReqVal=1) or off (ReqVal=2) > > > > 5: VBR_QUALITY Set the encoder quality for VBR mode > > > > 6: LOW_MODE Set the encoder mode for low-band > > (wideband only) > > > > 7: HIGH_MODE Set the encoder mode for high-band > > (wideband only) > > > > > > > > All requests should be considered at the receiver as a > > suggestion and > > > > compliance is not mandatory. The PERSIST_ACK should be sent > > upon > > > receiving a > > > > REQ_PERSIST request to indicate that the request has been > > received. > > > > > > > > The speech data part contains speech frames one after the > other. > > > The size of > > > > the encoded frames can be found since the mode is directly > > encoded > > > into each > > > > frame. > > > > > > > > For example, a frame where we request VBR to be on with > > quality 8 > > > and we > > > > transmit two frames encoded at 8.35 kbps (167 bits/frame) > > will be: > > > > > > > > 0 1 2 3 > > > > 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 > 6 7 > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | NB=2 |1|ReqID=2| ReqVal=0|1|ReqID=3|ReqVal=8 |0| > > frame 1 | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | frame > > 1 | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | frame > > 1 | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | frame > > 1 | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | frame > > 1 | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | frame > > 1 | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > |end| frame > > 2 | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | frame > > 2 | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | frame > > 2 | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | frame > > 2 | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | frame > > 2 | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | end frame 2 |P|P|P|P|P|P| > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > //************************from the SVN /doc/rtp.txt end > > > > *************************************// > > > > > > > > > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/speex-dev/attachments/20061122/1ae498bc/attachment.htm