Aspect ratio, SAR and DAR

A file plays correctly in VLC and squashed in a browser. Nothing is corrupt, nobody resized anything, and both players are behaving as designed. The cause is that video files carry more than one idea of shape, and not every tool respects all of them.

Three ratios, not one

Storage aspect ratio (SAR-as-storage) is simply the pixel dimensions: 1920x1080 stores a 16:9 rectangle of samples.

Sample aspect ratio (SAR) is the shape of an individual pixel. Usually 1:1, meaning square pixels, in which case nothing interesting happens. When it is not 1:1, the pixels are rectangles and the picture must be stretched at playback to look right.

Display aspect ratio (DAR) is what the viewer should see, and it is the product of the other two: DAR = storage ratio x SAR.

The confusing part is that FFmpeg uses “SAR” for sample aspect ratio while much of the surrounding world uses it for storage aspect ratio. When reading any tool’s output, check which it means.

Where non-square pixels come from

They are a legacy of broadcast television, where the sampling grid did not match the display shape. DVD is the canonical example: a PAL DVD stores 720x576, whose raw ratio is 5:4, but the content is meant to be seen as 4:3 or 16:9. The player stretches horizontally using the SAR the file declares.

Anamorphic cinematography does the same thing optically, squeezing a wide image onto a narrower sensor with a lens and unsqueezing it in post.

Modern content is overwhelmingly square-pixel, but non-square SAR survives in broadcast, in DVD and Blu-ray rips, and in some camera formats, and it survives long enough to ruin a transcode.

The failure modes

A player ignores SAR. The picture appears horizontally squashed or stretched. Browsers historically handled SAR less reliably than dedicated players, which is exactly the “fine in VLC, wrong on the web” report.

A transcode drops SAR. Scale a 720x576 anamorphic file to 640x480 without accounting for the pixel shape and you have baked in the wrong geometry permanently.

A tool bakes SAR in when it should not, or vice versa. Both directions produce a file that is correct for one player and wrong for another.

Rotation metadata compounds it. A phone video that carries a rotation flag and non-square pixels can be wrong in two independent ways, which is why the rotate page treats the metadata and pixel approaches as separate decisions.

Diagnosing and fixing

Check what the file claims:

ffprobe -v error -select_streams v -show_entries stream=width,height,sample_aspect_ratio,display_aspect_ratio -of default=nw=1 input.mp4

If sample_aspect_ratio is 1:1, aspect ratio is not your problem. If it is anything else, the file needs that stretch applied somewhere.

To bake it in (make the pixels square, so every player agrees):

ffmpeg -i input.mp4 -vf "scale=iw*sar:ih,setsar=1" -c:a copy output.mp4

That multiplies the width by the pixel aspect and then declares square pixels. The result is a file no player can misinterpret, which is the right outcome for anything web-bound.

To correct a wrong tag without touching pixels, -aspect 16:9 sets the display ratio in the container, and setsar/setdar set it at the filter level. These are metadata edits; they are instant and lossless, and they only work if the pixels underneath were right all along.

Letterboxing and the other kind of wrong shape

Aspect ratio problems get confused with letterboxing, and they are unrelated. Black bars are real pixels in the image, baked in because content of one shape was placed in a frame of another. No metadata will remove them; only cropping will, which is what the crop page covers. If your picture is the right shape but surrounded by bars, that is letterboxing. If the picture itself is squeezed, that is SAR.