Hi Tim,
Here's a revised patch that describes guidelines for encoders. These
guidelines are related to gapless support, but I'm sure there's other
recommendations we should give encoder implementers. The general idea is
to minimize the number of broken or suboptimal encoders.
Cheers,
Jean-Marc
On 11/19/2012 06:00 PM, Timothy B. Terriberry wrote:
> [email protected] wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Internet Wideband Audio Codec
>> Working Group of the IETF.
>
> The (other) chairs declared there was consensus to adopt this draft as a
> WG item and asked me to upload a new version of it.
>
> I have made a few minor edits from draft-terriberry-oggopus-01:
> 1) Fixed up the references.
> 2) Fixed a couple of typos.
> 3) Replaced a "should" with a "SHOULD" in Section 4.1.
> 4) Clarified the language around the starting granule position in the
> case that a) there is more audio in packets that complete on the first
> audio data page with a completed packet than the granule position
> indicates and b) the EOS flag is set on the same page (in this case you
> should not count forwards from 0, but should work backwards to figure
> out the real starting granule position).
> 5) Updated the acknowledgments.
>
> I have not incorporated any of the proposals that have been made to the
> list since the initial draft was posted (e.g., seamless chaining,
> replaygain tags, etc.).
> _______________________________________________
> codec mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/codec
>
>
diff --git a/doc/draft-ietf-codec-oggopus.xml b/doc/draft-ietf-codec-oggopus.xml
index ab20be5..9c23cbf 100644
--- a/doc/draft-ietf-codec-oggopus.xml
+++ b/doc/draft-ietf-codec-oggopus.xml
@@ -1138,6 +1138,74 @@ An implementation could reasonably choose any of these numbers for its internal
</t>
</section>
+<section anchor="encoder" title="Encoder Guidelines">
+<t>
+When encoding Opus files, Ogg encoders should take into account the
+algorithmic delay of the Opus encoder. In encoders derived from the reference
+implementation, the number of samples can be queried with:
+opus_encoder_ctl(encoder_state, OPUS_GET_LOOKAHEAD, &samples_delay);
+To achieve good quality in the very first samples of a stream, the Ogg encoder
+MAY use LPC extrapolation to generate at least 120 extra samples
+(extra_samples) at the beginning to avoid the Opus encoder having to encode
+a discontinuous signal.
+For an input file containing length samples, the Ogg encoder, SHOULD set the
+preskip header flag to samples_delay+extra_samples, encode at least
+length+samples_delay+extra_samples samples, and set the granulepos of the last
+page to length+samples_delay+extra_samples.
+This ensures that the encoded file has the same duration as the original, with
+no time offset. The best way to pad the end of the stream is to also use LPC
+extrapolation, but zero-padding is also acceptable.
+</t>
+
+<section anchor="lpc" title="LPC Extrapolation">
+<t>
+The first step in LPC extrapolation is to compute linear prediction coefficients.
+When extending the end of the signal, order-N (typically with N ranging from 8
+to 40) LPC analysis is performed on a window near the end of the signal. The last
+N samples are used as memory to an infinite impulse response (IIR) filter. The
+filter is then applied on a zero input to extrapolate the end of the signal. Let
+a(k) be the kth LPC coefficient and x(n) be the nth sample of the signal, each
+new sample past the end of the signal is computed as:
+<artwork align="center"><![CDATA[
+ N
+ ---
+x(n) = \ a(k)*x(n-k)
+ /
+ ---
+ k=1
+]]></artwork>
+The process is repeated independently for each channel. It is possible to extend
+the beginning of the signal by applying the same process backward in time. When
+extending the beginning of the signal, it is best to apply a "fade in" to the
+extrapolated signal, e.g. by multiplying it by a half-Hanning window.
+</t>
+
+</section>
+
+<section anchor="continuous_chaining" title="Continuous Chaining">
+<t>
+In some applications, such as Internet radio, it is desirable to cut a long
+streams into smaller chains, e.g. so the comment header can be updated.
+This can be done simply by separating the input streams into segments and
+encoding each segment independenty.
+The ony drawback of this approach is that it creates a small discontinuity
+at the boundary due to the lossy nature of Opus.
+An encoder MAY avoid this discontinuity by using the following procedure:
+<list style="numbers">
+<t>On the last frame of the first stream, encoding an independent frame by
+turning off all forms of inter-frame prediction (de-emphasis is allowed).</t>
+<t>setting the granulepos of the past page to a point near the end of the last
+frame.</t>
+<t>Beginning the new stream with a copy of the last frame of the first
+stream.</t>
+<t>Setting the preskip flag of the second stream in such a way as to properly
+join the two streams.</t>
+<t>Continuing the encoding process normally from there, without any reset to
+the encoder.</t>
+</list>
+</t>
+</section>
+
<section anchor="implementation" title="Implementation Status">
<t>
What follows is a brief summary of major implementations of this
_______________________________________________
codec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/codec
