<div dir="ltr"><div><div>Yes, that's a start.<br><br></div>Ultimately, though, I'm hoping to reduce the 80ms requirement, and am trying to get a handle on what state in the decoder must converge and what complications I might be up against. I'm also only considering CELT-based encodings if that simplifies things.<br>
<br></div><div>I know that Opus can do inter-frame energy envelope prediction, but that dependency can be eliminated by using intra-frames.<br>
<br></div><div>There's also a dependency introduced by the MDCT overlap of CELT. Without the previous frame, this could be a major term in the convergence requirement.<br><br></div><div>Other than that, I'm not sure what other dependencies I would need to consider.<br>
<br></div><div>Is their a paper or some studies or discussions available about where the 80 ms comes from?<br></div><div>I'm a fairly new member to this group, but did scan the mailing list archives for similar topics ...<br>
</div><div><br></div><div>Thanks again,<br></div><div>-Bob Estes<br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 15, 2013 at 5:30 AM, Ralph Giles <span dir="ltr"><<a href="mailto:giles@thaumas.net" target="_blank">giles@thaumas.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 13-08-14 10:09 PM, Bob Estes wrote:<br>
<br>
> I've been studying the Opus code and documentation for a while and have<br>
> seen it mentioned several times that Opus uses pre-skip to allow the<br>
> codec to converge. What convergence are they referring to? Rate<br>
> control? Energy envelope prediction after seeking?<br>
<br>
</div>Not rate control, but there are a number of predictors running in the<br>
decoder which need some amount of data to converge with their expected<br>
values when the encoder and decoder would be out of sync for whatever<br>
reason.<br>
<br>
Pre-skip can be used by a muxer to describe how much data must be run<br>
through the decoder before valid output is obtained at the start of a<br>
file. This could be e.g. 80 ms if the muxer is creating a file from the<br>
middle of another one (lossless editing, webrtc stream recording).<br>
<br>
More commonly it's used to account for resampler and algorithmic delay<br>
so the output can be phase-aligned with the input.<br>
<div class="im"><br>
> Also, I'm also interested in the seeking behaviour of the decoder.<br>
> If, say, I want to skip ahead in an Opus bitstream, can I start decoding<br>
> at any intra frame without artifacts?<br>
<br>
</div>You must start feeding data to the decoder about 80 ms before the<br>
intended seek point, and discard the output. This is for convergence as<br>
described above, but for seeking you can use the general 80 ms rule as<br>
described in the Ogg Opus draft. This is referred to as pre-roll, and<br>
doesn't need to be specially specified by the muxer like pre-skip since<br>
it's constant and applies to any seek point, not just the start of playback.<br>
<br>
Does that help?<br>
<span class="HOEnZb"><font color="#888888"><br>
-r<br>
<br>
</font></span></blockquote></div><br></div>