Some .mkv files show as corrupted

[frozenpandaman]

e.g.

[eirnym]

Hi, have you tried to re-index them like HandBrake does?

[frozenpandaman]

@eirnym What do you mean?

[eirnym]

Handbrake has a feature to rebuild time-to-frame indices in a video file. Sometimes indices became corrupted and video could be still playable, but automated tools can give strange output. "Force re-index" process usually fixes these issues, full re-encoding is not required, but also helpful.

Basically, this plugin does sampling video file at specific moments using ffmpeg library. You can try to fetch some screenshots by yourself based using ffmpeg using something like following command ffmpeg -ss 01:23:45 -i input -vframes 1 -q:v 2 output.jpg.

[frozenpandaman]

Thanks! It's likely just a problem with the video file itself, then. I think some users would want to preserve the files exactly from the source they're downloaded, so modifying the video (i.e. the md5 hash or bytes changing in any way) or re-encoding isn't always an option. Can you point me to the Handbrake command that does this? I can't find the option in the GUI either, but would be interested to try it out per your suggestion.

You're right – the ffmpeg command you provided outputs a similarly (though not identically) messed up screenshot. Wonder if there's any way to fix this, since it does display properly during playback, when scrubbing to it, etc.?

[frozenpandaman]

Also (maybe this is different enough to deserve its own issue?) I've noticed some files, particular those with large file sizes, show up as having completely black thumbnails:

However, clicking on one of the sidebar thumbnails displays the full image, but the sidebar remains black:

Sometimes when viewing the file in Quick Look, a few of the images show, but not all, and it's often different ones each time:

[eirnym]

Reindexing usually solves the problem. Basically in most cases there's 2 kind of frames: full image frame with full image and motion frame. Index shows where full frames are for fast forward feature.

[eirnym]

Not all sources have good files in them. Broken video files and won't be shown correctly except you're lucky enough as you described.

[frozenpandaman]

Reindexing usually solves the problem.

Could you point me how to do this? I didn't see the option looking through the Handbrake CLI tools or GUI.

[eirnym]

really, thanks for noticing me :) it uses ffmpeg underneath, so I found answer fairly quickly

Tell ffmpeg to put into a new container (even with the same format and video/audio streams will be copied as they are)ffmpeg -i infile -c:v copy -c:a copy outfile or recode as you pleased.

[eirnym]

My guess is it's possible to make the same with Handbrake GUI, probably by adding this action as a new preset (without recoding video and audio)

[frozenpandaman]

Ah, you just meant "fix" it like that, got it. I'm happy (and more comfortable) with using ffmpeg anyway – you just mentioned Handbrake before, so I was going off that.

However, running that command doesn't fix either of the issues (black thumbnails and corrupted thumbnails). For the former, at least, it's not an issue with the video file – it's an issue with QLVideo, likely due to the file size.

[eirnym]

I used Handbrake for this back in the day.

Returning to your question, does ffmpeg returns correct images?

[frozenpandaman]

does ffmpeg returns correct images?

"the ffmpeg command you provided outputs a similarly (though not identically) messed up screenshot" https://github.com/Marginal/QLVideo/issues/93#issuecomment-968240959

[eirnym]

Probably you should file an issue to ffmpeg itself then. I'd love to know any way how to fix these video files as well

[Marginal]

If FFmpeg doesn't like the file then unfortunately QLVideo won't either. Closing.