MKV subtitles that will not sync

First, work out where your subtitles are

If you have a .srt or .ass file sitting next to the video, skip this section. Correct that file inthe tool, keep the same base name as the video, and your player will pick it up.

If the subtitles appear in your player's subtitle menu but there is no file on disk, they are embedded in the MKV and need extracting first. List what is inside:

ffmpeg -i movie.mkv

Then pull the track you want:

ffmpeg -i movie.mkv -map 0:s:0 subs.srt

0:s:0 means the first subtitle stream. Use 0:s:1for the second, and so on. MKVToolNix does the same job withmkvextract tracks movie.mkv 3:subs.srt, where the number comes from mkvmerge -i movie.mkv.

One catch: some MKVs carry image-based subtitles, PGS or VobSub rather than text. Those cannot be extracted to SRT without OCR, because there is no text in them to extract. If ffmpeg refuses and mentions hdmv_pgs ordvd_subtitle, that is what you have, and you will need an OCR tool such as Subtitle Edit.

Whether the browser preview opens your MKV

It depends on what is inside, not on the container. This surprises people, because MKV has a reputation for being unopenable on the web.

Chrome and Edge will generally play an MKV whose video is H.264and whose audio is AAC. Firefox and Safari do not support the Matroska container at all, so on those the preview will not load whatever is inside.

Even in Chrome, two things commonly stop it:

• HEVC / H.265 video. Standard on 4K and many 1080p encodes, and not decodable in most Chrome builds.
• AC-3, E-AC-3 or DTS audio. Standard on Blu-ray rips, and not decodable at all. The picture may appear while the audio fails, which also stops automatic detection from working.

So the honest advice is to try it. Drop the MKV in. If it plays, everything works, including automatic detection, which can read audio straight out of a Matroska file when the codec is supported. If it does not, the fallback below takes one command.

When the MKV will not open

Detection does not need the picture. It listens to the speech and matches it against your subtitle timing, so an audio-only file works just as well, is far smaller, and sidesteps both the HEVC and the AC-3 problem at once:

ffmpeg -i movie.mkv -vn -c:a aac -b:a 64k audio.m4a

Drop audio.m4a in alongside the subtitles. A two-hour film comes out around 55MB, decodes quickly, and never leaves your machine.

The -c:a aac matters. It re-encodes whatever the original track was into something every browser can decode, which is the whole point when the source is DTS or Dolby.

If you would rather not touch a command line

You do not need the video at all to correct a subtitle file. Work out the offset in your player, then apply it:

• VLC: pressH to push subtitles later andG to pull them earlier, in 50ms steps. The current delay shows on screen. Note the number when it looks right.
• mpv: z and x do the same, and the delay appears in the OSD.

Those adjustments are discarded when you close the player. Enter the number you found in the tool to write it into the file permanently, for every player and every device.

Watch the sign. If VLC shows a subtitle delay of +2500ms, the subtitles needed pushing later, so the correction is +2.5s.

The middle option: a delay stored in the container

There is a third position between a delay your player forgets and a corrected subtitle file. MKVToolNix can write the offset into the MKV itself: add the file, select the subtitle track, and set Delay under Format specific options, in milliseconds. Remuxing takes seconds because nothing is re-encoded.

Worth understanding what you get. The delay travels with the MKV, so any player opening that file is correct without being told. It does not travel with the subtitles: extract that track later, or hand the .srtto someone else, and the timestamps inside are still the original wrong ones. The container is carrying the correction, not the subtitles.

So it is the right tool when the MKV is the thing you keep, and the wrong one when the subtitle file is. It also cannot help with drift, for the same reason a player delay cannot — one number added to every line does nothing about an error that grows.

Putting corrected subtitles back

You usually do not need to. Name the corrected file to match the video,Film.2019.1080p.mkv and Film.2019.1080p.srt, put them in the same folder, and VLC, mpv, Plex, Jellyfin and Infuse will all load it automatically.

Media servers want a little more.Plex and Jellyfin read a language code from the filename, and without one the track shows up as Unknown and may not be selected automatically:

• Film.2019.1080p.en.srt — English
• Film.2019.1080p.en.forced.srt — forced, for foreign dialogue only
• Film.2019.1080p.en.sdh.srt — deaf and hard of hearing

The basename before the code must match the video exactly. If a server still ignores the file after a rename, it is usually that the library has not been rescanned, or that local subtitle files are switched off in its agent settings rather than anything wrong with the file.

If you do want it inside the container, remux without re-encoding:

ffmpeg -i movie.mkv -i subs.srt -map 0 -map 1 -c copy -c:s srt out.mkv

-c copy matters. It rewrites the container without touching the video or audio streams, so it takes seconds and loses no quality.