http://forum.videohelp.com/threads/368819-MKV-Merge-Makes-29-97-file-into-30
... and since we're on to frame rates, I created a VFR UT Codec MKV and MediaInfo displayed it as CFR, I'm assuming either UT doesn't have a VFR flag in it's header or MKVMerge doesn't set it but... @%& Matroska files are ultimately supposed to be able to contain multiple titles in a single file, and if they ever get the thing working properly frame rate meta data really ought to be set at a chapter level rather than a track level (although, assuming it was ever there in the first place, they seem to have destroyed the ability to set tags to a track within a chapter to get the track statistics working and to enable the people who can't tell the difference between MKV tags and MP4 tags). I guess reading the stream header is acceptable for as long as people like to pretend MKV==MP4 but I thought I'd point it out... there are some limited tags in the files now, when you manage to implement them you might consider moving away from reading the stream header info where possible and switching instead to the duration and number of frames tag, although I know that's not a perfect solution either. sigh
How do you tell if an MKV video stream is CFR or VFR?
You cannot really. There's no header flag for it, and technically VFR is already achieved if there's a single frame duration that's different than all the other frame durations.
So yes, looking at the track timecodes (e.g. with »mkvextract
timecodes_v2…«) is the only way that I know of.
Maybe MediaInfo uses some heuristics in order to determine and display that fact; I don't know. If it does then it's like all heuristics:
imprecise and error-prone.
Kind regards,
mosu
It is definitely an heuristic, with all the issues with heuristics.
I try to check as much as possible the time stamps of the first frames in order to detect VFR, but sometimes there are issues (time stamps in MKV are at 1000 Hz, this is not a lot :( ).
Is it possible to get the file with 59.880 fps issue?
The one I have at the moment is UT Video codec which is a bit big to upload. I'm guessing I need length on this one so you can check the time codes. I'll try to make a h.264 version but my head hurts so I don't know how long it will take.
(now that I'm reading what I wrote it sounds ridiculous, that bit at the bottom is part of an email reply I got from Mosu (MKVToolNix) by the way.)
http://www.mediafire.com/watch/janf111vd9vt1ne/Toxie.mkv
This have been an issue with mediainfo for a long time.
I reported it back in 2013, http://sourceforge.net/p/mediainfo/bugs/772/
and also with the partially fixed https://sourceforge.net/p/mediainfo/bugs/762/
As far as I can tell it's caused by the time code scale MKVMerge uses. MKVMerge indicates time in milliseconds (1000000ns), whereas the files that show the correct frame rate scale time by 50000 nanoseconds or similar.
1ms doesn't seem to be accurate enough for the frame rate detection implementation currently used by MediaInfo, I'm assuming 60/1.001 is the highest non integer standard frame rate so, having shorter frame durations, it's the one that needs the greatest accuracy in it's time-codes.