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:
parent
0f9c40499f
commit
3ba1bb01db
1 changed files with 25 additions and 22 deletions
|
@ -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 ms.
|
of 10 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 ms SILK mode
|
</t>
|
||||||
frame, a better solution would be to synthesize a packet describing four
|
|
||||||
20 ms SILK frames, followed by a packet with a single 10 ms SILK
|
<t>
|
||||||
|
In the example above, if the previous frame was a 20 ms SILK mode frame,
|
||||||
|
the better solution is to synthesize a packet describing four 20 ms SILK
|
||||||
|
frames, followed by a packet with a single 10 ms SILK
|
||||||
frame, and finally a packet with a 5 ms CELT frame, to fill the 95 ms
|
frame, and finally a packet with a 5 ms CELT frame, to fill the 95 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 0, 1, 2, or 3 to pack the
|
Matching synthetic TOC byte(s) MAY be packed into packets using any of
|
||||||
frame(s) into a packet.
|
codes 0, 1, 2, or 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 2 or
|
frames with previous or subsequent non-zero-length frames (using code 2
|
||||||
VBR code 3).
|
or VBR code 3).
|
||||||
</t>
|
</t>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue