Answers.Body: <p><em><strong>Note</strong>: 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.</em></p>
  <h2>Add <code>-profile:v high -level:v 5.1</code> (or your appropriate limitation) as a &quot;further limiter&quot;</h2>
  <p>within the other main constraints video dimension + framerate, implicit in the <code>-i input-video.mov</code> or explicit in the output arguments <code>-vf scale=WIDTH:HEIGHT -r FRAMERATE</code>.</p>
  <p><code>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 2560x1600-CR18-FPS50-High@5.1.mp4</code></p>
  <ol>
  <li><p>I think the basic limiters <strong>dimension</strong> and <strong>framerate</strong> by itself MUST comply with the profile and level you are targeting.</p>
  </li>
  <li><p>The arguments <code>-profile</code> and <code>-level</code> 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.</p>
  <ul>
  <li>If you state a very low <code>-profile</code> and <code>-level</code> but for a dimension/framerate combo way above that profile/level's maximums then ffmpeg / libx264 can do little.
  <ul>
  <li>According to mediainfo that video file then has the targeted profile/level declared in the video header (moov atom) but its contents contradict it.</li>
  </ul>
  </li>
  <li>So I guess the video players / chipsets / devices have some additional heuristics to skip such &quot;falsely labeled&quot; video files.
  <ul>
  <li>And as the next point shows, possible those heuristics possibly even falsely disqualify a video file, if carefully evaluated would qualify.</li>
  </ul>
  </li>
  </ul>
  </li>
  <li><p>On the concrete targeting device (iPhone 6S)</p>
  <ul>
  <li>I found only the vague spec: High@L5.1 and an exemplary maximum of 4K @ 30FPS.</li>
  <li>According to Wikipedia High@L5.1 should allow my 2560x1600 source as within the <code>2560×1920 @ 51.2 (9) </code> boundaries if I encode it at 50 FPS (below that 51.2), and the <code>-profile</code> and <code>-level</code> 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.
  <ul>
  <li>But the practical test on the iPhone 6S: Not playing back!</li>
  </ul>
  </li>
  <li>Interestingly the EXACT same command line, just swapping <code>-level:v</code> from <code>5.1</code> down to <code>5</code>, produced a video file of the EXACT same size in bytes. The 2 bytes which differ are the profile/level declaration flags (see screenshot).</li>
  <li>That High@L5 file then played back on the iPhone 6S.</li>
  <li>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.</li>
  </ul>
  </li>
  </ol>
  <p><img src="https://i.sstatic.net/63hv2.png" alt="ffmpeg - profile level difference only in header not video content" /></p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-07-27T13:44:19.273Z
Answers.LastActivityDate: 2023-07-27T13:44:19.273Z
Answers.UserDisplayName: porg
Body: <h2>Original Issue</h2>
  <p><code>ffmpeg -i macos-sreenrecording-2560x1600-h264-FPS60.mov -movflags faststart -an -c:v libx264 -crf 18 -preset veryslow 2560x1600-CR18-FPS60.mp4</code></p>
  <ul>
  <li>Yields an MP4 with H.264 at High@L6 (aka High Profile Level 6)</li>
  <li>❌ Does not play back on iPhones 6S, <a href="https://help.shopmoment.com/article/135-video-formats-for-ios" rel="nofollow noreferrer">whose maximum is High@L5.1 (4K @ 30 FPS)</a>.</li>
  </ul>
  <h3>Realized root cause and solution (in principle!)</h3>
  <ul>
  <li>Wikipedia lists these maximum values for <a href="https://en.wikipedia.org/wiki/Advanced_Video_Coding#Levels" rel="nofollow noreferrer">video Width×Height@Framerate(Stored Frames)</a> for Profile 5.1
  <ul>
  <li><code>1920×1080 @ 120.5 (16), 2560×1920 @ 51.2 (9), 3840×2160 @ 31.7 (5), ...</code></li>
  </ul>
  </li>
  <li> So I thought I have these viable alternatives:
  <ul>
  <li> Keep dimensions 2560x1600 and lower framerate from 60 to 50 FPS</li>
  <li> Keep the framerate of 60 FPS and reduce the dimensions from 2560x1600 to 1920x1200.</li>
  </ul>
  </li>
  </ul>
  <h2>Remaining issue (in practice &amp; theory)</h2>
  <p><code>ffmpeg -i 2560x1600-h264-FPS60.mov -movflags faststart -an -c:v libx264 -r 50 -vsync cfr -crf 18 -preset fast 2560x1600-CR18-FPS50.mp4</code></p>
  <ul>
  <li>With <code>-preset fast</code> according to <code>mediainfo</code> this yields an MP4 with H.264 at High Profile Level 5.1 with:
  <ul>
  <li>Format settings: CABAC / 4 Ref Frames</li>
  <li>Bit rate: 185 kb/s</li>
  </ul>
  </li>
  <li>If I change <code>-preset</code> to <code>veryslow</code> then according to <code>mediainfo</code> it becomes a High Profile Level 6 with:
  <ul>
  <li>Format settings: CABAC / 16 Ref Frames</li>
  <li>Bit rate: 179 kb/s</li>
  </ul>
  </li>
  </ul>
  <p><strong>Learning:</strong> The <strong>H.264 Profile Level</strong> seems to be <strong>not only determined</strong> by <em>video dimensions + framerate + average and/or peak bitrate</em>, <strong>but also by the reference frame count</strong>.</p>
  <h2>Remaining Question</h2>
  <p>How can I encode this video with the most CPU effort (for the best possible outcome, except placebo which is explictly &quot;too much&quot;) to remain High@L5.1 compatible with the maximum image dimensions and framerate?</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2023-07-27T06:20:55.357Z
Comments.Text: try to add `-level:v 5.1`
Comments.UserDisplayName: Баяр Гончикжапов
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2023-07-27T13:46:06.897Z
Comments.Text: Thanks! Tried this approach and put this into an [own answer](https://video.stackexchange.com/a/36712/35955). Would appreciate if you could help there clarify my remaining speculations/uncertainties.
Comments.UserDisplayName: porg
Tags: <ffmpeg><h.264><libx264>
Title: Why do different libx264 encoding presets yield different H264 profiles? For same video: Same source, same target dimension + framerate + CRF
UserDisplayName: porg
ThreadText: # Why do different libx264 encoding presets yield different H264 profiles? For same video: Same source, same target dimension + framerate + CRF
  
  (Asked by: username_0 on 2023-07-26)
  
  ## 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 High@L5.1 (4K @ 30 FPS)](https://help.shopmoment.com/article/135-video-formats-for-ios).
  
  ### Realized root cause and solution (in principle!)
  
  * Wikipedia lists these maximum values for [video Width×Height@Framerate(Stored Frames)](https://en.wikipedia.org/wiki/Advanced_Video_Coding#Levels) 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 High@L5.1 compatible with the maximum image dimensions and framerate?
  
  **Tags:** ffmpeg, h.264, libx264
  
  > **Comments:**
  > **username_1**: try to add `-level:v 5.1`  
  > **username_0**: Thanks! Tried this approach and put this into an [own answer](https://video.stackexchange.com/a/36712/35955). Would appreciate if you could help there clarify my remaining speculations/uncertainties.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2023-07-27. Score: 0
  
  ***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 2560x1600-CR18-FPS50-High@5.1.mp4`
  
  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: High@L5.1 and an exemplary maximum of 4K @ 30FPS.
     * According to Wikipedia High@L5.1 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.
  
  ![ffmpeg - profile level difference only in header not video content](https://i.sstatic.net/63hv2.png)
  
  
  ---
  
  