Re: requesting "AvgTimePerFrame" or "FieldRate" header field

2015-09-23 18:26 GMT+02:00 madshi <[email protected]>:
> 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.

It may not need an extra field. If we go with a fraction for the
TrackTimecodeScale it should probably be it. As mentioned in the other
thread VFR would have a problem with this.
Otherwise an extra value per track should be possible, and marked as
informational only. We already have the
http://matroska.org/technical/specs/index.html#FrameRate field that
has been deprecated. It's a damn float ;)

> Best regards, Mathias.
>
>
> 2012-12-16 11:09 GMT+01:00 madshi <[email protected]>:
>>> 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.
> _______________________________________________
> Matroska-devel mailing list
> [email protected]
> 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
[email protected]
http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel