Convert M4V to TIFF

M4V is Apple’s extension for iTunes Store video, and store purchases carry FairPlay encryption. An encrypted video cannot be decoded in a browser, so there is no frame to read and the conversion stops with a message saying nothing in the file could be converted. That is the lock speaking, not a corrupt file.

The origin of the file settles it. Bought or rented from the iTunes Store or the Apple TV app: locked, and nothing in any browser opens it. Exported from QuickTime, iMovie, Final Cut or Compressor, recorded by a camera or a phone, or supplied by a course or conference platform: not locked, and a frame comes out normally.

Because TIFF has been read by everything since 1986 and because the uncompressed variant has no ambiguity in it. An archive is written against a horizon of decades, and the question it is really asking is not "which format is best" but "which format will still open when nobody involved in this decision is still here".

That reasoning is why the output here is uncompressed baseline rather than LZW or Deflate. Those are smaller and readers agree on them less; JPEG-in-TIFF is a compressed image in a TIFF wrapper and defeats the point of the requirement entirely. Uncompressed is the variant no reader has ever refused.

The picture data is the pixel count times four bytes — eight bits each for red, green, blue and alpha — with a header of about a kilobyte in front. A 1920 by 1080 frame is 8.3 MB; a 3840 by 2160 frame is 33.2 MB; a 1280 by 720 frame is 3.7 MB.

The M4V’s own size, bitrate and duration have no effect on any of that. A two-minute clip and a two-hour film at the same resolution produce identically sized stills, because what is written is the decoded frame rather than anything the codec did on the way to it.

The conversion takes the frame being displayed at the timestamp you type: formally, the last frame whose own start time falls at or before that number of seconds. The default is 0, which is the first frame of the video, and for a file that opens on a title card or a black frame that is exactly the wrong picture.

Each conversion produces one image. For a file that needs several stills — an incident at three points, a sequence of screens — run it several times with different timestamps and keep a note of each. That note is worth more later than the images are.

It shows exactly what the video showed at that instant, at the video’s full resolution, without any further loss. That is the strongest claim available and it is a real one: the still is not a photograph of a screen, not a scaled screenshot, and not a re-compressed copy.

It is not more than the video was. The frame came through a codec that stored eight bits per channel, kept colour at reduced resolution, and spent fewer bits on frames where things were moving. A number plate or a face that is unreadable in the video is unreadable in the TIFF, and no format converts one into the other.

The output carries nothing that describes the recording: no capture date, no source file name, no position within the video, no colour profile. The pixels are read out of a decoder and everything the M4V knew about itself stays in the M4V. The one field the encoder does write is Software, and it says "Photopea (UTIF.js)" — the name of the library that assembled the file, not of anything that touched the footage.

Close that gap at the moment of extraction rather than later. Put the source file name and the timestamp into the image file name, and add proper fields with a metadata tool if the archive specifies them. A still that cannot be traced back to the second it came from is much weaker evidence of anything than one that can.

The file is RGB with no ICC profile attached. Video colour for HD material is conventionally Rec. 709, and an application opening the TIFF will assume its own default rather than being told.

For a records archive that is usually acceptable, because the point is a faithful record of the frame rather than a colour-managed reproduction. Where colour accuracy is part of what is being recorded — damage assessment, a product condition report — assign the source space explicitly in an editor and say in the file what was assigned.

Frames during fast movement carry motion blur that nobody saw at 25 frames a second and that dominates a still, and video encoders also allocate fewer bits to those frames. A moment where the camera and the subject are both still produces a sharper capture and a better-encoded one at the same time.

It costs nothing to try three timestamps a tenth of a second apart and compare. On material recorded handheld or from a moving vehicle, the difference between adjacent frames is often the difference between a usable record and one somebody will question.

The decode and the write both happen in the browser tab on your own processor. Nothing carrying the video is sent anywhere, which the network tab will confirm during a conversion, and the free tier takes files up to 100 MB.

For the material this page is used on that is the part that matters. Case files, insurance evidence, HR recordings and compliance video are frequently governed by rules about where a copy may exist, and a workflow with no server in it has no copy to account for.