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

Steve Lhomme slhomme at matroska.org
Sat Dec 8 15:55:23 CET 2012


I agree with the storage vs display distinction. A new field might
help when it's correct. The problem remains when it's absent, or worse
incorrect. But in any case the new field would allow better user
experience at very little cost.

I was going to suggest it should default to DefaultDuration when now
set (in older files) but that would not be right if you require this
field to be absolutely correct or missing.

To avoid errors of the past, I would define this value as a fraction.
That's where Matroska v4 would come handy as timestamps will be based
on fractions and not just ns in floating point. But for now we could
just define it in the same format as DefaultDuration (it certainly
have to be a multiple).

On Wed, Dec 5, 2012 at 1:11 PM, Moritz Bunkus <moritz at bunkus.org> wrote:
> 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
> _______________________________________________
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
> Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel



-- 
Steve Lhomme
Matroska association Chairman


More information about the Matroska-devel mailing list