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

madshi madshi at gmail.com
Sat Dec 8 17:48:03 CET 2012

Thank you, I'm happy that this is going to be added.

For old files most current DirectShow MKV splitters use
DefaultDuration as an FPS estimation. This is sometimes
wrong. But a rather simple logic can be used to auto-
correct that. E.g. if the DefaultDuration suggests 50p, but
if the video bitstream says 25p/50i at the same time, then
it's pretty clear that DefaultDuration is wrong with a factor
of 2x. Such a simple correction should work in most cases.
Not in all, but in most, so I guess that's good enough for
old files.

The same format as DefaultDuration for the new field
would be fine with me. One alternative solution might be
to use a similar logic as h264. Typical h264 values would
be 48000/1001, 60000/1001 or 50000/1000, but that would
require two new fields. So probably the DefaultDuration
format would be simpler = better.

One thing that is important is that the field should be very
clear about what is describes exactly. E.g. is it the frame
rate or field rate? Before or after deinterlacing? Before or
after evaluating the telecine flags?

Personally, I think it should be before deinterlacing. Ideally
it would be good if the frame rate would match the video
bitstream information. And that is always before deinterlacing.
I think for telecined movie the telecine affects the frame rate,
though. So e.g. a broadcast or DVD encoded as 24p, but
with telecine flags will likely have a video bitstream FPS
information of 30i (someone correct me if I'm wrong). So I
think that's what should also be written to the MKV header.

Best regards, Mathias.

2012/12/8 Steve Lhomme <slhomme at matroska.org>

> 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
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20121208/8bc14fc4/attachment.html>

More information about the Matroska-devel mailing list