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

[Jean-Marc Valin]

>> Consider a device that only has enough ROM to store one set of
>> quantization tables (the limitation could also be about speed, network,
>> ...). If you specify MUST be able to decode, then it means that this
>> device simply *cannot* implement the spec *at all*. This is bad for
>> interoperability.
> 
> For me: device which don't have all mode implemented are already banned:
> the SDP offer/answer model is based on codec and parameter *proposal*:
> still the sender is *allowed* to not send the given mode. That said, UA
> that don't support all modes are already not capable of
> interoperability: they will receive sometimes modes that they do not
> proposed and do not support.

The same reasoning could apply to other codecs as well: if a client
doesn't support G.729, you can't say it's broken if someone unexpectedly
start sending that. Of course, in the case of Speex, we try and do our
best...

> One possible way would be to use "mode=any" to clearly indicate that the
> UA support any modes. The prefered mode could be specified by order of
> preference: "mode=5;mode=any". Other "limited device" would announce all
> modes supported: "mode=5;mode=3;mode=1"

Yes, I agree with that.

> Samples for SDP negotiation must clearly indicates this behaviour:
> 
>    m=audio 8088 RTP/AVP 97
>    a=rtpmap:97 speex/8000
> 
>   -> equivalent to "mode=any"   (for smooth evolution of current
>                                  implementations)

Shouldn't clients have at least a preferred mode? Otherwise, if everyone
says "any", which bit-rate do you choose?

<ship>

> The above would make sense and compliant application would
> be interoperable? right?

I think so.

> That would be perfect for me, and I guess would be fine for you?

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".


>>> The other way would be to make it transparent like g279.
>>
>> Not sure what kind of transparence you mean? The Speex decoder (unless
>> you remove some tables) is able to decode anything without even knowing
>> how it was encoded.
> 
> Except for limited device which are not capable of decoding the "mode"
> that were removed from code ;)
> 
> If I understood well the speex stuff: a decoder without wideband
> implementation would be capable of locating the narrowband part
> of the speex bitstream and return at least narrowband in audio? right?

Actually, if you give wideband data to a narrowband decoder, it will
decode it as narrowband without even *realising* it's wideband (the
wideband bits are transparently ignored).

> Is this possible? (I guess it's not that complex):
> --->wideband data --> NARROW BAND DECODER --> narrow band decoded audio!

yes, that's possible.

> This does not seems possible:
> --->mode=4 nband data --> LIMITED DEVICE    ---> correct nband data
>                           WITH MODE=3 ONLY

That's not possible.

>> If all you mean is "do your best to decode anything you get no matter
>> how different it is from what you asked for", then I agree.
> 
> This has to be at least of recommendation so people are aware that speex
> implementation allow this behavior: it was unclear to people that they
> don't need to set option before starting decode process. Because they
> get a lot of decode failure before, I think speex users are more prepared
> now. Anyway, it's good to inform people.

What do you mean by "they get a lot of decode failure"?

> Sometimes, draft are providing some C code: I would love to see some kind
> of annex with a sample routine to decode speex data.
> 
> Something like: static void dec_process(MSFilter *f)
> http://cvs.savannah.nongnu.org/viewvc/linphone/mediastreamer2/src/msspeex.c?root=linphone&view=markup
> 
> I'm not sure of my implementation (mainly I have a strange behavior of
> "speex_bits_remaining"...)

I'm not really sure I understand your code, but it looks much more
complicated than it should be. Normally, the decode code should look like:

speex_bits_init(&bits);
speex_bits_read_from(&bits, packet, length);
while (1)
{
   err = speex_decode_int(state, bits, out_buffer);
   if (err != 0)
      break;
   play_audio(out_buffer);
}
if (err == -2)
   ms_warning("there was an error decoding");


I see from your code that you use speex_bits_remaining(&bits) but I
can't really understand why. Could you explain?

	Jean-Marc