makemkv producing .mkvs with video corruption

[Drag0nFly]

The file sizes are indeed identical, although diff-ing the files reveal that they are different between rips. I did a couple of more tests – the full backup (reported no issues), ripping to local drives vs. nfs-shares, etc. (made no difference)

However, from what it now looks like it appears to be some strange incompatibility between MakeMKV and _all_ the players I've tested(!). I watched the same glitching segment in MPlayer on Linux, and – voil? – no issues.

Then I compiled MPlayer via brew (vs. "MplayerX" which I had been using) on OS X, and it again played fine without issues.

So in short, I must apologize for directly blaming MakeMKV in the first place. It seemed natural since the video glitch was present on VLC, MPlayerX and XBMC, and since no other video stream has exhibited this problem before.

Now, if only there is a way to get these rips working properly in XBMC. I tried the daily-build (20130520), and it is showing the same glitch. For the record, the disc I am testing with is the U.S version of "Dredd". On my system the glitch appears three times, the first of which at the 16:39 mark. Also tried with an episode of Game of Thrones and Glengarry Glen Ross, so the issue is not disc related.

[Romansh]

The file sizes are indeed identical, although diff-ing the files reveal that they are different between rips.

How about diffing and/or comparing checksums for the raw H.264 streams after extraction?

Code: Select all

mkvextract tracks /path/to/mkv/file/number1 0:number1_video.264
mkvextract tracks /path/to/mkv/file/number2 0:number2_video.264

Now, if only there is a way to get these rips working properly in XBMC. I tried the daily-build (20130520), and it is showing the same glitch. For the record, the disc I am testing with is the U.S version of "Dredd". On my system the glitch appears three times, the first of which at the 16:39 mark. Also tried with an episode of Game of Thrones and Glengarry Glen Ross, so the issue is not disc related.

If the raw H.264 streams have no differences, I suggest remuxing with mkvmerge (or mkvmerge GUI if you prefer). Some players are pretty sensitive to how audio/video is interleaved, the size of MKV clusters, etc. - remuxing may fix that.

If this doesn't work, a more drastic approach would be to demux all tracks to raw streams before remuxing, to make sure mkvmerge does not preserve any of MakeMKV's "output characteristics", but you'll want to be sure to extract timecode files along with each video or especially audio tracks, in case there are gaps (silence).

[Drag0nFly]

Thanks for the mkvextract/-merge tip. I will try that later and see whether it makes any difference.

[Drag0nFly]

I've now done the audio/video extraction + remuxing via mkvmerge; and can confirm that the glitch is still there. Also reconfirmed that this same video (either original or remuxed) plays fine via MPlayer on OSX. (albeit not with the most recent VLC or XBMC)

Also performed a test with the Linux build of XBMC – which also plays the video w/o issues, so this is probably another one of those OS X curiosities.

mkvmerge -o test.mkv number1_video.264 number1_audio
mkvmerge v6.2.0 ('Promised Land') built on Apr 30 2013 19:17:47
'number1_video.264': Using the demultiplexer for the format 'AVC/h.264'.
'number1_audio': Using the demultiplexer for the format 'DTS'.
'number1_video.264' track 0: Using the output module for the format 'AVC/h.264 (unframed)'.
'number1_audio' track 0: Using the output module for the format 'DTS'.
The file 'test.mkv' has been opened for writing.
'number1_video.264' track 0: Extracted the aspect ratio information from the MPEG-4 layer 10 (AVC) video data and set the display dimensions to 1920/1080.
Progress: 100%
The cue entries (the index) are being written...
Muxing took 22 minutes 55 seconds.

In other words, this starting to look like a prospective bug report for the OSX branch of XBMC.

[Romansh]

I've now done the audio/video extraction + remuxing via mkvmerge; and can confirm that the glitch is still there. Also reconfirmed that this same video (either original or remuxed) plays fine via MPlayer on OSX. (albeit not with the most recent VLC or XBMC)

Also performed a test with the Linux build of XBMC – which also plays the video w/o issues, so this is probably another one of those OS X curiosities.

[…]

In other words, this starting to look like a prospective bug report for the OSX branch of XBMC.

If it affects both XBMC and VLC, but only under OS X, I'd suspect maybe a hardware-accelerated decoding issue. The Linux version would not be using hardware decoding through the same API (or maybe not at all), so that could explain the difference (software decoding should usually produce visually identical results on all platforms, assuming the same decoder is used - which is the case for XBVMC, VLC and MPlayer).

[Drag0nFly]

Which would be true if MPlayer on OSX behaved the same way, which it doesn't. – it also uses hw accel. Since there are clearly identifiable spots which do not change between rips or demuxing/remuxing the streams, it appears to be the way each player handles the mkv/h264 video decoding (i.e, a compatibility issue).
Also, the problem isn't 100% identical on XBMC and VLC. On VLC the player freezes up for a while (which isn't the case for XBMC)–should have mentioned this earlier.

It's going to be a hard issue to create a bug report for. Haven't tried recreating the MKV with with 1.8.3, though. But from the changelog it would probably be the same (not that this is a MakeMKV issue anyway)

[Romansh]

Any chance you could split the MKV with mkvmerge and provide a small clip (30 seconds or less) demonstrating the issue?

[Drag0nFly]

Yeah, I was planning to do that for a future bug report anyway–will post a link or attachment once I have it.

[Drag0nFly]

I've uploaded a short sequence displaying the glitch. Also verified that it is the VDADecoder acceleration in OSX (I'm using Intel HD3000) which is causing it.

https://www.dropbox.com/s/2qyyt0jd073pb80/seq.mkv

[Drag0nFly]

btw.–I don't know if the clip is still of interest; since you were right in suggesting it is related to the Intel VDADecoder/x264 acceleration–which makes it funny how that problem could show up only _three times_ for an entire 2h feature. I would have thought it'd be much more visible if the hw-accel was the culprit, but there you go.

[Romansh]

which makes it funny how that problem could show up only _three times_ for an entire 2h feature. I would have thought it'd be much more visible if the hw-accel was the culprit, but there you go.

If the issue occurred throughout with every Blu-ray compliant H.264 bitstream, the issue would have been very obvious and someone would have fixed it already…

Edit: reproduced in QuickTime X, so nothing VLC or XBMC can do about it I'm afraid.

[Drag0nFly]

Unsure what you mean with your last comment. I've verified that the glitch is not there with the VDADecoder acceleration disabled in XBMC.

This is also apparently a known issue affecting certain Macs, detailed here: http://wiki.xbmc.org/index.php?title=XB ... c_specific

[Drag0nFly]

(deleted)

[Romansh]

Edit: reproduced in QuickTime X, so nothing VLC or XBMC can do about it I'm afraid.

This means the issue also exists in QuickTime Player X, so it's not an issue of VLC and XBMC using VDADecoder incorrectly - only Apple can fix this.

As for the "green line" issue, it looks like a different issue to me.

[Drag0nFly]

Gotcha. But as long as there is a workaround for it I'm happy. I can certainly live without the hw-acceleration as the system is more than capable of playing h.264 material without it.

Maybe Apple has a focus on fixing this, but usually their updates introduce more issues than the few trivial ones that are actually resolved.