[Matroska-devel] Fwd: WebM file validation tool

Steve Lhomme slhomme at matroska.org
Mon May 24 09:54:46 CEST 2010


A lot of discussions are happening on the WebM mailing list.
This one may end up removing TrackTimecodeScale from Matroska (or simply
mark it as deprecated).

---------- Forwarded message ----------
From: Steve Lhomme <slhomme at matroska.org>
Date: Mon, May 24, 2010 at 9:24 AM
Subject: Re: WebM file validation tool
To: Frank Galligan <fgalligan at google.com>
Cc: j <j at v2v.cc>, WebM Discussion <webm-discuss at webmproject.org>


Also the explanation seem bogus. The Cluster timecode should not be scaled
by the track, otherwise that means that data from 2 tracks don't have the
same time base to be muxed in the same Cluster. Given there are as many
possible ways as there are channels the resulting muxing will end up being
suboptimal for only 1 track combination. For the others, the audio
corresponding to a video channel may end up being in a another Cluster,
maybe even many Clusters away if the stream is long enough. That's terrible
for playback.

Wether the TrackTimecodeScale is applied during playback or during muxing,
the problem is still there. After some time the actual audio timecode may be
too far from the video data and b0rk the player caching resulting in jerky
or loss of playback. So in the end the TrackTimecodeScale is a bad solution
to a tricky (and rare) problem.


On Mon, May 24, 2010 at 8:59 AM, Steve Lhomme <slhomme at matroska.org> wrote:

> Hi Frank,
>
> A lot of Matroska readers/players can read and handle the value. But I
> don't know any program that can output something else than 1.0 (the default
> value). The only program that may have is mkvmerge, but I checked the code
> and it doesn't. So dropping the element, even player side, could be fine. At
> worse those file where it's written it can be discarded.
>
> The reason for TrackTimecodeScale to exist is described here:
> http://www.matroska.org/technical/specs/notes.html#TrackTimecodeScale
>
> <http://www.matroska.org/technical/specs/notes.html#TrackTimecodeScale>It
> was designed when you could get the video from a framerate and then the
> audio from another source (in another language) and you try to mux them
> together without reencoding. Technically it's always possible to adjust the
> video framerate to match the audio (although it won't look natural). It
> becomes impossible when you merge more than 1 "heterogeneous" source
> together.
>
> This is a very corner case, so much that it's not in use anywhere, and may
> likely never be used. The only use is when the encoded audio doesn't get
> reencoded. So maybe it can be useful for storage of a "Master", but that's
> it.
>
> On Mon, May 24, 2010 at 3:25 AM, Frank Galligan <fgalligan at google.com>wrote:
>
>> Steve,
>>
>> Do you know if any Matroska implementations use TrackTimecodeScale? I
>> would like to submit a patch to FFmpeg but they would like to use as much of
>> the same code for Webm and Matroska.
>>
>> Frank
>>
>>
>> On Sat, May 22, 2010 at 12:06 PM, Steve Lhomme <slhomme at matroska.org>wrote:
>>
>>> On Sat, May 22, 2010 at 6:03 PM, <j at v2v.cc> wrote:
>>>
>>>>  > Yup, it's called mkvalidator:
>>>> > http://www.matroska.org/downloads/mkvalidator.html
>>>> >
>>>> > It was broken with "live streams" but I fixed it today. I haven't made
>>>> a
>>>> > new package though. You can always build it from SVN.
>>>> >
>>>>
>>>> for files created with the latest patches and ffmpeg i get ERR201
>>>> is this a know problem with the current ffmpeg patches?
>>>>
>>>> ERR201: Invalid TrackTimecodeScale for profile 'webm v2' at 386 in
>>>> TrackEntry
>>>> ERR201: Invalid TrackTimecodeScale for profile 'webm v2' at 461 in
>>>> TrackEntry
>>>>
>>>
>>> Yes, TrackTimecodeScale is not part of webm.
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20100524/ea44d7df/attachment.html>


More information about the Matroska-devel mailing list