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

madshi madshi at gmail.com
Wed Sep 23 18:26:45 CEST 2015

Hi Steve,

sorry to revive such an old "thread", but since you're currently
actively working on extending the MKV spec, maybe you can take this
old wish of mine into account now, too? I think MKV is really missing
this specific piece of information as of yet.

Best regards, Mathias.

2012-12-16 11:09 GMT+01:00 madshi <madshi at gmail.com>:
>> Wasn't your original goal to display the content at the original
>> frame rate it was recorded ?
> My original goal was simply to have a reliable frame rate indicator for MKV
> video tracks, which is currently not available.
> It is true that I want to use this to decide the display refresh rate etc.
> But that is just my personal end goal. From a design point of view the new
> frame rate indicator should ideally be compatible to all other containers to
> make development easy. Other containers usually just pass the
> h264/MPEG2/VC-1 frame rate information through, so MKV should do that, too,
> to stay compatible.
>> If so I fail to understand how writing 30000/1001 for 24p
>> content is good.
> For true 24p content (e.g. Blu-Ray) 24000/1001 should be written.
> I suppose you're wondering about soft-telecined content (which is encoded as
> 24 frames with telecine flags)? This content type practically tells the
> decoder to decode the 24 frames and then to interlace them to 30i and output
> them this way. Whether the decoder really does that, whether a deinterlacer
> is sitting behind the decoder etc are things that the MKV muxer can't
> possibly know. So a frame rate of 30000/1001 should be written to the header
> (or 60000/1001 as the *field* rate).
> Basically we have to find a crystal clear definition of what the new MKV
> frame/field rate field specifies. And since the MKV muxer doesn't know
> whether a deinterlacer will be in the display chain and what the
> deinterlacer will do exactly, it doesn't make sense to specify the "final
> display refresh rate" in the MKV because the MKV muxer just doesn't know
> that. Instead it makes sense to store the frame rate that the decoder should
> output, because there's no confusion about that. And that happens to match
> exactly how h264/MPEG2 and VC-1 specify the frame rate in their bitstream.
> Best regards, Mathias.

More information about the Matroska-devel mailing list