Re: [codec] Suggestions for OggOpus draft

[Gregory Maxwell <[e-mail]>]

Jean-Marc Valin [[e-mail]]:
> I suggest adding these two sections to the OggOpus draft, one that
> describes how to handle chaining and one that has recommendations for
> encoders. I'm sure there's still more things an encoder can do that I
> haven't listed.

The recommendations here are quite complex in terms of container handling
— complex enough that alone their implementation would be comparable to
a whole implementation of a basic encoder / decoder (not including the
codec itself).  This complexity is hidden by the fact that it uses DSP
terminology like 'LPC' in place of what would be a dozen step procedure.

It also doesn't address the multitude of corner cases that can arise: like
what should an encoder do if the minimum 2.5ms padding requirement
means two frames must be trimmed, so they need to be repacketized,
but they have different toc's and so can't be repacketized. I expect many
implementations would end up outputting two packets that need to be trimmed,
which may break some decoders.

Opus-tools's encoder does LPC extrapolation for end-padding, it doesn't bother
with the beginning because doing it at the beginning added latency and was
somewhat messy and I wasn't able to find any originally gapless streams that weren't
gapless without it (which surprised me). 

Since even with only a half-padding encoder and no decoder splice handling 
I was unable to find any gaplesness issues for originally gappless audio, I 
suspect the decoder part of this advice is just not needed.  It's also unlikely
to be implemented: it's complicated, requires DSP coding (admittedly modest)
which will take some implementers out of their comfort zone, and can be
quite difficult to implement in some architectures (e.g. if separate links in a
chain are decoded independently— as is common in existing mediaframe
works).

Recommending encoder extrapolation to prevent pre/post leakage of the
discontinuity to silence seems prudent to me. But I think the decoder
advice is unlikely to be followed especially if written as a recommendation.
If it turns out to actually be important it should probably be a requirement
not a recommendation. If it's not important then I think it should be omitted
because reduced implementation behavior diversity is more important than
theoretical improvements.

Chain itself is not widely supported by implementations of Vorbis. Only basic
audio only tools commonly support it.  I fear adding a bunch of complexity to
handle them the recommended way will further encourage implementations
which opt not to work with chaining at all.

(My opinion would be revised with examples which aren't gapless without it,
or by the existence patches for gstreamer / vlc / and or Firefox, all of 
which will, I think, have problems implementing these recommendations.)