Q:

How to specify CRF quality settings for different encoding software

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"?

A:

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).
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.

