[CELT-dev] Variable frame size and API changes
Benjamin M. Schwartz
bmschwar at fas.harvard.edu
Tue May 18 13:41:31 PDT 2010
On 05/18/2010 04:28 PM, Jean-Marc Valin wrote:
> Quoting Torgeir Hagland <torg at gaikai.com>:
>> Are there any use-cases where it would be acceptable for lag
>> to vary over time?
> Yes, the use case here is that as network bandwidth changes, you should be able
> to scale not only the quality, but also the delay.
I have to say that I still don't see how seamless frame size switching
helps. If you imagine that the sample clocks for record and playback are
synchronized, then if you are using 20 ms frames, you have at least 20 ms
of delay between record and playback. If you then switch to 5 ms frames,
seamlessly, you will still have the exact same total delay in the system.
To reduce the delay you must drop 15 ms' worth of samples, either by
dropping samples during encoding or by dropping packets on decode. Either
way, you introduce a discontinuity, making the seamless switch irrelevant.
Switching the other way is even worse, since you will presumably only
discover congestion when it causes packet loss. If you are experiencing
packet loss, then the discontinuity from the frame size switch is irrelevant.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: OpenPGP digital signature
Url : http://lists.xiph.org/pipermail/opus/attachments/20100518/35a27a6c/attachment-0002.pgp
More information about the celt-dev