<p>Any decent encoder can hit a target bitrate (with 2pass), but still spend the bits intelligently to achieve similar quality throughout the file.  x264 2pass figures out what CRF will give the desired bitrate (pass1), and then uses it (pass2).  (source: Dark Shikari.  cf. the links I dug up for my answer on <a href="https://video.stackexchange.com/questions/14955/variable-bitrates-for-streaming">this question about VBR streaming</a>).</p>

<p>You only get CBR with x264 if <code>vbv-maxrate</code> = <code>bitrate</code>, and even then it's can be VBR within the buffer size.  (h.264 is never going to be strictly CBR like mp3 or something, unless your I frames look HORRIBLE :P)</p>

<p>However, you probably meant variable-across-clips, rather than the usual within-one-file meaning, because CFR as a quality target is clearly much better than blindly setting a target bitrate for many different sources.</p>

<p>(Is there a word for this?  flexible bitrate?  Other than target-quality, as opposed to target-bitrate.  CRF targets a heuristic for quality, not strictly a quality target.)</p>

<p>Anyway, in that case, I have no idea what other encoders support.  Lossless h.264 is probably the best format for sending files around.  It's significantly smaller than huffyuv or utvideo, and can support up to 10bit.  (actually, I think FFmpeg can decode higher bit depths, but x264 can only produce files up to 10bit.)  Or I guess you could get them to send you slightly-lossy pro-res files, if that's a lot easier for your workflows.</p>

<p>LordNeckBeard brings up the question of whether you're delivering these files directly to clients.  If that's the case, you should probably require that they encode with x264 with at least preset=slower, so you can just give them a crf value if you're already requiring x264.  The rate-distortion tradeoff matters for final files that you're going to stream many times.</p>

CC BY-SA 3.0
2015-03-03T11:12:35.403Z
Oh, one encoder-independent proxy for quality is average quantizer.  If they do use x264, they could just use a CRF below your required average QP.  (psy / AQ both raise quantizers, but gains perceived visual quality.)  x264 with very low subme can look worse at the same average QP (but this affects CRF, too).  Anyway, if you require that, and they DON'T use x264, it might be inconvenient for them to even find out.  ffmpeg's h.264 decoder doesn't keep stats to print average QP, but might export QP per frame so you could use `-vf codecview`.
Peter Cordes
CC BY-SA 3.0
2015-03-03T11:16:28.523Z
If they don't use x264, they could find some target quality mode if there is one, or maybe a fixed-QP mode (which would probably be worse RD, but at least of known quality).  Make sure you put your reasoning along with any such requirement.  i.e. "average QP < 14.  (Use an encoder setting that is well beyond visually transparent, as we will be re-encoding this.  For x264, crf = 12 would be ideal.)"  As long as they know the reason for your rule, they will know that the actual QP isn't what you care about, but rather visual quality.
Peter Cordes
CC BY-SA 3.0
2015-03-03T11:31:16.597Z
also, nvm, `codecview` is for visualizing motion vectors, and `showinfo` doesn't print per-frame average QP.  I looked over the whole list of ffmpeg's video filters, and none of them will print QP values :/
Peter Cordes
CC BY-SA 3.0
2015-03-04T00:43:01.283Z
Thanks for your answer. I think the take-home message is that if we want to have quality control for our web video we ask contractors to deliver masters and do the encoding ourselves.
stib
CC BY-SA 3.0
2015-03-04T01:46:34.877Z
Yeah, if storage space to archive the masters on your end isn't an issue, it's a LOT more useful to have them.  In the future, you can go back and produce encodes at different bitrates, or with VP9 / HEVC, or for different streaming scenarios, or do whatever else.  Or just change your settings for new encodes, without having to ask your contractors to update their settings.  If you did have your contractors do the encodes, you could always look at the x264 settings string it embeds in the h.264 string, to make sure they used high enough subme, and other settings.
Peter Cordes
CC BY-SA 3.0
2015-03-03T06:22:24.520Z
2015-03-03T06:22:24.520Z
2017-04-13T12:46:08.110Z
Peter Cordes
<p>Is there a way of specifying a quality setting for h.264 that is not software dependant?</p>

<p>I'm trying to help a colleague create a specification for outside contractors when they deliver video to us for use on our website as h.264-compressed mp4 files. We can specify a bitrate, but that doesn't work so well if we want variable bitrate / constant quality (CRF) compression.</p>

<p>If I knew they would be using libx264 to do the compression I could give them a range for the <code>-crf</code> setting, but they'll be using all sorts of software to do the compression. So how do I specify quality, except by saying something vague like "visually lossless" or "good quality"?</p>

CC BY-SA 3.0
2015-03-02T03:54:36.993Z
For VBR, can't you specify both the average bit rate and quality level (essentially, minimum bit rate)? If you have to meet a specific target, you may have to use CBR.
Jim Mack
CC BY-SA 3.0
2015-03-02T18:50:47.307Z
That's going to be challenging because not all encoders are equal, and even "video professionals" don't always know what they're doing, so your results will probably vary wildly. Can you require a lossless (or acceptable quality lossy) intermediate format and you can re-encode to your specifications?
llogan
CC BY-SA 3.0
2015-03-02T20:27:59.183Z
That's what I've been suggesting. I've never had to contact a contractor to get them to supply me with an mp4 because I've only got a ProRes master, but the reverse is quite common.
stib
CC BY-SA 3.0
2015-03-02T20:31:12.120Z
But just as an academic exercise, would specifying a profile + level do the job? I usually encode Main Profile for compatibility, could I specify level 3 or higher?
stib
CC BY-SA 3.0
2015-03-03T00:36:04.327Z
It depends on the devices you want to support if the video is going straight from contractor to client, and level limits may be encountered depending on the chosen level and the output parameters (Example. See the warnings in: `ffmpeg -f lavfi -i testsrc=s=hd720:d=5,format=yuv420p -c:v libx264 -level 3 output.mp4`)
llogan
CC BY-SA 3.0
2015-03-03T00:42:21.437Z
I only explicitly use profile and level if the playback device requires it. Otherwise I just let `x264` choose.
llogan
CC BY-SA 3.0
2015-03-03T06:11:51.470Z
Profile and level would be the same as specifying a bitrate, with additional restrictions on rez/fps, and on ref frames.  Also, for the love of science, get people to use High profile unless you actually want the videos to play on crappy old phones or other hardware players.  8x8dct helps a lot, esp. at HD rez.  (It probably helps less at very high bitrates, though, so for very very high-bitrate masters it's maybe not losing as much quality.)
Peter Cordes
CC BY-SA 3.0
2015-03-03T06:14:13.290Z
Also, level is just an upper bound on bitrate.  Setting a level limit for x264 just makes sure it doesn't exceed it;  It doesn't tell it that you want it to max out the bitrate as much as possible within that level.  I assume other encoders would have a level setting separate from quality / bitrate targets.
Peter Cordes
<ffmpeg><encoding><compression><h.264>
How to specify CRF quality settings for different encoding software
stib
# How to specify CRF quality settings for different encoding software

(Asked by: username_0 on 2015-03-02)

Is there a way of specifying a quality setting for h.264 that is not software dependant?

I'm trying to help a colleague create a specification for outside contractors when they deliver video to us for use on our website as h.264-compressed mp4 files. We can specify a bitrate, but that doesn't work so well if we want variable bitrate / constant quality (CRF) compression.

If I knew they would be using libx264 to do the compression I could give them a range for the `-crf` setting, but they'll be using all sorts of software to do the compression. So how do I specify quality, except by saying something vague like "visually lossless" or "good quality"?

**Tags:** ffmpeg, encoding, compression, h.264

> **Comments:**
> **username_1**: For VBR, can't you specify both the average bit rate and quality level (essentially, minimum bit rate)? If you have to meet a specific target, you may have to use CBR.  
> **username_2**: That's going to be challenging because not all encoders are equal, and even "video professionals" don't always know what they're doing, so your results will probably vary wildly. Can you require a lossless (or acceptable quality lossy) intermediate format and you can re-encode to your specifications?  
> **username_0**: That's what I've been suggesting. I've never had to contact a contractor to get them to supply me with an mp4 because I've only got a ProRes master, but the reverse is quite common.  
> **username_0**: But just as an academic exercise, would specifying a profile + level do the job? I usually encode Main Profile for compatibility, could I specify level 3 or higher?  
> **username_2**: It depends on the devices you want to support if the video is going straight from contractor to client, and level limits may be encountered depending on the chosen level and the output parameters (Example. See the warnings in: `ffmpeg -f lavfi -i testsrc=s=hd720:d=5,format=yuv420p -c:v libx264 -level 3 output.mp4`)  
> **username_2**: I only explicitly use profile and level if the playback device requires it. Otherwise I just let `x264` choose.  
> **username_3**: Profile and level would be the same as specifying a bitrate, with additional restrictions on rez/fps, and on ref frames.  Also, for the love of science, get people to use High profile unless you actually want the videos to play on crappy old phones or other hardware players.  8x8dct helps a lot, esp. at HD rez.  (It probably helps less at very high bitrates, though, so for very very high-bitrate masters it's maybe not losing as much quality.)  
> **username_3**: Also, level is just an upper bound on bitrate.  Setting a level limit for x264 just makes sure it doesn't exceed it;  It doesn't tell it that you want it to max out the bitrate as much as possible within that level.  I assume other encoders would have a level setting separate from quality / bitrate targets.  

---

## 1 answers

### Answer by username_3 on 2015-03-03. Score: 3

Any decent encoder can hit a target bitrate (with 2pass), but still spend the bits intelligently to achieve similar quality throughout the file. x264 2pass figures out what CRF will give the desired bitrate (pass1), and then uses it (pass2). (source: Dark Shikari. cf. the links I dug up for my answer on [this question about VBR streaming](https://video.stackexchange.com/questions/14955/variable-bitrates-for-streaming)).

You only get CBR with x264 if `vbv-maxrate` = `bitrate`, and even then it's can be VBR within the buffer size. (h.264 is never going to be strictly CBR like mp3 or something, unless your I frames look HORRIBLE :P)

However, you probably meant variable-across-clips, rather than the usual within-one-file meaning, because CFR as a quality target is clearly much better than blindly setting a target bitrate for many different sources.

(Is there a word for this? flexible bitrate? Other than target-quality, as opposed to target-bitrate. CRF targets a heuristic for quality, not strictly a quality target.)

Anyway, in that case, I have no idea what other encoders support. Lossless h.264 is probably the best format for sending files around. It's significantly smaller than huffyuv or utvideo, and can support up to 10bit. (actually, I think FFmpeg can decode higher bit depths, but x264 can only produce files up to 10bit.) Or I guess you could get them to send you slightly-lossy pro-res files, if that's a lot easier for your workflows.

LordNeckBeard brings up the question of whether you're delivering these files directly to clients. If that's the case, you should probably require that they encode with x264 with at least preset=slower, so you can just give them a crf value if you're already requiring x264. The rate-distortion tradeoff matters for final files that you're going to stream many times.

> **Comments:**
> **username_3**: Oh, one encoder-independent proxy for quality is average quantizer.  If they do use x264, they could just use a CRF below your required average QP.  (psy / AQ both raise quantizers, but gains perceived visual quality.)  x264 with very low subme can look worse at the same average QP (but this affects CRF, too).  Anyway, if you require that, and they DON'T use x264, it might be inconvenient for them to even find out.  ffmpeg's h.264 decoder doesn't keep stats to print average QP, but might export QP per frame so you could use `-vf codecview`.  
> **username_3**: If they don't use x264, they could find some target quality mode if there is one, or maybe a fixed-QP mode (which would probably be worse RD, but at least of known quality).  Make sure you put your reasoning along with any such requirement.  i.e. "average QP < 14.  (Use an encoder setting that is well beyond visually transparent, as we will be re-encoding this.  For x264, crf = 12 would be ideal.)"  As long as they know the reason for your rule, they will know that the actual QP isn't what you care about, but rather visual quality.  
> **username_3**: also, nvm, `codecview` is for visualizing motion vectors, and `showinfo` doesn't print per-frame average QP.  I looked over the whole list of ffmpeg's video filters, and none of them will print QP values :/  
> **username_0**: Thanks for your answer. I think the take-home message is that if we want to have quality control for our web video we ask contractors to deliver masters and do the encoding ourselves.  
> **username_3**: Yeah, if storage space to archive the masters on your end isn't an issue, it's a LOT more useful to have them.  In the future, you can go back and produce encodes at different bitrates, or with VP9 / HEVC, or for different streaming scenarios, or do whatever else.  Or just change your settings for new encodes, without having to ask your contractors to update their settings.  If you did have your contractors do the encodes, you could always look at the x264 settings string it embeds in the h.264 string, to make sure they used high enough subme, and other settings.  

---

