[Matroska-devel] Opus in Matroska

Steve Lhomme slhomme at matroska.org
Sat Sep 22 20:29:36 CEST 2012

Here is how the frameworks I know work:
1/ the splitter reads a frame with a timecode
2/ the codec decodes the frame
3/ the frame is rendered based on the timecode given by #2

There is nothing that forbids phase #2 to tweak the timecode. In the case
of video a common tweak is to reorder frames. In the case of Opus shift the
timecode by the amount defined in the CodecPrivate. On the output of the
Opus codec the timecodes would be the one it got on input. But that doesn't
mean internally it would be the same. The shift would be added during
encoding and removed during decoding. Aren't other audio codec do the same?
What is different with Opus? That's what I don't understand.
On Sep 22, 2012 7:20 PM, "Ralph Giles" <giles at thaumas.net> wrote:

> On 12-09-22 8:52 AM, Steve Lhomme wrote:
> > As for your question, what timecodes do the codec output after a seek
> > ? Whatever seek starting point it corresponds to, minus the internal
> > delay. For example, seeking at 0ms would output data starting at
> > -80ms. Or not output them at all if they are considered garbage.
> I'm sorry, I still don't understand what you're describing here. Let's
> go back a level.
> I am assuming that there are two components in software doing playback
> one component, what Moritz called a "splitter", is parsing the
> container, and handing blocks of data to the other component. That other
> component is the "decoder" which runs the blocks it gets through the
> actual codec and hands it back to the player. These components must be
> conceptually separate because there are many codecs, and the splitter
> needs to be able to talk to them all over a shared interface.
> > It's up to the codec and transparent to the container.
> How then, can this be true? Is the splitter supposed to ignore the
> timestamps it sees, and rely on the decoder to adjust them to account
> for pre-roll? I thought in most frameworks the splitter looked at the
> timestamps, and expected the decode buffers to be similarly timestamped?
>  -r
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20120922/b93d6954/attachment.html>

More information about the Matroska-devel mailing list