[opus] Encoder state management - 'chunked' Opus?

[Timothy B. Terriberry]

David Holroyd wrote:
> My code does not recreate encoder state per-frame, but it does create
> new state at the start of each 'chunk' (where a chunk is 1 second of
> consecutive Opus frames, right now).  Is this an unsupported use of the
> codec (and therefore a potential source of my issue), or should this
> have little impact on the output other than reduced efficiency?

This does sound like the source of your issue. If you don't reinitialize 
the decoder at the start of each chunk, then you'll decode extra padding 
samples at the start of each one (and lose the corresponding samples 
from the end of the previous chunk).

If you're putting these frames in, e.g., Ogg, then you can start a new 
chain for each chunk, which will indicate to the decoder that it needs 
to reset between them. Make sure you're properly setting the preskip 
value in the header to get it to skip the padding samples at the start, 
and encoding at least that many samples extra to flush the buffered 
samples at the end.

That will ensure you're at least encoding and decoding the right samples 
(at some efficiency cost). However, because of the lossy nature of the 
compression, there may still be small artifacts when switching from one 
chunk to another. See 
<http://www.ietf.org/mail-archive/web/codec/current/msg02972.html> for 
some ideas that would eliminate this in the encoder. Unfortunately, 
these are not yet implemented, and require tracking state between chunks 
(which, if you could do that easily, presumably you wouldn't be 
resetting the encoder state for each one).

N.B., not all players handle chained streams very well (e.g., Firefox 
treats them as unseekable).