Re: [codec] Ogg Opus zero-length frames

["Timothy B. Terriberry" <[e-mail]>]

Mark Harris wrote:
> lost or not transmitted.

Done.

> ...plus one byte of Ogg lacing.

See below.

> For initial zero-length frames, might it be better to prefer the
> configuration of the first non-zero-length frame to the extent
> possible, when available, to help in any situation where the
> configuration of the first packet might be used to report
> information (such as frame size), or for an initial estimate of
> bandwidth, required buffer sizes, etc.?

I thought about this a little when writing the original text, and I'm 
not sure it helps much. It's not a bad thing to do, both here and when 
you're forced to change modes to match the gap duration, but the 
benefits are small (you can't really do a good job estimating initial 
bandwidth/buffer sizes from 0-byte frames, for example), and it means 
you can't write out anything until you get the first packet after the 
gap. Most RTP stacks, on the other hand, are going to declare packets 
lost and generate PLC without necessarily waiting for that to arrive.

> Or perhaps the last sentence should just be omitted, since it
> already effectively says that the mode, bandwidth, and channel
> count are unlikely to matter to a decoder in this case.

In practice I only expect initial gaps to be useful in conjunction with 
other streams (e.g., video), since otherwise you would just take the 
arrival of the first Opus packet as the start of the stream, so perhaps 
it isn't worth spending much text on them. If you don't think this is 
necessary, let's just drop it.

> s/to //

Done.

> s/80/20/

Done.

>> frames requires 4 bytes (plus an extra byte of Ogg lacing overhead),
>> but allows the PLC to use its well-tested steady state behavior for
>> as long as possible.
>
> To clarify, if the previous frame was 20 ms SILK, is this
> suggesting a 4 x 20 ms SILK packet followed by a 3 x 5 ms CELT
> packet?  The next paragraph suggests keeping the mode as long as
> possible, implying that it may be better to use 4 x 20 ms SILK +
> 10 ms SILK + 5 ms CELT.  Or is minimizing the number of frame size
> changes more important than keeping the mode as long as possible?

No, the other way around. I changed this example a few times and didn't 
think through the last version very well, apparently. 4x20 ms SILK + 
10ms SILK + 5 ms CELT would be better. I'll rework this to clarify.

Thanks for the review!