www.makemkv.com

Hello,

I´m having a weird issue. I recently imported my first Shout!Factory UHD Bluray (Happy Death Day 2U) from the US to remux it with the dubbed track of my local bluray. Luckily both rips are the same length so no change is required there on the audio side, just a simple remux, which I do from time to time. I never had an issue but this time is was weird. Well, the remux process did not yield anything wrong - no error - nothing. (Remux process: rip file with makemkv and the use mkvtoolnix to combine the files) Yesterday I watched my remux through Plex and noticed some extreme gibberish. (1:23:40/45) First I thought it is the player software (Plex HTPC based on mpv) but then I tried it on all of my clients (Lg TV, Android Phone, Ipad, Nvidia Shield, mpv) and all of them showed this mangled image. (Some players even crashed) I did some further investigation with the cli player of mpv with software decoding, it showed a "ffmpeg error" message. I never had this one and I´m having no idea what it really means - all I know is it leads to an image error. I also suspected this could be an encoding issue on Shout!Factories side but that was negated relatively quickly after playing back the file with my UHD Bluray player. (no glitching there)
Then I googled the error message and found a post on the FFmpeg bug tracker side that mentioned this could be a remuxing problem, so I ripped the disc and remuxed it again with mkvtoolnix. I checked the file after the rip and after the remux - both files showed no glitching anymore at this spot.

Is this an issue someone else also had? Is there an explanation of how this could happen and/or whether this is an issue with makemkv or mkvtoonix? How could someone prevent this in the future? Is there a tool that could sanity check an hevc video stream? I tried hbbatchbeast but this did not help and showed no error.

Software versions used:
makeMKV V.1.17.1
mkvtoolnix V69


Thanks!

You said the second time you ripped "the disc". Do you mean as a full-disk backup?
If so, a difference in workflow would be that the first time MakeMKV created the mkv from the disk. And the second time MKVToolNix created the mkv from disk.
As such, logics could indicate to a demux/remux issue lying with MakeMKV. With that specific disc.

Or maybe it's just a coincidence where the disc was not 100% correctly processed at the first run. It sometimes just happens that a disc needs a second reading.

MRX_BD_07 wrote: ↑

Sun Aug 07, 2022 8:56 am

I also suspected this could be an encoding issue on Shout!Factories side but that was negated relatively quickly after playing back the file with my UHD Bluray player. (no glitching there)

Does this mean you put your UHD disc in your UHD player and it played fine? Or does it mean something else?

I suppose you don't happen to have your original UHD rip to check?

MRX_BD_07 wrote: ↑

Sun Aug 07, 2022 8:56 am

Then I googled the error message and found a post on the FFmpeg bug tracker side that mentioned this could be a remuxing problem, so I ripped the disc and remuxed it again with mkvtoolnix. I checked the file after the rip and after the remux - both files showed no glitching anymore at this spot.

Does this mean, as ArArdin suggests, the second time you created the .mkv with MKVToolNix (presumably from a backup created by MakeMKV) and also used MKVToolNix to remux? Or, are you saying that you ripped it again with MakeMKV (used MakeMKV to produce the .mkv file) and then used MKVToolNix to remux?

Thanks for the answers!

dcoke22 wrote: ↑

Tue Aug 16, 2022 2:11 am

Does this mean you put your UHD disc in your UHD player and it played fine?

Exactly, I have put the disc (not the file, described it poorly, sorry) inside the player and everything was fine at the spot, where the ripped/remuxed file would show the artifacts.

dcoke22 wrote: ↑

Tue Aug 16, 2022 2:11 am

I suppose you don't happen to have your original UHD rip to check?

Unfortunately not :/

dcoke22 wrote: ↑

Tue Aug 16, 2022 2:11 am

Or, are you saying that you ripped it again with MakeMKV (used MakeMKV to produce the .mkv file) and then used MKVToolNix to remux?

That's how I have done it. I have not made a disc backup, I have ripped it to a mkv file and then remuxed it with mkvToolNix again into an mkv file. Both times, so I don't really understand why the second time it worked. (I have also checked the new file with ffmpeg and no error was shown)

ArArdin wrote: ↑

Tue Aug 09, 2022 12:01 pm

Or maybe it's just a coincidence where the disc was not 100% correctly processed at the first run. It sometimes just happens that a disc needs a second reading.

Is this really a thing? I have never heard of this but it would make sense.

Anecdotes are not data, but my anecdote is after ripping a few hundred discs with MakeMKV, it has been my experience that if it produces a rip without any error messages, then the rip is a duplicate of what's on the disc. I've never unknowingly gotten bad output from MakeMKV. This makes me suspect the mangled output was introduced by MKVToolNix. Perhaps there's a weird timing bug or the system hiccuped when reading or writing data.

In any case, I'm glad redoing the process produced clean output the second time.

Update on this one...
I just ripped Black Adam and while watching I noticed similar glitching as seen with HPDD2U...
After some file diagnostics, I got the almost same cu_qp_delta error... The only difference this time is, I have not remuxed the file with mkvtoolnix. It was a basic rip with makemkv. (load the disc -> select the title -> set preferences on audio tracks and then hit "make mkv") So I guess the issue comes from makeMKV?

I have no idea what is going on. Could this also be slow or "buffer overflown" storage? All of my rips are created/copied to a nvme drive so I can leverage my 10gbit network when copying the file to my server...

I guess for now I will check all of my files with ffmpeg for cu_qp_delta errors and hash-check before and after transferring them to my storage box...

Version:
MakeMKV v1.17.3
Windows 11

Another update...

I will continue to post them, maybe they are useful for someone in the future...

I now started checking my 4K rips with FFmpeg and I just found another rip with a cu_qp_delta error message. What I find interesting about this one is, that the file (also a basic rip without remux) is over 2 years old, it was created on an older i7 pc (compared to the new rips created on an AMD system) with Windows 10 and the rip saved to an HDD before they where transferred to my storage system. The only thing that's the same is the optical drive... Well, I re-ripped the movie, and rechecked it with FFmpeg and everything is fine... Very interesting...