From 3ba1bb01dba72c269c25b4ab91a12d185b293868 Mon Sep 17 00:00:00 2001 From: Ralph Giles <giles@mozilla.com> Date: Fri, 17 Jan 2014 12:09:45 -0800 Subject: [PATCH] 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. --- doc/draft-ietf-codec-oggopus.xml | 47 +++++++++++++++++--------------- 1 file changed, 25 insertions(+), 22 deletions(-) diff --git a/doc/draft-ietf-codec-oggopus.xml b/doc/draft-ietf-codec-oggopus.xml index 3a95e0115..4346148c2 100644 --- a/doc/draft-ietf-codec-oggopus.xml +++ b/doc/draft-ietf-codec-oggopus.xml @@ -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 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> -- GitLab