WebM file validation tool

[j...@v2v.cc]

Hi,
is there some tool like mkvinfo that would check if a file is a valid
webm file, also checking that the file only uses the allowed subset of
Matroska?

j

[Steve Lhomme]

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.

Steve

[j...@v2v.cc]

> 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

[Steve Lhomme]

Yes, TrackTimecodeScale is not part of webm. 

[j...@v2v.cc]

looks like gstreamer git also has issues:

ERR201: Invalid Tag for profile 'webm v2' at 7605134 in Tags
.... file created with GStreamer plugin version 0.10.22.2 / GStreamer
Matroska muxer

[Frank Galligan]

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

[Steve Lhomme]

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

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.

[Steve Lhomme]

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.

[Frank Galligan]

Thanks, I see what it could be used for. That would be pretty rare, maybe slideshows and the like could use it. But as you said I think this would be a lot harder to handle in the player instead of the muxer. I'm going to propose a patch to FFmpeg to remove setting this value. Currently they always set it to one. This should not effect Matroska format as the spec says this value has a default of 1.0. 

Frank

[Steve Lhomme]

Yes, storing it as 1.0 or not storing it has exactly the same behaviour.

[James Zern]

On Mon, May 24, 2010 at 09:45, Frank Galligan <fgal...@google.com> wrote:
> Thanks, I see what it could be used for. That would be pretty rare, maybe
> slideshows and the like could use it. But as you said I think this would be
> a lot harder to handle in the player instead of the muxer. I'm going to
> propose a patch to FFmpeg to remove setting this value. Currently they
> always set it to one. This should not effect Matroska format as the spec
> says this value has a default of 1.0.
>

Probably not necessary:

------------------------------------------------------------------------
r23247 | conrad | 2010-05-21 21:41:38 -0400 (Fri, 21 May 2010) | 3 lines
Changed paths:
M /trunk/libavformat/matroskaenc.c

matroskaenc: Don't write track timecode scale

It's not required for mkv and unsupported in webm