Add option to specify --qpmax

[Tom Vaughan]

https://twitter.com/donmelton requested this feature, which would place a hard upper limit on QP. While we're at it we might as well add --qpmin.

While this option is potentially dangerous in the hands of inexperienced users, it is a helpful feature for experts who are working to encode a specific video file that they are familiar with. The documentation should explain the dangers of using this setting.

We may want to display warning messages when x265's rate control wanted to exceed these limits, but was prevented from doing so.

[Don Melton]

@Ultradef, Thanks for opening this issue after our discussion on Twitter.

Yes, I definitely need a --qpmax option to set a minimum quality level for single-pass ABR encoding. Otherwise, single-pass ABR is not a viable choice.

Typically for single-pass ABR when using x264, I would do something like this:

x264 --bitrate 8000 --qpmax 34

Even with VBV constraints for level 4.0, I don't see underflows with these two options. And this is with complex and noisy content. But there's a significant increase in the quality for some portions of the video.

You can see this quality difference yourself easily if you have access to any ripped Blu-ray from an HBO TV program.

Just encode the "HBO logo" intro from something like "Game of Thrones." It's usually the first few seconds of an episode. Try it with and without --qpmax 34 on the command line.

Without --qpmax 34, the intro is a mess of blockiness. (And I don't mean the artificial blockiness of the logo animation.) You can see the same problem with x265.

Obviously, this quality problem with single-pass ABR occurs in other samples. The "HBO logo" intro is just the easiest way to demonstrate it.

And I'm sure the "magic" QP value of 34 is likely different for x265. But right now I can't even run tests to find the viable value.

[Deepthi Nandakumar]

Thanks for adding more colour here. We can certainly plan on implementing this depending on your use-case - is it ABR+VBV? Have you tried CRF? .

We have crf-max/min which performs similar quality capping in CRF mode, not absolute QP caps. In general, CRF also provides better quality results.

[Don Melton]

@nandaku2 Yes, it's ABR+VBV. But access to qpmax is necessary for ABR even if you don't apply VBV.

Yes, I've tried CRF. You may not recognize my name and avatar, but I'm the author of the video_transcoding Gem. And the default behavior of its transcode-video utility relies heavily on CRF mode, VBV constraints and crf-max when leveraging x264.

So, I'm very familiar with crf-max and Constrained VBR. :)

However, my transcode-video utility also has a modified ABR mode. And that mode requires control of qpmax to not suck.

I really want to port my tools to also leverage x265. But to do that, I need access to qpmax as well as crf-max.

Thanks.

[Deepthi Nandakumar]

Ok, very nice!

Do you empirically figure out the right qpmax value for a given bitrate/resolution, and that applies to all content? Or tune qpmax depending on content?

Essentially, I get that qpmax is a good workaround - but I'm trying to figure out if we can identify & fix the root cause (in ABR+VBV) rather than forcing our users to test and find the right qpmax value.

[Don Melton]

Currently the --abr option of transcode-video applies the same qpmax=34 value for all content. But I'm planning on changing that based on, as you say, bitrate and or resolution. Or possibly allowing users to specify a higher quality mode for ABR which would be implemented by lowering qpmax slightly. I've found that values down to about 30 are fairly safe for most low to medium complexity content.

So, I would rather be able to tweak qpmax than have it set to a fixed value.

That said, I'm interested in finding, as you say, the root cause of the quality degradation of ABR in both x264 and x265. ABR quality at a reasonable bitrate should never be that low compared to CRF. The purpose of ABR is to be predictive and, essentially, to set a minimum bitrate which can prevent, or at least mitigate, contouring and color banding.

[Stacey Spears]

Sorry, I think I just opened a duplicate request for this feature. I would say either qpmin and qpmax or even fixedqp.

It should still also honor the constraints and report under/over flow errors. For example, I want to set VBV and peak bitrate and if a maxqp of n value causes an issue, report it on the command line and I will manually adjust my QP value to remove the error.

In my case, I am encoding synthetic test patterns used to evaluate the playback pipeline, including display. Usually QP 0. Only time I have to go above QP 0 is when its really complex, such as a full screen zone plate. I still need to apply Blu-ray constraints or UHD BD in this case.

[Deepthi Nandakumar]

Issue #251 was marked as a duplicate of this issue.

[Don Melton]

@pramach2 and @Ultradef Why was this issue resolved without being fixed? And without explanation?

[Tom Vaughan]

Don,

The issue was fixed. See http://x265.readthedocs.io/en/default/cli.html#cmdoption--qpmax

Pradeep - when you close an issue as resolved, please indicate how exactly the issue was resolved.

Thanks,

Tom

[Stacey Spears]

I just tested this feature last week and it worked as expected. Maybe he resolved it without any detail.

[Don Melton]

@Ultradef and @StaceySpears Sweet! And thanks! I guess it's not in the release available from Homebrew and the Handbrake team then. My apologies. What version is this scheduled for or is it only available in HEAD?