4

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

Improve this question
8
  • 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
    Mar 2, 2015 at 3:54
  • 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
    Mar 2, 2015 at 18:50
  • 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
    Mar 2, 2015 at 20:27
  • 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
    Mar 2, 2015 at 20:31
  • 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
    Mar 3, 2015 at 0:36

1 Answer 1

Reset to default
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).

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.

Improve this answer
5
  • 1
    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
    Mar 3, 2015 at 11:12
  • 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
    Mar 3, 2015 at 11:16
  • 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
    Mar 3, 2015 at 11:31
  • 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
    Mar 4, 2015 at 0:43
  • 1
    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
    Mar 4, 2015 at 1:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.