Re: [codec] I-D Action: draft-ietf-codec-oggopus-00.txt

[Ron <[e-mail]>]

Hi Jean-Marc,

A few quick "first-reading" comments on this ...

On Fri, Mar 29, 2013 at 05:39:03PM -0400, Jean-Marc Valin wrote:
> 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.


> 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, &amp;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>

If this is going to be generally recommended, I wonder if we shouldn't provide
a 'reference implementation' of it in libopus, and also make some reference to
that here?


In the following section, I wonder if we need to provide a few more specifics
(and also possibly some API support in libopus), since this draft primarily
is focussed on an encapsulation format, and many people implementing it will
likely be using a separate encoder library, quite possibly without having, or
otherwise needing, a very detailed knowledge of the Opus spec itself or the
internals of the encoder they are using.

The issues you raise here, while important, do kind of blur the lines between
"encapsulating the output of an encoder" and "doing additional encoding above
and beyond what the encoder you may be using does".  And they aren't specific
to the Ogg encapsulation, other mechanisms would surely get the same benefits
from them too.

> +</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.

s/independenty/independently/

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

How do people turn that off?

> +<t>setting the granulepos of the past page to a point near the end of the last
> +frame.</t>

How do they determine where that point should be?

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

What such ways would ensure this is done properly?

> +<t>Continuing the encoding process normally from there, without any reset to
> +the encoder.</t>
> +</list>
> +</t>
> +</section>

The answers to these questions may be obvious to someone who has studied the
Opus spec and the encoder that they are using in detail, but in the context
of this draft I suspect we should probably offer slightly stronger guidance
about how to get this right, if we are going to include these concerns here.

 Cheers,
 Ron