Why do different libx264 encoding presets yield different H264 profiles? For same video: Same source, same target dimension + framerate + CRF

Question

Original Issue

ffmpeg -i macos-sreenrecording-2560x1600-h264-FPS60.mov -movflags faststart -an -c:v libx264 -crf 18 -preset veryslow 2560x1600-CR18-FPS60.mp4

• Yields an MP4 with H.264 at High@L6 (aka High Profile Level 6)
• ❌ Does not play back on iPhones 6S, whose maximum is [email protected] (4K @ 30 FPS).

Realized root cause and solution (in principle!)

• Wikipedia lists these maximum values for video Width×Height@Framerate(Stored Frames) for Profile 5.1
  • 1920×1080 @ 120.5 (16), 2560×1920 @ 51.2 (9), 3840×2160 @ 31.7 (5), ...
• 💡 So I thought I have these viable alternatives:
  • 👉 Keep dimensions 2560x1600 and lower framerate from 60 to 50 FPS
  • 👉 Keep the framerate of 60 FPS and reduce the dimensions from 2560x1600 to 1920x1200.

Remaining issue (in practice & theory)

ffmpeg -i 2560x1600-h264-FPS60.mov -movflags faststart -an -c:v libx264 -r 50 -vsync cfr -crf 18 -preset fast 2560x1600-CR18-FPS50.mp4

• With -preset fast according to mediainfo this yields an MP4 with H.264 at High Profile Level 5.1 with:
  • Format settings: CABAC / 4 Ref Frames
  • Bit rate: 185 kb/s
• If I change -preset to veryslow then according to mediainfo it becomes a High Profile Level 6 with:
  • Format settings: CABAC / 16 Ref Frames
  • Bit rate: 179 kb/s

Learning: The H.264 Profile Level seems to be not only determined by video dimensions + framerate + average and/or peak bitrate, but also by the reference frame count.

Remaining Question

How can I encode this video with the most CPU effort (for the best possible outcome, except placebo which is explictly "too much") to remain [email protected] compatible with the maximum image dimensions and framerate?

Answer 1

Note: Take this my answer with a grain of salt. Derived from lots of trial'n'error observations in combination with some knowhow of video encoding in general and ffmpeg in particular. But I'm in no way an expert. Would love if someone can chime in and give the exact explanations.

Add -profile:v high -level:v 5.1 (or your appropriate limitation) as a "further limiter"

within the other main constraints video dimension + framerate, implicit in the -i input-video.mov or explicit in the output arguments -vf scale=WIDTH:HEIGHT -r FRAMERATE.

ffmpeg -i macos-sreenrecording-2560x1600-h264-FPS60.mov -movflags faststart -an -c:v libx264 -crf 18 -preset fast -r 50 -vsync cfr -profile:v high -level:v 5.1 [email protected]

1. I think the basic limiters dimension and framerate by itself MUST comply with the profile and level you are targeting.

2. The arguments -profile and -level seem to be able to just make some other tweaks WITHIN that constraints (mainly the reference framecount, what I could observe). But they can not magically make it conform if the outer constraints break the profile/level limit.

   • If you state a very low -profile and -level but for a dimension/framerate combo way above that profile/level's maximums then ffmpeg / libx264 can do little.
     • According to mediainfo that video file then has the targeted profile/level declared in the video header (moov atom) but its contents contradict it.
   • So I guess the video players / chipsets / devices have some additional heuristics to skip such "falsely labeled" video files.
     • And as the next point shows, possible those heuristics possibly even falsely disqualify a video file, if carefully evaluated would qualify.

3. On the concrete targeting device (iPhone 6S)

   • I found only the vague spec: [email protected] and an exemplary maximum of 4K @ 30FPS.
   • According to Wikipedia [email protected] should allow my 2560x1600 source as within the 2560×1920 @ 51.2 (9) boundaries if I encode it at 50 FPS (below that 51.2), and the -profile and -level then make sure, that the last variables (which I don't state explicitly), such as the reference frame amount, stay within the maximum, in the case of High@L5 ref=9 or lower.
     • But the practical test on the iPhone 6S: Not playing back!
   • Interestingly the EXACT same command line, just swapping -level:v from 5.1 down to 5, produced a video file of the EXACT same size in bytes. The 2 bytes which differ are the profile/level declaration flags (see screenshot).
   • That High@L5 file then played back on the iPhone 6S.
   • So if you don't know the exact limitation, it's a guesswork, and sometimes lowering the -level, in practice creates the same video, just with a different flag, and by this if passes a video player's pre-check.