[Speex-dev] draft-ietf-avt-rtp-speex-01.txt

Jean-Marc Valin jean-marc.valin at usherbrooke.ca
Fri May 18 05:05:50 PDT 2007

>> Yes, I think it's the best compromise -- and actually not very far from
>> what we have now. I would still keep the thing that says 8 kbps SHOULD
>> be supported. Or maybe we can say "all modes SHOULD be supported and if
>> it's not possible, then at least 8 kbps (mode 3) SHOULD be supported".
> I think this is close to be equivalent anyway.

Well, it's got one more thing: the recommendation that if you're only
going to support one mode, it should be mode 3 (8 kbps).

>> What do you mean by "they get a lot of decode failure"?
> Just that implementation was full of bugs.

I'm just thinking one has to be really creative to screw up decoding of
a Speex packet considering that any decoder can decode any packet.

>> I see from your code that you use speex_bits_remaining(&bits) but I
>> can't really understand why. Could you explain?
> I don't know......
> I think that when I implemented this, that helped me to get out the loop.
> It seems that in your code you call "speex_decode_int" one more time
> than me: I tried to call it only when "speex_decode_int" will succeed
> because I though it was bad to call it when there was no data any more.
> It seems I was wrong... Anyway: it's working fine...

It's still a bit weird and theoretically incorrect because you won't be
able to handle null frames (indicating silence/CNG), that are only 5
bits. It probably worked because few (if any) people ever use them.

> Would you mind if I rewrite the draft myself with the idea we discussed?
> Do you have the xml version?

Can you sort that out with Alfred?


More information about the Speex-dev mailing list