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!
_______________________________________________
codec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/codec
