shithub: opus

Info  •  Files  •  Log  •  Branches

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.

--- a/doc/draft-ietf-codec-oggopus.xml

+++ b/doc/draft-ietf-codec-oggopus.xml

@@ -268,7 +268,7 @@

 <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 @@

  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 @@

 <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 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 ms SILK mode

- 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

+However, SILK and Hybrid mode frames cannot fill gaps that are not a multiple

+ of 10 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 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

  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 0, 1, 2, or 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 2 or

- VBR code 3).

+Matching synthetic TOC byte(s) MAY be packed into packets using any of

+ codes 0, 1, 2, or 3.

+If the TOC configuration matches, the muxer MAY further combine the empty

+frames with previous or subsequent non-zero-length frames (using code 2

+ or VBR code 3).

 </t>

 </section>