[Speex-dev] Re: One bug in the SVN and rtp wrapper issue

Jean-Marc Valin jean-marc.valin at usherbrooke.ca
Tue Nov 21 18:41:09 PST 2006



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 at usherbrooke.ca
> <mailto:jean-marc.valin at 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
>     > *************************************//
> 
> 


More information about the Speex-dev mailing list