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.
This commit is contained in:
Ralph Giles 2014-01-17 12:09:45 -08:00
parent 0f9c40499f
commit 3ba1bb01db

View file

@ -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 <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 section outlines choices that are expected to have a positive influence on
most PLC implementations, including the reference implementation. 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). 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 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, 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. data it generates.
However, if the size of the gap is not a multiple of the most recent frame 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. 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 Such changes SHOULD be delayed as long as possible to simplify
implementations. things for PLC implementations.
</t> </t>
<t> <t>
@ -299,35 +299,38 @@ The total bitrate of the latter approach, including Ogg overhead, is about
<t> <t>
Changing modes is discouraged, since this causes some decoder implementations Changing modes is discouraged, since this causes some decoder implementations
to reset their PLC state. to reset their PLC state.
However, SILK and Hybrid modes cannot fill gaps that are not a multiple of However, SILK and Hybrid mode frames cannot fill gaps that are not a multiple
10&nbsp;ms. of 10&nbsp;ms.
If switching to CELT mode is needed to match the gap size, doing so at the end If switching to CELT mode is needed to match the gap size, a muxer SHOULD do
of the gap allows the PLC to function for as long as possible. so at the end of the gap to allow 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 </t>
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 <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 frame, and finally a packet with a 5&nbsp;ms CELT frame, to fill the 95&nbsp;ms
gap. gap.
This also requires four bytes to describe the synthesized packet data (two 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 bytes for a CBR code 3 and one byte each for two code 0 packets) but three
three bytes of Ogg lacing overhead to mark the packet boundaries. 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 At 0.6 kbps, this is still a minimal bitrate impact over a naive, low quality
solution. solution.
</t> </t>
<t> <t>
Since CELT does not support medium-band audio, using wideband when switching Since CELT does not support medium-band audio, wideband frames SHOULD be
from medium-band SILK ensures that any PLC implementation that does try to generated when switching from medium-band SILK to ensure that any PLC
migrate state between the modes will not be forced to artificially reduce the implementation that does try to migrate state between the modes will not be
bandwidth. forced to artificially reduce the audio bandwidth.
</t> </t>
<t> <t>
The synthetic TOC byte MAY use any of codes&nbsp;0, 1, 2, or&nbsp;3 to pack the Matching synthetic TOC byte(s) MAY be packed into packets using any of
frame(s) into a packet. codes&nbsp;0, 1, 2, or&nbsp;3.
If the TOC configuration matches, the muxer MAY combine the empty frames with If the TOC configuration matches, the muxer MAY further combine the empty
previous or subsequent non-zero-length frames (using code&nbsp;2 or frames with previous or subsequent non-zero-length frames (using code&nbsp;2
VBR code&nbsp;3). or VBR code&nbsp;3).
</t> </t>
</section> </section>