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

Timothy B. Terriberry
Mon, 22 Jul 2013 14:55:48 -0000

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).