Insensible "libx264" encoding default

[Jeremy Hopkinson]

Summary of the bug:
Trying to re-encode a video to play on an older TV and the video isn't being decoded with the high default, which is why I'm reaching back to more constrained profiles.

H.264 Video Encoding Guide states that:

"The -profile:v option limits the output to a specific H.264 profile. You usually do not need to use this option and the recommendation is to omit setting the profile which will allow x264 to automatically select the appropriate profile"

yet this profile option does not appear to be limiting it, and x264 is nevertheless automatically selecting an inappropriate bit depth.

What am I missing?

x264 [error]: main profile doesn't support a bit depth of 10
[libx264 @ 0000019ccf0a0c40] Error setting profile main.
[libx264 @ 0000019ccf0a0c40] Possible profiles: baseline main high high10 high422 high444
[vost#0:0/libx264 @ 0000019ccf09f400] [enc:libx264 @ 0000019ccf0a0640] Error while opening encoder - maybe incorrect parameters such as bit_rate, rate, width or height.
[vf#0:0 @ 0000019ccf09f8c0] Error sending frames to consumers: Invalid argument
[vf#0:0 @ 0000019ccf09f8c0] Task finished with error code: -22 (Invalid argument)
[vf#0:0 @ 0000019ccf09f8c0] Terminating thread with return code -22 (Invalid argument)
[vost#0:0/libx264 @ 0000019ccf09f400] [enc:libx264 @ 0000019ccf0a0640] Could not open encoder before EOF
[vost#0:0/libx264 @ 0000019ccf09f400] Task finished with error code: -22 (Invalid argument)
[vost#0:0/libx264 @ 0000019ccf09f400] Terminating thread with return code -22 (Invalid argument)
[out#0/mp4 @ 0000019ccf035000] Nothing was written into output file, because at least one of its streams received no packets.

How to reproduce:

% ffmpeg -i input -c:v libx264 -crf 18 -preset slow -tune animation -profile:v main -c:a copy output

ffmpeg version: Unsure, from file "ffmpeg-master-latest-win64-gpl.zip," latest from BtbN
built on 2024-10-20 13:01

Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker.

[MasterQuestionable]

͏    Try explicitly specify the "-pix_fmt yuv420p".

͏    And I guess it's very likely just your playback device doesn't support 10bpc.
͏    Not much to do with the Profile meta.
͏    See also: ​https://trac.ffmpeg.org/ticket/11110#comment:3

[Balling]

profile:v option does not always work and sometimes does not overwrite profile. For example in this example it fails: #9573

Profile high444 predictive is only forced by qp 0, it cannot be forced by -profile:v high444, also crf 0 does not force high444 profile and thus is not lossless. Maybe the cause is deprecation of high 444 itself in ITU spec in favour of predictive.

Indeed, ffmpeg -i ​https://trac.ffmpeg.org/raw-attachment/ticket/9573/test.mkv -c:v libx264 -preset veryfast -profile:v high444 high10profile.mp4

produces high10 5.1 profile even though I am trying to force high444.

Also profile level is incorrectly written when Nvidia encoder is in use, which is insane. ​https://trac.ffmpeg.org/ticket/6476#comment:12

And I guess it's very likely just your playback device doesn't support 10bpc.

ALMOST NOTHING supports hi10p of H.264. That is not really an argument. (I know Mediatek added it in 2022 and I think Apple M2, M3, M4 added it).

[MasterQuestionable]

͏    Most hardware decoders don't support 10bpc.
͏    But some devices may use software decoder (and very likely FFmpeg based).

͏    Regardless, I don't see much rationale of using > 8bpc as final archival.
͏    Scarcely real difference: ​https://trac.ffmpeg.org/ticket/11107#comment:1
͏    Let alone the lossy codecs' meddling...

[Jeremy Hopkinson]

Replying to MasterQuestionable:

͏    Try explicitly specify the "-pix_fmt yuv420p".

͏    And I guess it's very likely just your playback device doesn't support 10bpc.
͏    Not much to do with the Profile meta.
͏    See also: ​https://trac.ffmpeg.org/ticket/11110#comment:3

It worked to explicitly specify -pix_fmt yuv420p, and it works on my old TV. Thanks for solving that problem. I'm up and running.

However, broader point being the H.264 Video Encoding Guide should be fixed by TPTB to let users know the -profile:v option does not in fact limit the output to a specific H.264 profile, and that if you select a main or baseline profile you must force a lower bit depth with -pix_fmt yuv420p else error. The Encoding Guide is not just misleading about this, it's actually wrong.

[MasterQuestionable]

͏    There are issues in both the code and documentation... Somewhat troublesome to fix.