Commit 3ba1bb01 authored by Ralph Giles's avatar Ralph Giles
Browse files

Replace MAY with SHOULD in the gap-filling guidelines.

This is really the best implementations can do as far as we
understand the possibilies, so it's better to be straightforward.
parent 0f9c4049
......@@ -268,7 +268,7 @@ The actual length of each missing Opus frame inside the packet is zero bytes,
<xref target="RFC6716"/> does not impose any requirements on the PLC, but this
section outlines choices that are expected to have a positive influence on
most PLC implementations, including the reference implementation.
Where possible, synthesized TOC bytes MAY use the same mode, audio bandwidth,
Synthesized TOC bytes SHOULD maintain the same mode, audio bandwidth,
channel count, and frame size as the previous packet (if any).
This is the simplest and usually the most well-tested case for the PLC to
handle and it covers all losses that do not include a configuration switch,
......@@ -281,8 +281,8 @@ When a previous packet is available, keeping the audio bandwidth and channel
data it generates.
However, if the size of the gap is not a multiple of the most recent frame
size, then the frame size will have to change for at least some frames.
Delaying such changes as long as possible simplifies things for PLC
implementations.
Such changes SHOULD be delayed as long as possible to simplify
things for PLC implementations.
</t>
<t>
......@@ -299,35 +299,38 @@ The total bitrate of the latter approach, including Ogg overhead, is about
<t>
Changing modes is discouraged, since this causes some decoder implementations
to reset their PLC state.
However, SILK and Hybrid modes cannot fill gaps that are not a multiple of
10&nbsp;ms.
If switching to CELT mode is needed to match the gap size, doing so at the end
of the gap allows the PLC to function for as long as possible.
Thus in the above example, if the previous frame was a 20&nbsp;ms SILK mode
frame, a better solution would be to synthesize a packet describing four
20&nbsp;ms SILK frames, followed by a packet with a single 10&nbsp;ms SILK
However, SILK and Hybrid mode frames cannot fill gaps that are not a multiple
of 10&nbsp;ms.
If switching to CELT mode is needed to match the gap size, a muxer SHOULD do
so at the end of the gap to allow the PLC to function for as long as possible.
</t>
<t>
In the example above, if the previous frame was a 20&nbsp;ms SILK mode frame,
the better solution is to synthesize a packet describing four 20&nbsp;ms SILK
frames, followed by a packet with a single 10&nbsp;ms SILK
frame, and finally a packet with a 5&nbsp;ms CELT frame, to fill the 95&nbsp;ms
gap.
This also requires four bytes to describe the synthesized packet data (two
bytes for a CBR code 3 and one byte each for two code 0 packets) but requires
three bytes of Ogg lacing overhead to mark the packet boundaries.
At 0.6 kbps this is still a minimal bitrate impact over a naive, low quality
bytes for a CBR code 3 and one byte each for two code 0 packets) but three
bytes of Ogg lacing overhead are required to mark the packet boundaries.
At 0.6 kbps, this is still a minimal bitrate impact over a naive, low quality
solution.
</t>
<t>
Since CELT does not support medium-band audio, using wideband when switching
from medium-band SILK ensures that any PLC implementation that does try to
migrate state between the modes will not be forced to artificially reduce the
bandwidth.
Since CELT does not support medium-band audio, wideband frames SHOULD be
generated when switching from medium-band SILK to ensure that any PLC
implementation that does try to migrate state between the modes will not be
forced to artificially reduce the audio bandwidth.
</t>
<t>
The synthetic TOC byte MAY use any of codes&nbsp;0, 1, 2, or&nbsp;3 to pack the
frame(s) into a packet.
If the TOC configuration matches, the muxer MAY combine the empty frames with
previous or subsequent non-zero-length frames (using code&nbsp;2 or
VBR code&nbsp;3).
Matching synthetic TOC byte(s) MAY be packed into packets using any of
codes&nbsp;0, 1, 2, or&nbsp;3.
If the TOC configuration matches, the muxer MAY further combine the empty
frames with previous or subsequent non-zero-length frames (using code&nbsp;2
or VBR code&nbsp;3).
</t>
</section>
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment