On: FFmpeg 6.0

[ttflee]

You need `-pix_fmt yuv420p` for an iPhone to recognize a ffmpeg-encoded video file.

[jeroenhd → ttflee]

Do you happen to know why? Is this a hardware decode limitation perhaps, or a bug in the standard decoder?

[izacus → jeroenhd]

YUV420p is the only pixel format that all H.264 compatible decoders MUST support. Other formats are optional.

In practice that means that most hardware decoders (not just iPhones, also other phones, TVs, older PC GPUs) won't be able to decode YUV 4:2:2 or YUV 4:4:4 videos.

It's kinda annoying, since YUV420 really messes up red text in screen captures for example.

You need this parameter to force ffmpeg to convert the color space if your input isn't YUV420P (it defaults to keeping the input pixel format to avoid quality loss).

[thrdbndndn → izacus]

>since YUV420 really messes up red text in screen captures for example

Is there an detailed explanation why red is especially bad after chroma subsampling? Have been wondering about this for awhile.

I assume it's because red has low brightness/luminance (no idea if correct or not)?

[klodolph → thrdbndndn]

Yes, it’s because red is dim. Dark blue (like, RGB 0, 0, 255) also suffers, perhaps worse, but that shade of blue is hard to reaf even when it is reproduced perfectly.

[brigade → jeroenhd]

The capture pixel format depends on device - I think 4:2:2 is pretty common for webcams, which in H.264 requires profiles that aren’t widely implemented outside of x264 and ffmpeg.

[867-5309 → jeroenhd]

licensing for a non-free closed-source platform

[djkoolaide → ttflee]

and if you're encoding an x265 file, it needs

-tag:v hvc1

for iphone/quicktime to recognize it.

[onion2k → ttflee]

You also need that same parameter for transparent videos.