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

From: "Timothy B. Terriberry" <[email-masked]>
Date: Fri, 24 May 2013 10:11:10 -0700

Jean-Marc Valin wrote:
> 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.

(as an individual contributor)
I like this much better than your earlier proposal that required special 
handling in the decoder, since it doesn't require any changes to 
already-deployed decoders, and keeps the decoding process (relatively) 
simple.

A few minor points:
- The start of the Encoder Guidelines section should forward-reference 
the LPC Extrapolation section.
- Need a reference on how to actually compute the linear prediction 
coefficients. We have references to both the Burg method and the Schur 
algorithm in RFC 6716, and source code in libvorbis. Some implementation 
guidance wouldn't be amiss.
- The language in general needs a little word-smithing. We can 
coordinate on that in git.

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Fri, 24 May 2013 10:19:16 -0700

Jean-Marc Valin wrote:
>>> +<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.

Well, I still think you need to explicitly list the SILK and CELT 
features that should be disabled (since, as you say, you don't want to 
refer to the libopus API), not just one feature that you shouldn't disable.

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

I think you need to say more than this. In some contexts you may not be 
able to choose how many samples are in the file (encoding a CD with no 
inter-track gaps, but where you wish to preserve sample-accurate track 
boundaries, for example). That means you may need to do some frame size 
juggling to ensure the end of the track lies at "a point near the end of 
the last frame". How near is enough? The last half? The last quarter? In 
what size frame? Someone without intimate DSP knowledge and knowledge of 
the Opus format is not going to be able to make informed decisions here, 
so we should provide some guidance.