Confused over frame rates being changed

[tomty89]

So then if I want to rip my DVDs to mkv, I guess the best answer is to trust Makemkv

Maybe. I wouldn't say that it must be doing everything correct, but it's probably good enough. I know too little about video codecs and Matroska itself to tell about certain stuff.

don't worry about what mediainfo reports about the frame rates (23.976. 24.000, or 29.970)?

Well the problem is, even if you should worry about it, what's next? Are you willing to analyze the video streams of the different shows or episodes and find out how they are really different? I mean something like literally looking into picture headers. (And before that, find out what tools you can use to do so -- assuming there's even a good enough one.)

It would be great if you can do that and then isolate what mkvtoolnix or makemkv might be doing wrong, but it's not exactly a trivial task.

[mattias83]

Yeah, that might be a bit beyond what I can do.

Just to be on the safe side I was dropping the files into mediainfo assuming if something was off, it would tell me. Unfortunately, it seems like DVD ripping can get messy due to a number of reasons, and without knowing why each file is being muxed the way it is, like you said, I guess there's not much else I can do anyways.

I thought mkvtoolnix was certainly something I could trust when it comes to the odd task now and then like ripping specific chapters or timestamps, but it seems even that appears to have issues.

If there's any other software that's more suitable for doing what I want - ripping DVD features and extras, easily with a GUI, I'd love to hear it. But it's looking like makemkv, for better or worse, and hoping the files it puts out are okay.

[tomty89]

For one AFAIK the maintainer of mkvtoolnix is a "one-man band". On and off it receive pull requests from other people but that was it. So you can't really expect / ask for much. It wasn't in "heavily maintained state" even back when I made my tiny contribution, especially not the MPEG-2 / DVD related code. The maintainer explicitly mentioned that he would rather / have to devote the time he has to maintain the code for modern format / codecs (but is open to PRs / fixes from others).

[mattias83]

So he closed the bug request and this was his comment:

"Not a bug. Matroska uses plain integers for both the default frame duration & the frame timestamps. Therefore they cannot express irrational numbers such as 30000/1001 precisely."

Does this make any sense to you? I don't understand this since we know mkvs from makemkv indeed play in VLC at the correct frame rates of 23.976024 and 29.970030. So this doesn't explain why mkvs from mkvtoolnix play in VLC at 23.976216 and 29.970628.

How can they both be correct? One has to be off, right?

[tomty89]

My guess is he didn't bother to read carefully. Maybe you can try reinstating you are aware of that and the problem is that "error" you saw is far more significant than it should be for just the integral conversion. (You may also suggest that he should pay attention to the millisecond part. I don't know if that would work out well though.)

P.S. You may also ask him to note that int() was applied in the formula where the correct / expected values was returned.

[tomty89]

Okay, I figured it all out, at least for MPEG-2 video stream. mkvtoolnix has nothing to do with the problem. VLC does.

First of all, the "precision loss" is introduced in the VLC code:
https://github.com/videolan/vlc/blob/3. ... e.cpp#L333
https://github.com/videolan/vlc/blob/3. ... e.cpp#L475

The next question would be, why the heck does it not happen with MKV from makemkv? The answer is this:
https://github.com/videolan/vlc/commit/ ... 5341c86c0d
(This hack is still there as of VLC 3.0.23: https://github.com/videolan/vlc/blob/3. ... 1489-L1495)

And when the respective packetizer is active / used, it "corrects" / resets the frame rate as per the frame rate code found in the video stream:
https://github.com/videolan/vlc/blob/3. ... #L752-L764

I have literally performed a test by changing the "libmakemkv" in the metadata to ten spaces (with dd conv=notrunc instead of e.g. mkvpropedit) to confirm that the packetizer is where the "correction" originates from, so I'm 100% sure that is the story.

However as mentioned, I have yet to find out what's the story with file with AVC or HEVC (or VC-1). Not even sure if the video track would always get a default duration in those cases. Also maybe e.g. makemkv doesn't set default duration but mkvtoolnix does is where their stories begin. (I mean like if that's a fact.)

[mattias83]

Thanks for digging deeper into this.

The "packetizer" and code links are over my head, but it sounds like you've discovered VLC is at fault regarding the non-standard frame rates being reported under "tools>codec information" for mkv files output by mkvtoolnix, due to imprecise playback by VLC, and VLC uses code hacks to keep the playback framerate more precise? And for some reason mkv files from makemkv are not affected but files from mkvtoolnix are? Is that why mkvtoolnix mkvs report non-standard framerates under VLC's codec information? Does this apply to NTSC/29.970 framerates and also blu-ray framerates?

If so, it seems there's no reliable method to quickly check an mkv for it's actual precise framerate and if it's deviated at all from it's original source framerate. Mediainfo seems to make educated guesses based on the first 100 frames or so and seems to be unreliable, and VLC seems to not be reporting accurately.

Which I guess leaves me back to just hoping that makemkv and mkvtoolnix are doing the right things when I rip my DVDs?

So then is it safe to assume then that neither makemkv nor mkvtoolnix are actually outputting problem mkvs from DVDs or blu-rays regarding frame rate, and it's just VLC (and mediainfo) causing confusion with how it's reporting the frame rates?

Bottom line, should I trust mkvtoolnix and makemkv when ripping my DVDs, even when mediainfo reports a different "original frame rate" in the scan results?

[tomty89]

The "packetizer"

Basically it means that MakeMKV is not muxing MPEG-2 stream in a very nice / proper way, so (as per my understanding) VLC needs to sort of "redo" part of the muxing "on-the-fly" (through inspecting headers in the stream by itself).

VLC is at fault regarding the non-standard frame rates being reported under "tools>codec information" for mkv files output by mkvtoolnix

Yes. In fact not only those output by mkvtoolnix, but basically any mkv files other than those output by MakeMKV (or technically, any that claims to be so in its metadata).

due to imprecise playback by VLC

Well I have no idea how much this frame rate thing affect actual playback, or in general how the number would be used. All I know is that, under normal circumstances, the frame rate is "transformed" / "calculated" from the "default duration" set in the file. "Default duration" is stored in nanosecond, such as 33366666 ns for 30000 / 1001 fps, although the actual precision depends on the software that produce it (e.g. it could be set to 33366000 ns).

The problem here is that when VLC reads the number from a file, it ignores "the less significant part", like even when mkvtoolnix set the value to 33366666 nanoseconds, VLC converts it to 33366 µs and then use that to derive the frame rate. (Btw in previous posts I made a mistake by calling microsecond / µs as millisecond / ms.) I have no idea why the developer made VLC does that, but you can see it concretely in the linked code.

and VLC uses code hacks to keep the playback framerate more precise

No.

And for some reason mkv files from makemkv are not affected but files from mkvtoolnix are

The "hack" I referred to was the packetizer.

Files from MakeMKV would have the same default duration value as mkvtoolnix does, so "originally" it should also be affected by the "precision loss" / microsecond problem I just explained. However, because VLC enables the packetizer for it, and that the packetizer would "reset" the "imprecise" frame rate that is already in VLC's "memory" to a precise value. (It doesn't do so because "it knew it was being imprecise", but essentially just a "side-effect".) For example, for a 30000 / 1001 fps video, resetting it from 1000000 / 33366 (29.970628) to 30000 / 1001 (29.970030). (I'm not really sure why they aren't 29.970629 or 29.970029 instead.)

Does this apply to

It applies to files with MPEG-2 video stream of frame rate that the corresponding default duration would suffer from "precision loss" in nanosecond-to-microsecond conversion (any duration that does not "end" with 000 when in ns). For example, for 30 fps ("exact" / "non-NTSC-ized" version of 30000 / 1001 fps) video the default duration would be 33333333 ns, and the frame rate derived / calculated from that should be 30.000000 fps, yet you would probably see 30.000300 fps in VLC (for any MPEG-2 MKV not from MakeMKV).

blu-ray

But since most Blu-ray does not come with MPEG-2 video (H.262) but AVC (H.264) or VC-1, or HEVC (H.265) for UHD Blu-ray, things could be very different for Blu-ray mux. The thing is I do NOT know whether default duration typically get set in MKV with AVC/VC-1/HEVC, and whether mkvtoolnix and MakeMKV have different "policy" in that. Suppose they both set default duration (to the same value for a particular video), you should NOT see any difference in the reported frame rate for non-MPEG-2 MKV (unless there is something similar that "kicks in" just for MakeMKV output like the MPEG-2 packetizer -- I'm not seeing any so far).

If so, it seems there's no reliable method to quickly check an mkv for it's actual precise framerate

Well, you can check the default duration set with mkvinfo (and maybe mkvtoolnix GUI) -- if it is set. 1000000000 divided by the default duration would be the frame rate the mux "reports" (for video with constant frame rate -- essentially including those with soft pulldown; I think that some codecs support literally varying frame rate, although it doesn't mean that players / decoders would support it well; and I have no idea whether in that case default duration is supposed to be set -- actually AFAIK default duration is somewhat optional anyway -- with at least some codec / mux / player the file should play fine even when its value is set to 0).

Bottom line, should I trust mkvtoolnix and makemkv when ripping my DVDs, even when mediainfo reports a different "original frame rate" in the scan results?

I don't think you should give too much of a damn about anything MediaInfo output...

[mattias83]

Regarding Makemkv not muxing MPEG-2 streams "in a very nice / proper way", does that mean it's not a great idea to use makemkv for DVD/MPEG-2 rips? Is the mkv output by makemkv from DVDs actually problematic for media players and frame rates, sync, etc.?

It's much more convenient to rip an episode or extra feature from a DVD using makemkv rather than mkvtoolnix, which doesn't open full DVDs, and mkvtoolnix also doesn't seem to easily support including chapters when ripping a DVD stream. Unless I'm doing it wrong, the only way I know to open a DVD in mkvtoolnix is browse to the DVD folder and open a specific vob, after figuring out beforehand which vob is which. Any linked VOBs automatically open with it ( VTS_01_1.VOB, VTS_01_2.VOB, etc.). But doing that loses chapters. There's no way to "open" and parse a full DVD like makemkv does.

But I don't want to use makemkv for DVDs if it means all the mkvs will be "off" or non-standard in some way that could cause playback issues. As mentioned before I use external players like Zidoo and Dune. In the past I've watched some 4:3 holiday special ripped by makemkv from DVDs, and while the players seem to play them fine, I don't really know if there's timing issues or frame rate issues going on that I'm unaware of. If I'm going to rip lots of episodes and holiday specials from DVDs, I'd prefer doing it the right way so there aren't issues later.

I wish this wasn't so complicated. Makemkv makes it seem easy but if it's doing something wrong, then that worries me.