Hi Ron,
On 03/30/2013 03:28 AM, Ron wrote:
>> +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?
I'm not sure this really belongs in libopus -- maybe in libopusfile once
it gets encoder support?
> 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.
I'd rather minimize references to the libopus API because it's not
normative and it may be different many years from now.
> 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.
It's not specific to Ogg, but it's still useful knowledge for someone
generating an Ogg file. In theory, you should be able to create an
encoder using just this draft and the Opus and Ogg RFCs.
>> +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?
That's actually something that needs to be cleanly exposed in the
libopus API. The functionality is already there and you can probably get
it to work by specifying 100% packet loss, but it needs to be a
dedicated setting.
>> +<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?
I mean that any point near the end would work. Any thoughts on how to
make this clearer?
>> +<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?
Well, properly as in avoiding hole or duplicated samples, i.e. the
preskip should be such that the first sample of the second stream is the
one that follows the last sample of the first stream. Any suggestion on
the wording?
Cheers,
Jean-Marc
_______________________________________________
codec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/codec
