Jean-Marc Valin wrote:
>>I believe it is adaptive, but no, I haven't used it, because
it's
>>coupled only to the speex codec. We're working on a generic
>>application and codec-independent jitter buffer algorithm, for use in
>>asterisk and iaxclient (at least). Some information is available at
>>http://www.voip-info.org/tiki-index.php?page=Asterisk%20new%
>>20jitterbuffer
>>
>>
>
>Yes, this jitter buffer is adaptive. There are still some improvements
>left to do (e.g. making sure packets are dropped/interpolated during
>silent periods), but it's already working good.
>
>As for being Speex-dependent, I'd say yes and no. It calls speex_decode,
>which is a Speex "virtual" function, so it would be rather simple
to
>wrap any other codec to make it work like that. If you're interested, I
>can provide help doing that.
>
>
OK, I'm actually about ready to start working on this now.
If people in the speex community are interested in working with me on
this, I can probably start with the speex buffer, but I imagine there's
going to be a lot more work needed to get this where I'd like it to go.
At the API level, It seems pretty easy to make the speex implementation
become speex-independent. Instead of having speex_jitter_get call any
particular speex_decode or speex_read_bits, etc functions, it could
instead just return the "thing" it got, and a flag. I.e.
#define JB_OK 0
#define JB_EMPTY 1
#define JB_NOFRAME 2
#define JB_DROP 3
JB_OK means here's the frame for the timestamp you asked for.
JB_EMPTY means the jitterbuffer is empty, (we just started or whatnot)
JB_NOFRAME means the caller should interpolate a frame
JB_DROP means we'd like you to drop this frame, and try calling us again
with the same timestamp.
We could then have a second-level API wrapper around this for speex
which would then call speex_decode, etc, as necessary.
Basically, I'd like the jitterbuffer to do all the history, length, etc
calculations, but not actually know anything about what it's managing.
In asterisk and iaxclient (my project), the things I'd pass into the
jitterbuffer would be different kinds of structures. Some of these may
be audio frames, some might be control frames (DTMF, etc) that we want
synchronized with the audio stream, etc. In the future, we'd also want
to have video frames thrown in there, which would need to be synchronized.
So, I guess my questions (for Jean-Marc mostly, but others as well):
1) Is it OK with you to add this extra abstraction layer to your jitter
buffer?
2) What's the state of the current implementation: (does it work?)
3) Is there a paper or something that you're using in your design that I
can read.
4) Are people interested in collaborating and contributing to this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/speex-dev/attachments/20041115/0ea0cd03/attachment.html