Answers.Body: <p>Here is my understanding of FFMPEG, there are 4 settings for VQ, and they are &quot;codec&quot;, &quot;crf&quot;, &quot;preset&quot;, and &quot;tune&quot;. For the &quot;codec&quot;, FFMPEG does not do well on VP9; the others are H.264 and H.265. For the &quot;tune&quot;, i prefer &quot;film&quot; for H.264 and &quot;grain&quot; for H.265. &quot;crf&quot; and &quot;preset&quot; can get the VQ excellent but there are drawbacks:long encoding time and large file size (bitrate)</p>
  <p>&quot;codec&quot; takes care of the bitrate, H.265 has smaller file size(bitrate) that retains same level of VQ but longer transcoding time.</p>
  <p>&quot;crf&quot; takes care of the quantization and the bitrate, the smaller the crf, the better the video quality, but the longer the transcoding time, and larger the file size.</p>
  <p>&quot;preset&quot; takes care of the bitrate, the slower the preset, the smaller the file size(bitrate), but the longer the transcoding time</p>
  <p>Get back to your scenario - the quick movement video, we concern with the high frequency content. We don't want to see blocky images; therefore, we need higher bitrate, but we want reasonable transcoding time.</p>
  <p>Therefore, i prefer H.265 &quot;codec&quot; and &quot;tune&quot; grain. Then we need to tweak the &quot;crf&quot; and &quot;preset&quot; based on the SSIM and PSNR results. I had done some experiments on the MainConcept sample stream (1080p content)</p>
  <ul>
  <li>Default) codec=h.264 crt=23, preset=medium, the transcoding took <em>27.9s</em> the bitrate=<em>3118kb/s</em>, the SSIM=<em>0.994413</em>, PSNR=<em>48.644</em></li>
  <li>Setting 1) codec=H.265, crt=23, preset=medium, tune=grain, the transcoding took 130s, the bite 3949kb/s, the SSIM=0.99487, PSNR=50.894298</li>
  <li>Setting 2) codec=H.265, crt=1, preset=medium, tune=grain, the transcoding took 202.37s, bitrate=<strong>60883kb/s</strong>, SSIM=<em>0.999738</em>, PSNR=<em>65.497223</em></li>
  <li>Setting 3) codec=H.265, crt=23, preset=slow, tune=grain, the transcoding took 329.36s, bitrate=<em>4338kb/s</em>, SSIM=<em>0.9952</em>, PSNR=<em>51.452838</em></li>
  </ul>
  <p>Setting 3) has better VQ performance with acceptable drawbacks or you may keep tweaking the &quot;crt&quot; and &quot;preset&quot; to get to the point that reaches your acceptable transcoding time and the bitrate results.</p>
  <p>Good luck!</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-11-01T17:45:34.783Z
Answers.Text: Time is not of the matter: I can run all encodes with `-preset veryslow`. I appreciate the idea that `-tune grain` could indeed improve quick scenes and will experiment with that. In addition, I would be strongly interested in how I can configure a variable bitrate encoding that indeed distributes more bitrate to or dials up quality in quick scenes. Perhaps you or someone else can elaborate on this.
Answers.UserDisplayName: XZS
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-11-02T10:43:14.267Z
Answers.Text: Those commands are vbr, 
  
  Streams with no motion - no motion vectors & residual - low bitrate
  Streams with motion - yes motion vectors & residual - high bitrate
  
  Not sure what do you want to achieve here?
Answers.UserDisplayName: xer-rex
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-10-27T14:59:39.847Z
Answers.LastActivityDate: 2020-10-27T23:53:04.583Z
Answers.LastEditDate: 2020-10-27T23:53:04.583Z
Answers.UserDisplayName: xer-rex
Body: <p>I gathered the following rate control algorithms are commonly used when encoding modern video formats like h264, HEVC or VP9.</p>
  <ul>
  <li>With a <strong>constant quantizer</strong> (<code>-qp</code> in terms of <code>ffmpeg</code>) all frames are encoded with the same compression ratio. Any still frame one would extract from the resulting video should come out to the same visual quality, regardless of how movement-intense or complex of a scene it is from.</li>
  <li>A <strong>constant rate factor</strong> (the <code>-crf</code> parameter) applies more compression to complex parts to in turn leave simple scenes relatively uncompressed. Thus more artifacts are introduced in e.g. quick moving shots, which in common application is less noticeable to the human eye, achieving a good subjective quality while saving on file size.</li>
  <li>The third variant is to target a specific file size with two passes of <strong>variable bitrate</strong> (<code>-b</code>). The first pass collects data on each frame, so that the second pass then can allocate more bits to the parts of the video that are hard to retain quality otherwise. This effectively does the inverse of CRF, assigning more quality to complex scenes.</li>
  </ul>
  <p>I am looking for a strategy to archive videos wherein the movement-heavy scenes are actually most important, may even be stopped, zoomed in on and analyzed for details, whereas slow or static content is less of interest. Am I right to look to two-pass VBR to achieve the best encoding in this regard?</p>
  <p>Should my understanding of any of the above methods be mislead in the first place, feel free to correct me. Other hints for encoding movement with good quality are also appreciated. I am especially unsure whether two-pass variable bitrate indeed leads to a heavier distribution of bitrate towards quick scenes and would appreciate if someone could confirm this with any documentation.</p>
  
Tags: <ffmpeg><encoding><bitrate>
Title: Which rate control algorithm best preserves quick movement?
UserDisplayName: XZS
ThreadText: # Which rate control algorithm best preserves quick movement?
  
  (Asked by: username_0 on 2020-10-27)
  
  I gathered the following rate control algorithms are commonly used when encoding modern video formats like h264, HEVC or VP9.
  
  * With a **constant quantizer** (`-qp` in terms of `ffmpeg`) all frames are encoded with the same compression ratio. Any still frame one would extract from the resulting video should come out to the same visual quality, regardless of how movement-intense or complex of a scene it is from.
  * A **constant rate factor** (the `-crf` parameter) applies more compression to complex parts to in turn leave simple scenes relatively uncompressed. Thus more artifacts are introduced in e.g. quick moving shots, which in common application is less noticeable to the human eye, achieving a good subjective quality while saving on file size.
  * The third variant is to target a specific file size with two passes of **variable bitrate** (`-b`). The first pass collects data on each frame, so that the second pass then can allocate more bits to the parts of the video that are hard to retain quality otherwise. This effectively does the inverse of CRF, assigning more quality to complex scenes.
  
  I am looking for a strategy to archive videos wherein the movement-heavy scenes are actually most important, may even be stopped, zoomed in on and analyzed for details, whereas slow or static content is less of interest. Am I right to look to two-pass VBR to achieve the best encoding in this regard?
  
  Should my understanding of any of the above methods be mislead in the first place, feel free to correct me. Other hints for encoding movement with good quality are also appreciated. I am especially unsure whether two-pass variable bitrate indeed leads to a heavier distribution of bitrate towards quick scenes and would appreciate if someone could confirm this with any documentation.
  
  **Tags:** ffmpeg, encoding, bitrate
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2020-10-27. Score: 0
  
  Here is my understanding of FFMPEG, there are 4 settings for VQ, and they are "codec", "crf", "preset", and "tune". For the "codec", FFMPEG does not do well on VP9; the others are H.264 and H.265. For the "tune", i prefer "film" for H.264 and "grain" for H.265. "crf" and "preset" can get the VQ excellent but there are drawbacks:long encoding time and large file size (bitrate)
  
  "codec" takes care of the bitrate, H.265 has smaller file size(bitrate) that retains same level of VQ but longer transcoding time.
  
  "crf" takes care of the quantization and the bitrate, the smaller the crf, the better the video quality, but the longer the transcoding time, and larger the file size.
  
  "preset" takes care of the bitrate, the slower the preset, the smaller the file size(bitrate), but the longer the transcoding time
  
  Get back to your scenario - the quick movement video, we concern with the high frequency content. We don't want to see blocky images; therefore, we need higher bitrate, but we want reasonable transcoding time.
  
  Therefore, i prefer H.265 "codec" and "tune" grain. Then we need to tweak the "crf" and "preset" based on the SSIM and PSNR results. I had done some experiments on the MainConcept sample stream (1080p content)
  
  * Default) codec=h.264 crt=23, preset=medium, the transcoding took *27.9s* the bitrate=*3118kb/s*, the SSIM=*0.994413*, PSNR=*48.644*
  * Setting 1) codec=H.265, crt=23, preset=medium, tune=grain, the transcoding took 130s, the bite 3949kb/s, the SSIM=0.99487, PSNR=50.894298
  * Setting 2) codec=H.265, crt=1, preset=medium, tune=grain, the transcoding took 202.37s, bitrate=**60883kb/s**, SSIM=*0.999738*, PSNR=*65.497223*
  * Setting 3) codec=H.265, crt=23, preset=slow, tune=grain, the transcoding took 329.36s, bitrate=*4338kb/s*, SSIM=*0.9952*, PSNR=*51.452838*
  
  Setting 3) has better VQ performance with acceptable drawbacks or you may keep tweaking the "crt" and "preset" to get to the point that reaches your acceptable transcoding time and the bitrate results.
  
  Good luck!
  
  > **Comments:**
  > **username_0**: Time is not of the matter: I can run all encodes with `-preset veryslow`. I appreciate the idea that `-tune grain` could indeed improve quick scenes and will experiment with that. In addition, I would be strongly interested in how I can configure a variable bitrate encoding that indeed distributes more bitrate to or dials up quality in quick scenes. Perhaps you or someone else can elaborate on this.  
  > **username_1**: Those commands are vbr,   Streams with no motion - no motion vectors & residual - low bitrate Streams with motion - yes motion vectors & residual - high bitrate  Not sure what do you want to achieve here?  
  
  ---
  
  