Answers.Body: <p>I've noticed that my HEVC h.265 readout/log in ffmpeg wasn't showing anything other than 0 for the q value during the transcode. Yeah, makes it difficult to evaluate quality during an encode.</p>
  
  <p>For h264, I find that the q value is always 4-6 higher than my stated crf. If crf is 18, my q during transcode might be 24. But that might be an averaging, the verbosity of the readout isn't showing you all frames. I'm guessing we are seeing an averaging of what is held in buffer verifier.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-12-18T02:20:03.107Z
Answers.LastActivityDate: 2015-12-18T02:20:03.107Z
Answers.UserDisplayName: Nick Spiropoulos
Answers.Body: <p>Your rate control mode is CRF, so there's no target bitrate to hit. And for a value of 23, QP of 29 is what I normally see used. Ultimately, the test is whether the video <em>looks</em> acceptable.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-12-07T16:25:02.763Z
Answers.LastActivityDate: 2015-12-07T16:25:02.763Z
Answers.UserDisplayName: Gyan
Body: <p>I'm trying out encoding video with ffmpeg using <code>x264</code> on a NAS machine with a 2.4 GHz processor. This yields a terminal output that has a high number in the <code>q=</code> parameter:</p>
  
  <p><code>frame=  236 fps=0.2 q=29.0 size=    1038kB time=00:00:08.82 bitrate= 963.4kbits/</code></p>
  
  <p>When I encode using <code>x265</code> on my standard computer, I get something that looks like this:</p>
  
  <p><code>frame=67350 fps=0.7 q=-0.0 size=  416991kB time=00:37:28.41 bitrate=1519.3kbits/</code></p>
  
  <p>It is my understanding that <code>q=</code> stands for quality, and should probably be as close to <code>0</code> as possible, while a low number close to <code>q=31</code> indicates poor quality and that ffmpeg has difficulties reaching an acceptable bitrate.</p>
  
  <p>Is this something specific to <code>x264</code> or is it that my settings for the NAS machine are too demanding? The video sources are 1080p at 30 fps.</p>
  
  <pre><code>ffmpeg -i "$i" -c:v libx264 -preset veryslow -crf 23 -af "volume=25dB, highpass=f=200, equalizer=f=50:width_type=h:width=100:g=-15" -c:a aac -strict experimental -b:a 192k
  </code></pre>
  
  <p>Should I be concerned about this, and what can be done about it?</p>
  
Tags: <ffmpeg>
Title: FFmpeg: What is an acceptable value for the q= parameter?
UserDisplayName: P A N
ThreadText: # FFmpeg: What is an acceptable value for the q= parameter?
  
  (Asked by: username_0 on 2015-12-07)
  
  I'm trying out encoding video with ffmpeg using `x264` on a NAS machine with a 2.4 GHz processor. This yields a terminal output that has a high number in the `q=` parameter:
  
  `frame= 236 fps=0.2 q=29.0 size= 1038kB time=00:00:08.82 bitrate= 963.4kbits/`
  
  When I encode using `x265` on my standard computer, I get something that looks like this:
  
  `frame=67350 fps=0.7 q=-0.0 size= 416991kB time=00:37:28.41 bitrate=1519.3kbits/`
  
  It is my understanding that `q=` stands for quality, and should probably be as close to `0` as possible, while a low number close to `q=31` indicates poor quality and that ffmpeg has difficulties reaching an acceptable bitrate.
  
  Is this something specific to `x264` or is it that my settings for the NAS machine are too demanding? The video sources are 1080p at 30 fps.
  
  ```
  ffmpeg -i "$i" -c:v libx264 -preset veryslow -crf 23 -af "volume=25dB, highpass=f=200, equalizer=f=50:width_type=h:width=100:g=-15" -c:a aac -strict experimental -b:a 192k
  
  ```
  
  Should I be concerned about this, and what can be done about it?
  
  **Tags:** ffmpeg
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2015-12-07. Score: 3 | Accepted answer
  
  Your rate control mode is CRF, so there's no target bitrate to hit. And for a value of 23, QP of 29 is what I normally see used. Ultimately, the test is whether the video *looks* acceptable.
  
  
  ---
  
  ### Answer by username_1 on 2015-12-18. Score: 1
  
  I've noticed that my HEVC h.265 readout/log in ffmpeg wasn't showing anything other than 0 for the q value during the transcode. Yeah, makes it difficult to evaluate quality during an encode.
  
  For h264, I find that the q value is always 4-6 higher than my stated crf. If crf is 18, my q during transcode might be 24. But that might be an averaging, the verbosity of the readout isn't showing you all frames. I'm guessing we are seeing an averaging of what is held in buffer verifier.
  
  
  ---
  
  