[Matroska-devel] requesting "AvgTimePerFrame" or "FieldRate" header field

Moritz Bunkus moritz at bunkus.org
Wed Dec 5 13:11:27 CET 2012


Hey,

Additional information from me. There are two points of view regarding
the issue of something like the frame rate or timecode calculation.
Those points can be named "storage" and "display".

The origin of this proposal is a discussion that has taken place on
doom9: http://forum.doom9.org/showthread.php?p=1603993#post1603993  It
starts a few posts earlier, but the linked post is where the acutal
technical discussion starts.

First I argued against having such an additional field, but Mathias
has succeeded in convincing me that it is needed.

At the moment the existing "DefaultDuration" field is purely
addressing the "storage" aspect. It defines the value that most blocks
in a Matroska file will be visible on screen (note that the same is
true for audio, simply with other words; I'll focus on video). It is
agnostic to how the video is encoded: be it in progressive frames
(meaning one Matroska block occupies the whole screen), in interlaced
fields (one Matroska block only contains content for either the odd or
the even lines), or even more complicated schemes like telecined
content. "DefaultDuration" is present so that every block does not
have to have its own "Duration" child to be present. It is therefore a
space optimization.

Mathias point, however, concerns solely the "display" aspect. Today's
content will indeed be refreshed at fixed intervals on screen, even if
the storage contains mixed content (e.g. 50i and 25p mixed). You still
only refresh the display 25 times per second, deinterlacing the
interlaced fields before showing them. That's why having the "display
frame rate" available to a player is something that can improve the
playback experience a lot.

It is not easy to calculate the "display frame rate" solely based on
the information that is currently available in Matroska. It cannot be
done from "DefaultDuration" alone; you have to analyse the video
track's content (progressive? interlaced? telecined?) and its
timecodes in order to do that. So if the muxer can provide that
information already then Matroska should give the muxer the option to
store this piece of information.

Kind regards,
mosu


More information about the Matroska-devel mailing list