Convert GIF to MKV

Media servers sort what they find into films, episodes, music and images, and they decide by container. A GIF lands on the wrong side of that line: it is an image file, so Jellyfin and Kodi either skip it or file it as artwork, and no amount of naming convention changes their mind. The animation is invisible to the thing that is supposed to play it.

An MKV is unambiguous. The scanner reads a duration, a video track and a resolution, and the item appears in the library with a thumbnail and a progress bar like everything else. That is the whole of the argument for this conversion, and it is the reason to do it — not file size, which any video container would deliver.

MKV was published in 2002 as an open container designed to hold anything for as long as anybody wants to keep it: any number of video, audio and subtitle tracks, chapters, attachments, and metadata that survives being moved between machines. Its uses in this registry are recorded as archival and delivery, and the archival half is the honest one.

What it is not is a web format. Its browser support is recorded as none — not partial, none — and it is not designed for progressive streaming the way WebM is. If there is any chance this animation ends up embedded on a page, converting it to MKV puts it one step further from that, not closer.

Matroska will carry almost any codec, which makes the choice a real one rather than a lookup. This conversion writes H.264 in the High profile, because the person putting a file into a self-hosted library is usually feeding a television, a streaming box or a phone app, and H.264 is the one thing every piece of that hardware decodes without transcoding on the fly.

The alternative would have been VP9 or AV1, both smaller at the same visible quality and both a gamble on the far end. A media server that has to transcode on playback turns a silent five-minute animation into a job for a CPU that is usually also doing something else. A file the client can play directly costs nothing.

The Matroska file this produces holds one video track and nothing else, which is exactly what a GIF has to give. What makes that a starting point rather than a limitation is that MKVToolNix can add to it later without re-encoding anything: a commentary track, a subtitle file, chapter marks, a cover image.

Remuxing copies the video stream across untouched, so nothing is lost in the process and it takes seconds rather than minutes. If this animation is going to become part of something larger — a compilation, a lecture with narration recorded afterwards — starting from MKV means every later step is a container edit rather than another generation of compression.

The GIF format has no motion compensation. Frame twelve is stored as a complete image even if it differs from frame eleven by four pixels, and the only compression applied is LZW over an indexed palette. That design is from 1989 and it never changed, which is why a screen capture saved as a GIF can be tens of megabytes for a couple of minutes of almost nothing moving.

H.264 stores one full frame and then, for each frame after it, the difference. On the material that ends up in a library as a GIF — a captured terminal session, a slowly rotating render, a whiteboard being drawn on — most of the picture is unchanged from frame to frame, and that is precisely the case the codec was built for.

A GIF frame carries at most 256 colours. Whatever the original capture had, that reduction happened when the GIF was written, and it is baked into the frames the encoder receives. A gradient that was smooth is now stepped, and a dithered area is now a field of alternating pixels.

The video encoder does not add to that, but dithering is a genuine complication: it is high-frequency noise, and high-frequency noise is the most expensive thing a video codec can be asked to store. A heavily dithered GIF converts to a larger MKV than a flat one of the same dimensions and length, and raising the quality band makes that worse rather than better.

A GIF has no sound, so the MKV contains a video track alone. Most players handle that without comment — VLC and MPV show no audio device, Kodi plays it silently.

A few library front ends are less relaxed and will show an item with no audio stream as having an unknown or damaged format. If your setup is one of them, MKVToolNix can mux a silent audio track into the file in one pass without re-encoding the picture, which is cheaper than converting the GIF again with different settings.

The stopping rule is worth stating plainly. If the animation is three seconds long and its purpose is to be posted somewhere, converting it to Matroska is effort spent on the wrong problem — it will sit in the library as an item nobody wants to browse to, and MP4 or WebM would have served the actual use better.

This conversion pays off when the GIF is long, when it is being kept rather than shared, and when the rest of the shelf is already Matroska. Consistency inside a library is worth something on its own: one container means one set of playback settings and one thing to check when something does not play.

The frames are read by the browser’s own image decoder and muxed into Matroska in the same tab. No part of the file is sent anywhere, there is no account, and there is no queue — which is the same reason people install FFmpeg for this job, without installing FFmpeg.

That decoder is not present in every browser. Where it is missing, the page says so and names browsers that have it, rather than quietly handing the file to a server to finish the job elsewhere.