Subject: Re: [Cellar] Clarification on blocks with a negative timecode

From: Michael Bradshaw <[email-masked]>
Date: Thu, 19 May 2016 11:56:07 -0700

On Fri, Jan 15, 2016 at 6:55 AM, Timothy B. Terriberry <[email-masked]>
wrote:

> Steve Lhomme wrote:
>
>> OK, so do we agree that negative timecodes should not be "rendered"
>> (play any audio) ?
>>
>
> I think the meaning of CodecDelay is clear: you should throw away the
> first "CodecDelay" worth of samples. What would be the behavior if the
> first block's timecode (before adjusting for CodecDelay) was positive? If
> it was already negative (again, before adjusting for CodecDelay)?
>
> To my mind, this should be thought of as if the first "CodecDelay" worth
> of samples are simply deleted. They don't have a negative timecode. They
> don't exist. After doing that, the behavior should be the same as in the
> no-CodecDelay case. The problem here is that we currently talk about the
> timecode of a block, not of individual samples.

I think the reason that the meaning of CodecDelay isn't entirely clear is
because the Matroska specification only talks about subtracting timestamps
(it never mentions discarding samples, which I think it should). I propose
the following change to CodecDelay's definition:

CodecDelay is the duration of the codec-built-in delay in nanoseconds. The
decoded frames from the beginning of a stream should be discarded until
CodecDelay duration has passed, and CodecDelay must be subtracted from each
block timestamp in order to get the presentation timestamp. The value
should be small so the muxing of tracks with the same presentation
timestamp are in the same Cluster.

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Fri, 20 May 2016 11:45:23 -0700

Michael Bradshaw wrote:
> CodecDelay is the duration of the codec-built-in delay in nanoseconds.
> The decoded frames from the beginning of a stream should be discarded
> until CodecDelay duration has passed, and CodecDelay must be subtracted
> from each block timestamp in order to get the presentation timestamp.
> The value should be small so the muxing of tracks with the same
> presentation timestamp are in the same Cluster.

The idea seems pretty reasonable, but I think it's important to be 
precise here. What does "until CodecDelay duration has passed" actually 
mean when "decoded frames" are in units of 1/48,000th of a second, and 
CodecDelay is in nanoseconds? How do you compare times in two different 
units (or derive times in one unit from another)? Are you comparing with 
the timestamp of the start of the frame or the end, and is this even the 
same for audio vs. video?

---

From: Michael Bradshaw <[email-masked]>
Date: Fri, 20 May 2016 16:36:05 -0700

This is a good question. If CodecDelay is convertible to the sampling rate
without rounding (that is to say, if CodecDelay * <sample_rate> /
1,000,000,000 is an integer), then the answer is trivial as CodecDelay ends
on a frame boundary. But if not, I would be in favor of comparing time
based on the start of the frame and discarding whole frames. And do it
consistently for audio/video/whatever.

I think that's simplest to understand and implement correctly. Arguments
could be made for some other approach, but so far I find this approach the
most logically convincing.

Thoughts/opinions?