Why an MP4 will not play, and what a container really is

An MP4 that will not play is rarely corrupt. The extension names only the container, the wrapper holding the streams and their timestamps. What must be decoded is the codec inside, and the same .mp4 can hold H.264 that plays on a decade old phone or AV1 that a two year old television cannot touch. That is why one MP4 plays and another does not.

Two questions apply to any video file: what box is it in, and how is the picture compressed. Changing the box is usually free; changing the compression never is.

A container is a box, a codec is the picture

MKV is the permissive one, fine for archives and poor for delivery: a valid MKV can hold a combination no browser will open. MOV and MP4 share most of their structure, so moving between the two is often only a rewrite of the index. Inspect the file:

input.mp4
  Stream #0:0  Video  h264 (High)   1920x1080  30 fps  4200 kb/s
  Stream #0:1  Audio  aac  (LC)     48000 Hz   stereo   128 kb/s

The word after "Video" is what matters. The word "mp4" tells you almost nothing.

Which codec plays where

H.265 is technically strong and commercially awkward, so support splits along vendor lines rather than technical ones. AV1 compresses best and encodes far more slowly, sometimes by an order of magnitude, so it suits video encoded once and watched often. For an unknown audience, H.264 in MP4 remains the answer, and Compress Video targets it.

Bitrate, resolution and frame rate

Bitrate is bits per second of output, and it alone sets file size: multiply by duration and you have the file.

1920 x 1080 x 30 fps x 3 bytes = about 186 MB per second raw
delivered at 4 Mb/s            = about 0.5 MB per second

Doubling the resolution quadruples the pixel count but not the bits needed, because neighbouring pixels in a bigger frame are more alike and compress better. Expect two to three times as many, so halving width and height is among the cheapest ways to shrink a file: that is Resize Video, and Crop Video discards pixels outright. Frame rate is gentler, adding 20 to 40% from 30 to 60 rather than 100%, and Change Video Speed shortens the timeline instead.

Three ways to control the rate:

• Constant bitrate holds one rate throughout: static shots waste bits, fast motion falls apart. It suits links with a hard ceiling.
• Variable bitrate with a target averages out, letting scenes borrow from each other. Size is predictable, so use it when output must fit a limit.
• Constant quality, usually a CRF value, fixes quality and lets bitrate go where it needs to. Size is unpredictable, quality is even, and it is the default for anything watched rather than streamed.

For H.264 the CRF scale runs 0 to 51, lower being better: 18 is near indistinguishable from the source, 23 a sane default, past 28 motion falls apart. The scale is not shared between codecs.

Keyframes, and why a trim is sometimes free

An I frame, or keyframe, is a complete picture that decodes on its own. A P frame stores only what changed from an earlier frame. A B frame predicts from both an earlier and a later frame, which compresses best and is why decoders sometimes hold frames back before display.

A keyframe plus its dependants is a group of pictures, and web encoders place one every two seconds or so. Cut mid group and surviving frames refer to a picture no longer in the file, which is why trimming has two modes. Copying streams is instant and lossless but lands only on a keyframe, so the start can drift by up to the group length; re-encoding puts a keyframe where you asked, costing time and quality. Trim Video offers both; copy unless the exact frame matters.

Re-encoding costs quality because every lossy pass discards what the model considers least visible. Encode again and the second pass treats the first pass artefacts as real detail, preserving them and adding its own, so error compounds across generations. Copy the streams when only the container changes, and copy the picture when only the audio goes, which is what Mute Video does. Rotate Video can set a rotation flag instead of turning pixels, though players that ignore it show the original orientation. When pixels must change, change everything in one pass.

The audio track is the other half

Audio is a separate stream with its own codec, sample rate and channel layout, and a common reason a file will not play. A browser that decodes the H.264 picture happily may not decode AC-3 or DTS surround, leaving silence or a hard failure on the whole file. Disc rips in MKV fail this way constantly.

Sample rate is how often the waveform was measured: 44100 Hz from CD, 48000 Hz the video standard. AAC at 48000 Hz stereo is the safe delivery choice, near 128 kb/s for speech and 192 kb/s for music. Extract Audio pulls a track out as MP3, WAV, AAC or Opus.

Turning video into a GIF

GIF is a still image format from 1987 with animation bolted on and no real motion compensation. Each frame is compressed largely on its own, so five seconds can run to several megabytes where the same clip as a silent MP4 is a couple of hundred kilobytes. It is capped at 256 colours per frame, has one bit of transparency, and no audio.

The colour limit is where quality is won or lost. A generic fixed palette bands gradients and forces heavy dithering, and that noise is close to random, so it compresses badly and inflates the file. Building a palette from the clip itself, then mapping frames onto it, gives a better picture and often a smaller file; Video to GIF does that pass. Keep GIFs short and narrow: two or three seconds, 480 to 640 pixels wide, 10 to 15 frames per second. If the destination accepts video, send a muted MP4.

Settings that work for the web

• H.264 in MP4 with AAC audio for anything that must simply play.
• CRF near 23, down to 20 for screen recordings with fine text, up to 26 for background footage.
• Resize to the width it will be displayed at, before compressing rather than after.
• Enable faststart, so the index sits at the front and playback begins before the download finishes.

Everything here runs in the browser on your own machine, so nothing is uploaded and the limit is memory, not a server quota. Decode buffers for a long 4K file can exhaust a tab, so trim first and resize second.