[Speex-dev] Re: One bug in the SVN and rtp wrapper issue
lianghu xu
lianghu.xu at gmail.com
Tue Nov 21 18:56:40 PST 2006
Does SDP exist defninitely in the VoIP application?
Any document on SDP?
Lianghu
On 11/22/06, Jean-Marc Valin <jean-marc.valin at 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 at usherbrooke.ca
> > <mailto:jean-marc.valin at 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 at usherbrooke.ca
> > <mailto:jean-marc.valin at usherbrooke.ca>
> > > <mailto: 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
> > > > *************************************//
> > >
> > >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/speex-dev/attachments/20061122/1ae498bc/attachment.htm
More information about the Speex-dev
mailing list