Convert MKV to TIFF

A camera system, a long-duration meeting capture or any recorder that expects to be interrupted has a specific requirement: the file has to remain usable if the power goes, the disk fills or the process is killed. Matroska writes its structure as it goes, so a recording that stops abruptly is still readable up to the moment it stopped. The same hours recorded straight to MP4 are frequently unrecoverable.

That is why the footage somebody needs a still from is so often an MKV rather than anything else, and it is also why these files are long — hours rather than minutes. The conversion below takes one frame from one moment, so almost all of the work is deciding which moment.

This is the part to settle before anything is filed. The image is written with no EXIF block at all: no capture date, no source filename, no position in the recording, no camera identifier, nothing. A photograph from a phone arrives carrying dozens of fields; a frame decoded out of a video has none to carry, and none are invented.

For an incident file or a claim that is a real gap and it has to be closed outside the file. Name the image after the recording and the timestamp as you download it, and record the same two facts in whatever accompanies it. If the camera burned a clock into the picture, that survives because it is part of the image — which is exactly why installers burn it in.

The TIFF is written as plain uncompressed baseline, which means four bytes per pixel and a short header. The size is therefore a multiplication rather than an estimate: a 1920 by 1080 frame is about 8 MB and a 3840 by 2160 frame is about 33 MB, identical for a busy picture and an empty corridor.

The reason for choosing that variant over a compressed one is compatibility. TIFF is less a format than a filing system for images and its readers disagree about a great deal — LZW is widely supported, Deflate is not universal, and JPEG-in-TIFF is a different image inside a TIFF wrapper. Uncompressed is the one thing every reader accepts, and for a file that has to be ingested by a system nobody in the room controls, that is worth more than the megabytes.

A video codec stores what changed and describes it as economically as it can. A recorder configured to keep a month of footage on a disk is running at a bitrate where a moving subject is a rough approximation, and a still lifted out of it preserves that approximation exactly. TIFF is faithful in the sense that it changes nothing — including nothing about how little was there.

So the frame is evidence of what the recording holds, and nothing more. Enlarging it adds no detail; software that appears to sharpen a face is generating pixels rather than recovering them, and a still produced that way is worse than useless in a file that anyone may later scrutinise. Where identification actually matters, the original recording is the artefact and the still is a pointer to it.

The timestamp box takes seconds from the start of the file and begins at zero, which on a continuous recording is the beginning of the shift rather than anything of interest. One hour ten minutes and twelve seconds is 4212, and decimals are accepted — 4212.4 lands at a specific fraction of a second, which is occasionally what it takes to catch a moment between two others.

The field goes up to 86400 seconds, a full day, so a long recording is not going to run out of range. If you name a time past the end, the conversion stops and reports how long the file actually is rather than quietly handing back the last frame it could reach — which on a records job is the behaviour you want, because a wrong frame that looks plausible is the expensive failure here.

The frame is written as ordinary RGB with no ICC profile attached, so any reader will treat the values as sRGB. TIFF as a format can carry CMYK, Lab, sixteen bits per channel and an embedded profile; none of that is present here, because none of it exists in a frame decoded off a canvas.

For a record that is almost always immaterial — the file is going into a system that will store and display it, not into a press. Where the destination is a print workflow that expects CMYK and a profile, the conversion those people need is one that happens in their own prepress software after this, and it is worth telling them what they are receiving rather than letting them assume.

Each run produces exactly one image. Where a report needs a sequence — the approach, the event, the aftermath — that is three runs at three timestamps, which is quick because the file is only being read rather than re-encoded, and tedious past about ten.

For a longer sequence, a desktop tool that extracts on an interval will do the whole span in one pass and is the right instrument for it. What this gives that an interval extraction does not is precision: you name the exact second that matters instead of taking every second and choosing afterwards, which for a file that has to be short and defensible is usually the better shape.

Only enough of the recording is read to reach the timestamp, and the decoding and the TIFF writing both happen inside the browser tab. Nothing carrying the footage is sent to a server, there is no account, and the network tab will show you that in ten seconds.

On this pair that is closer to a requirement than a feature. Recordings of identifiable people are personal data before they are anything else, and sending them to a converter found through a search result is a disclosure that somebody would have to justify. The free tier takes files up to 100 MB, which most continuous recordings exceed — for those, a player that saves a snapshot works on the file where it sits, and the TIFF can be made from that image here instead.