MKV Merge Makes 29.97 file into 30

[Dorian]

I'm trying to create MKV files to burn to a data DVD and would like to have the option to repackage them as Blu-rays with menus in the future without encoding them again. They are either 1080i 29.97fps or 720p 59.94fps. My goal is to play them on stand alone Blu-ray players. I exported M4V and AC3 files with Adobe Premiere CS6 then used MKVmerge to put them in a MKV container. The MKV files MKVmerge produced now say they're 30fps or 60fps (using MediaInfo). I also tried Video to Video and got 59.880 for the 60s and didn't try the 29.97 ones. One of my Blu-ray players does an occasional stutter with the 60fps files as well. I don't know if the same would happen if they were 59.94 because I can't find a software that will produce one, but I tried a 59.94 M2T straight from Premiere and there was no stutter.

Is the change in frame rate a problem? Is there a program that will package M4V and AC3 without changing the frame rate?

I can export from Premiere as M2T files and keep the frame rate, but my Blu-ray players take longer to start playing them and it's a few seconds before the sound kicks in, so I'm thinking they may be less compatible. However, like I said, the stutter on the one Blu-ray player is gone with the M2T 59.94 file. Are the m2t files a better way to go for what I want to do?

Thank you for any insight you can give!

[ndjamena]

1: MediaInfo seems to process MKVs differently than some other file types. Try looking at the original video and the MKV using FFProbe and see if it thinks they have the same frame rate.

2: The frame rate in the stream headers doesn't always exactly equal the frame rate in the Blu Ray M2TS files. The blu ray specs are quite clear on what frame rates are acceptable so the actual frame rate must adhere to those specs. If the frame rate in the stream header is wrong then if you demux/remux with MKVToolNix the resulting MKV will have the wrong frame rate. To overcome that you'd need to specifically set the frame rate to the correct number in the remuxing command line.

[Dorian]

I don't know how to use FFProbe. Is there a program with a GUI that would work? The original files say they are 30 or 59.94. I'm using Elgato Game Capture HD if that is any help. In Premiere I changed the 30 to 29.97 when encoding. Do you think it maybe didn't change it properly? And maybe the Elgato actually produced a 60fps file that various software reads as 59.94?

[ndjamena]

Riiight. Experimenting here.

*sigh* The actual frame rate you want isn't exactly 59.94, it's 60/1.001 which equals about 59.94005994005994005994005994006fps (once rounded).

The problem here is that generally MKVs measure time to the nearest millisecond (or at best to the nearest nanosecond) and that leaves no way to represent the time-codes necessary for NTSC frame rates. As a consequence it just chooses the closest time-code and the closest duration, then when necessary modifies the duration of individual frames to keep things in sync, essentially producing variable frame-rate. Other containers tend to modify the time base for NTSC and so aren't affected. It looks as though once you reach 60/1.001fps the duration of each frame is so small that the impact of rounding to the nearest millisecond is making it impossible for MediaInfo/FFProbe to figure out what the actual frame-rate is. 59.880 fps would seem to be where MediaInfo should end up.

However, the 29.97 should be working fine and shouldn't be displaying as 30fps, so there's definitely something wrong there.

If you're trying to play a 60fps video on a 60/1.001 TV then there will have to be some kind of conversion going on which may cause problems... Theoretically a 59.880 file should work since there will actually be 60/1.001 frames to display, I guess it depends on the player...

[_Al_]

I have some 60p videos here in mkv,
mediainfo reports two frame rates, frame rate 59.880 and original frame rate 59.94, ffprobe reports 59.94, but after demuxing to H.264 with tsMuxeR to get raw video again out of that mkv , mediainfo reports again 59.970 fps, for that elementary H.264 stream

DVD should have bitrate lower than 18Mbit or so, does that MKV has higher bitrate than m2t? I guess not, but it is worth mentioning.

[ndjamena]

I was messing around with UT to get 60/1001fps files, I don't know if UT has any frame rate data in it's headers. The Matroska container overrides whatever's in the headers anyway, theoretically you shouldn't get any data from the headers that doesn't exist solely to help decompress the stream, but given the state Matroska is in there's not a lot of choice at the moment.

*sigh* I suppose someone's going to argue with me about that again:

...

> 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

And try to remember, the Matroska container is supposed to be able to hold multiple titles in a single file, it makes no sense to define frame rates in the stream header, what matters is the frame rate in the title you're playing NOT what's in the file as a whole. Setting the VFR flag in the Stream header is nicety aimed towards the current operating environment, nothing more.

I wish they'd hurry up and finish the bloody thing.

[poisondeathray]

mkvmerge seems very finnicky and buggy lately. Same thing happens with x264 streams, that were 60000/1001 CFR , so it' s not necessarily Adobe's fault. I guess it's work in progress for mkvmerge

I suppose you could use mp4 container if the frame rate was indeed the issue (there can be other reasons for playback problems). You could use yamb beta 2, mymp4boxgui , both GUI's for mp4box

Another problem with transport stream (m2t, ts, m2ts) is the larger overhead (typically ~5-7%)

[poisondeathray]

Funny thing is the divx mkv muxer get the fps correct (according to mediainfo). Weird

[ndjamena]

Hmmm, 16683333 * (60 / 1.001) = 999999980.01998001998001998001998

1000000000 / (60 / 1.001) = 16683333.333333333333333333333333

So I guess the question is, "what default duration has the divx muxer given the MKV it created?"


-Edit- MKVMerge is using a 1000000ns time scale, that might be a contributing factor.