Timecode doesn't start at 0

[fnordware]

Someone sent me a WebM file that seems to be improperly written. The time code of the first cluster is not 0, but 155 seconds. It seems like the first 155 seconds were just not written to the file.

The time code ends at 286 seconds, and the file's duration is also listed at 286 seconds. So again, it seems like the file was intended to be written starting at 0, but wasn't for some reason.

Should I be expected to be deal with WebM files whose time code does not start at 0?

Brendan

[Jon V.]

In my experience video files are not required to start at zero. Think about how multi bit rate files are split and reassembled.

--
You received this message because you are subscribed to the Google Groups "Application Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to apps-devel+...@webmproject.org.
To post to this group, send email to apps-...@webmproject.org.
Visit this group at http://groups.google.com/a/webmproject.org/group/apps-devel/.
For more options, visit https://groups.google.com/a/webmproject.org/d/optout.

[Brendan Bolles]

On Aug 11, 2014, at 5:55 AM, Jon V. wrote:

> In my experience video files are not required to start at zero. Think about how multi bit rate files are split and reassembled.

I don't see any evidence that Matroska works this way. libwebm calculates duration as the last last block plus duration of that block. There's no accounting for the file starting at something other than 0. Other Matroska programs don't provide a way to start timecode at some arbitrary number.


Brendan

[Jon V.]

Yes, the timestamps are typically relative. Some formats use high clock rates such as 90khz and using absolute values would limit the total runtime whereas relative ts could allow for streams that go on for years.

[Brendan Bolles]

On Aug 12, 2014, at 1:24 PM, Jon V. wrote:

> Yes, the timestamps are typically relative. Some formats use high clock rates such as 90khz and using absolute values would limit the total runtime whereas relative ts could allow for streams that go on for years.

But I'm not talking about the relative timestamps, which indeed do start at 0 for each cluster. I'm talking about the absolute ones, which is what libwebm uses to set the duration. This file I'm talking about has a first cluster with a TimeCode element of 154 seconds.

WebM also sets the TimecodeScale to 1000000, so WebM files should be limited to 9 hours.


Brendan

[Jon V.]

I can't find anything that says the cluster timecodes are anything other than arbitrary.

Does the first block have negative relative timecode?  It is possible that the blocks start at negative 154 seconds.  Seems logical to me that a non-zero start cluster abs is valid and would be useful in a number of scenarios.

Have you tried playing the file?

[fnordware]

On Tuesday, August 12, 2014 4:47:13 PM UTC-7, Jonathan Valliere wrote:

I can't find anything that says the cluster timecodes are anything other than arbitrary.

Does the first block have negative relative timecode?  It is possible that the blocks start at negative 154 seconds.  Seems logical to me that a non-zero start cluster abs is valid and would be useful in a number of scenarios.

Have you tried playing the file?

Yeah, I haven't found a definitive word anywhere. Was hoping one of the Google guys would chime in. libwebm and apparently the muxer that made this file behave like it should start at 0 though.

Doesn't appear to be any negative time code. I'll attach the webminspector.py output for you to look at.

The file plays in Firefox, but has the problem of the long duration. Firefox makes a timeline for 286 seconds. The file starts playing, but then halts when it runs out of video at 131 seconds.