<div>----draft text:</div>
<div><br>" The encoding and decoding algorithm can change the bit rate at any 20<br> msec frame boundary, with the bit rate change notification provided<br> in-band with the bit stream. Each frame contains both "mode"
<br> (narrowband, wideband or ultra-wideband) and "sub-mode" (bit-rate)<br> information in the bit stream. No out-of-band notification is<br> required for the decoder to process changes in the bit rate sent by
<br> the encoder."</div>
<div> </div>
<div>-----Comment:</div>
<div> </div>
<div>Why not set fields in the payload to indicating mode/sub-mode?</div>
<div> </div>
<div>In the current design, the decoder need to decode the frame to know its mode/sub-mode. </div>
<div>That need time and not acceptable for real time system. Thus, it's not impossible for the decoder to know the mode/sub-mode which can change at any frame boundary.</div>
<div><br> </div>
<div><span class="gmail_quote">On 5/17/07, <b class="gmail_sendername">Aymeric Moizard</b> <<a href="mailto:jack@atosc.org">jack@atosc.org</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><br><br>On Thu, 17 May 2007, Jean-Marc Valin wrote:<br><br>>>> Consider a device that only has enough ROM to store one set of
<br>>>> quantization tables (the limitation could also be about speed, network,<br>>>> ...). If you specify MUST be able to decode, then it means that this<br>>>> device simply *cannot* implement the spec *at all*. This is bad for
<br>>>> interoperability.<br>>><br>>> For me: device which don't have all mode implemented are already banned:<br>>> the SDP offer/answer model is based on codec and parameter *proposal*:<br>
>> still the sender is *allowed* to not send the given mode. That said, UA<br>>> that don't support all modes are already not capable of<br>>> interoperability: they will receive sometimes modes that they do not
<br>>> proposed and do not support.<br>></blockquote>
<div> </div>
<div> </div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">> The same reasoning could apply to other codecs as well: if a client<br>> doesn't support G.729
, you can't say it's broken if someone unexpectedly<br>> start sending that. Of course, in the case of Speex, we try and do our<br>> best...<br><br>I'm not talking about codec proposal: you cannot send G729 to a UA that
<br>didn't offered it. While you can send packetisation interval of 30ms even<br>if the UA offered that he wish to receive 20ms.<br><br>I think anyway, that adding "mode=any" is fixing the mode issue, so it's
<br>now possible to specify that you don't support some of the modes.<br><br>>> One possible way would be to use "mode=any" to clearly indicate that the<br>>> UA support any modes. The prefered mode could be specified by order of
<br>>> preference: "mode=5;mode=any". Other "limited device" would announce all<br>>> modes supported: "mode=5;mode=3;mode=1"<br>><br>> Yes, I agree with that.<br>><br>>> Samples for SDP negotiation must clearly indicates this behaviour:
<br>>><br>>> m=audio 8088 RTP/AVP 97<br>>> a=rtpmap:97 speex/8000<br>>><br>>> -> equivalent to "mode=any" (for smooth evolution of current<br>>> implementations)
<br>><br>> Shouldn't clients have at least a preferred mode? Otherwise, if everyone<br>> says "any", which bit-rate do you choose?<br><br>But I gave you example in previous mail! Clients that support any mode and
<br>prefer "mode=4" would say:<br><br> mode=4:mode=any<br><br>> <ship><br>><br>>> The above would make sense and compliant application would<br>>> be interoperable? right?<br>><br>
> I think so.<br>><br>>> That would be perfect for me, and I guess would be fine for you?<br>><br>> Yes, I think it's the best compromise -- and actually not very far from<br>> what we have now. I would still keep the thing that says 8 kbps SHOULD
<br>> be supported. Or maybe we can say "all modes SHOULD be supported and if<br>> it's not possible, then at least 8 kbps (mode 3) SHOULD be supported".<br><br>I think this is close to be equivalent anyway.
<br><br>>>>> The other way would be to make it transparent like g279.<br>>>><br>>>> Not sure what kind of transparence you mean? The Speex decoder (unless<br>>>> you remove some tables) is able to decode anything without even knowing
<br>>>> how it was encoded.<br>>><br>>> Except for limited device which are not capable of decoding the "mode"<br>>> that were removed from code ;)<br>>><br>>> If I understood well the speex stuff: a decoder without wideband
<br>>> implementation would be capable of locating the narrowband part<br>>> of the speex bitstream and return at least narrowband in audio? right?<br>><br>> Actually, if you give wideband data to a narrowband decoder, it will
<br>> decode it as narrowband without even *realising* it's wideband (the<br>> wideband bits are transparently ignored).<br>><br>>> Is this possible? (I guess it's not that complex):<br>>> --->wideband data --> NARROW BAND DECODER --> narrow band decoded audio!
<br>><br>> yes, that's possible.<br>><br>>> This does not seems possible:<br>>> --->mode=4 nband data --> LIMITED DEVICE ---> correct nband data<br>>> WITH MODE=3 ONLY
<br>><br>> That's not possible.<br>><br>>>> If all you mean is "do your best to decode anything you get no matter<br>>>> how different it is from what you asked for", then I agree.
<br>>><br>>> This has to be at least of recommendation so people are aware that speex<br>>> implementation allow this behavior: it was unclear to people that they<br>>> don't need to set option before starting decode process. Because they
<br>>> get a lot of decode failure before, I think speex users are more prepared<br>>> now. Anyway, it's good to inform people.<br>><br>> What do you mean by "they get a lot of decode failure"?
<br><br>Just that implementation was full of bugs.<br><br>>> Sometimes, draft are providing some C code: I would love to see some kind<br>>> of annex with a sample routine to decode speex data.<br>>><br>
>> Something like: static void dec_process(MSFilter *f)<br>>> <a href="http://cvs.savannah.nongnu.org/viewvc/linphone/mediastreamer2/src/msspeex.c?root=linphone&view=markup">http://cvs.savannah.nongnu.org/viewvc/linphone/mediastreamer2/src/msspeex.c?root=linphone&view=markup
</a><br>>><br>>> I'm not sure of my implementation (mainly I have a strange behavior of<br>>> "speex_bits_remaining"...)<br>><br>> I'm not really sure I understand your code, but it looks much more
<br>> complicated than it should be. Normally, the decode code should look like:<br>><br>> speex_bits_init(&bits);<br>> speex_bits_read_from(&bits, packet, length);<br>> while (1)<br>> {<br>> err = speex_decode_int(state, bits, out_buffer);
<br>> if (err != 0)<br>> break;<br>> play_audio(out_buffer);<br>> }<br>> if (err == -2)<br>> ms_warning("there was an error decoding");<br>><br>><br>> I see from your code that you use speex_bits_remaining(&bits) but I
<br>> can't really understand why. Could you explain?<br><br>I don't know......<br><br>I think that when I implemented this, that helped me to get out the loop.<br>It seems that in your code you call "speex_decode_int" one more time
<br>than me: I tried to call it only when "speex_decode_int" will succeed<br>because I though it was bad to call it when there was no data any more.<br>It seems I was wrong... Anyway: it's working fine...<br>
<br>Would you mind if I rewrite the draft myself with the idea we discussed?<br>Do you have the xml version?<br><br>tks<br>Aymeric<br><br>> Jean-Marc<br>><br>><br><br>_______________________________________________
<br>Speex-dev mailing list<br><a href="mailto:Speex-dev@xiph.org">Speex-dev@xiph.org</a><br><a href="http://lists.xiph.org/mailman/listinfo/speex-dev">http://lists.xiph.org/mailman/listinfo/speex-dev</a><br></blockquote></div>
<br>