How long does the FFmpeg check take on a large MKV file?

It takes as long as it would to play the whole file. FFmpeg decodes every frame, so a 2 hour movie will take about 2 hours of processing time on a typical computer.

Can I run these tools on Windows without installing anything extra?

Yes. MKVToolNix provides a GUI version on Windows, and both MKVToolNix and FFmpeg offer prebuilt Windows executables. You can run the command line tools from the Command Prompt after adding them to your PATH.

What does it mean if mkvinfo shows no Cues element?

It means the file does not have a seek index. The file may still play from start to finish, but skipping to a later chapter or timestamp may cause glitches or take a long time. A proper repair should add Cues back.

Is it safe to use these checks on a file I already tried to repair?

Yes. Running mkvmerge -i , mkvinfo , or the FFmpeg decode command does not modify the file. You can run them as many times as needed on the original or on a repaired copy.

Check an MKV for Errors With MKVToolNix and FFmpeg

To check an MKV for errors, you do not need expensive software. Two free tool sets, MKVToolNix and FFmpeg, confirm whether a file is healthy and pinpoint where damage exists. Run these exact commands and read their output before you attempt a repair and after you finish one. The same tools work on Windows, macOS, and Linux.

Identify the Container and List Tracks with Mkvmerge

First, verify that the file is a valid Matroska container and see which tracks it contains. MKVToolNix includes a command called mkvmerge that does this quickly.

Open a terminal or command prompt and run:

mkvmerge -i file.mkv

Replace file.mkv with the path to your MKV file. The -i flag tells mkvmerge to identify the file. If the file is not a valid Matroska container, the command prints an error message such as "The file could not be opened." If the file is valid, the output lists every track inside it, showing the track ID, type (video, audio, subtitles), codec, and language.

A successful identification means the container structure is readable. A failure means the file header is damaged or the file is not an MKV at all. This is the fastest way to detect a corrupted MKV at the container level.

Inspect the Element Tree with Mkvinfo

Where mkvmerge -i gives a summary, mkvinfo prints the full element tree of the file. Use it to check whether critical metadata like Cues and duration are present.

Run:

mkvinfo file.mkv

The output can be long. Look for two things:

Duration: The element tree should contain a Duration entry with a value in nanoseconds. If this entry is missing, the file may be truncated or incomplete.
Cues: A healthy MKV usually contains a Cues entry (also called the index). Without Cues, seeking within the file may be slow or broken. A missing Cues entry does not always mean corruption, but it is a sign that the file was not finalized properly.

If mkvinfo fails partway through the output, the damage is likely located at the point where the output stops. This tells you which part of the file is corrupted.

Decode the Whole File with FFmpeg

Container-level checks do not reveal decoding errors inside the streams. FFmpeg decodes every frame and reports only actual errors, which is the most thorough way to verify an MKV file.

Run the Full Decode Check

Use this command:

ffmpeg -v error -i file.mkv -f null -

Here is what each part does:

-v error: Tells FFmpeg to print only error messages and suppress normal status output.
-i file.mkv: Specifies the input file.
-f null -: Decodes the file and discards the output instead of writing a new file.

If the command completes and returns to the prompt with no output, no decoding errors were found. The file plays cleanly from FFmpeg's perspective. If errors appear, they list the timestamp and the type of problem, such as a corrupt frame or a missing packet.

What the Errors Mean

An error might say corrupt block at X or header damaged. The timestamp tells you where in the file the damage is located. Use that timestamp to decide whether to cut the file or replace a specific segment. If you only see a few errors near the end, the file may be mostly playable. Many errors throughout the file indicate severe corruption.

Compare Before and After Repair

After you run a repair tool, run the same checks again to confirm the damage is gone. The procedure is the same each time.

Run mkvmerge -i repaired.mkv to confirm the container is still valid and all expected tracks are present.
Run mkvinfo repaired.mkv and check that the Duration entry exists and that Cues are present. If the original file was missing Cues, a proper repair should add them.
Run ffmpeg -v error -i repaired.mkv -f null - and verify that no decoding errors are reported.

If the FFmpeg command still shows errors, the repair did not fix the damaged frames. Extract the undamaged tracks and remux them, or cut out the corrupted segment. If the FFmpeg command shows no errors but mkvinfo still shows a missing Duration entry, the repair tool may have fixed the streams but not the container metadata.

Extract Individual Tracks with Mkvextract

When a repair fails to fix the whole file, salvage undamaged tracks by extracting them individually. MKVToolNix includes mkvextract for this purpose.

Find the Track ID

First, use mkvmerge -i file.mkv to list all tracks and their IDs. The track ID is a number shown next to each track, such as Track ID 1: video or Track ID 3: subtitles.

Extract a Single Track

To extract a subtitle track with ID 3, run:

mkvextract tracks file.mkv 3:subtitles.srt

This pulls that track out of the MKV and saves it as a separate file. You can extract audio, video, or subtitles the same way. If a track is damaged, mkvextract may fail on that track. If it succeeds, the extracted file is likely intact and can be remuxed into a new MKV with mkvmerge.

This approach works when only one stream is corrupted. Extract the healthy video and audio tracks, then combine them into a new container. The new file will be clean even if the original MKV had a damaged subtitle track or a broken index.

What the Tools Cannot Do

These free tools are diagnostic and extraction tools. They find errors and pull out working parts, but they cannot repair a corrupted video stream itself. If FFmpeg reports decoding errors, the video data inside the file is damaged. No tool can recreate that lost data. Cut out the bad section, replace it with a clean version from another source, or accept the glitch.

If you need to recover a file that has minor container damage but intact streams, remuxing with mkvmerge often fixes it. For files with severe stream damage, find a new copy of the damaged segment.