[Matroska-devel] Opus in Matroska

Ralph Giles giles at thaumas.net
Thu Sep 20 00:54:01 CEST 2012


On 12-09-15 3:51 AM, Steve Lhomme wrote:

> This is *definitely* something we don't want. The Cue/index in a file
> should tell where to jump in a file to play correctly at a particular
> time.

But that's the problem. The file cannot be played correctly if the
splitter hands the decoder blocks after a seek starting with the current
timestamp. It must start handing blocks PreRoll milliseconds earlier
than the seek target and discard the early output.

>                                                 If we go the v4 we
> could fix that by adding a TimecodeScaleNumerator, combined with
> TimecodeScale (the denominator) we would have our fraction, and with a
> default value of 1 we keep backward compatibility.

Being able to mark durations and offsets with sample accuracy would be
helpful, I agree.

> Now back to seeking. I think the timecode shift should be handled by
> the codec internally. So that number of samples to shift would be put
> in the CodecPrivate as a constant.

That is what the current proposal does to handle the algorithmic delay
of the encoder.

> When seeking, at any position that pre-roll sample is known to the
> codec and should use it to adjust its decoders and "external"
> timecodes. It would all appear to have just needed data from the
> outside, even though internally it's shifted.

I'm not sure how this would work. If the decoders apply an 80 ms
pre-roll after seek, what timestamps does the encoder put on the first
80ms of Block elements? Must the ambiguious portion of compressed data
always be combined into e.g. the same SimpleBlock so it can all share a
timestamp? How does the decoder know what the the target seek time is?

Thanks for responding,
 -r


More information about the Matroska-devel mailing list