Proposal to add a "simple" ratecontrol system

[lisamelton]

Proposal to add a "simple" ratecontrol system

One feature that makes my transcode-video tool unique is the special, or default, ratecontrol system it implements to produce consistent high quality output at a reasonable size. However, that implementation does have some undesirable side effects:

• Annoying VBV underflow warnings when the output bitrate exceeds the target, i.e. the VBV maximum bitrate. The number of these warnings vary, but for some videos it can be thousands.
• Inability to signal Hypothetical Reference Decoder (HRD) information in metadata because that VBV maximum bitrate cannot be honored.
• Larger than desired bitrates for certain content, sometimes 50% or more above the target. This is particularly annoying when you're already using the --target big option and argument.

These side effects are all caused by my special ratecontrol system using a maximum CRF (crf-max) value of 25 and a maximum quantizer (qpmax) value of 34 to maintain quality.

My average bitrate (ABR) ratecontrol system, enabled via the --abr option, does not have any of these side effects. But it has other issues. ABR is slightly more prone to color banding, while blockiness is a risk in some peculiar situations.

It's time to try something new to eliminate these side effects, so I'm proposing an additional, simplified version of my special ratecontrol system which does not manipulate crf-max or qpmax.

Basically this new ratecontrol system would set the values of vbv_maxrate and vbv_bufsize to the target bitrate and the value of crf to 1, the highest quality constant ratefactor for lossy transcoding.

Until recently, such a simple approach could produce unpleasant visual distortion or noise due to the crf value fluctuating too rapidly while trying fit the output bitrate below vbv_maxrate.

That risk is signifcantly reduced by the improved x264 video encoder included in HandBrake version 1.1.0 and later.

And that risk is also lowered if vbv_bufsize is set to the same value as vbv_maxrate. This is different from my special ratecontrol system which doubles vbv_bufsize.

(Please note that the implementation of this proposal is not the same as an older experimental, and now removed, ratecontrol system which was available via a poorly-named --cvbr option.)

This new implementation would also signal HRD information in metadata via nal-hrd=vbr for AVC/H.264 streams or hrd=1 for HEVC/H.265 streams.

By design this new ratecontrol system will never exceed the target bitrate, so using the --target big option and argument to increase quality is a good idea.

Here's how I would describe the option to enable this new ratecontrol system within the built-in --help output of transcode-video:

    --simple        use simple constrained ratecontrol
                      (limited size with different quality than default)

Since this new implementation is still a proposal, you can try it now using a wrapper script:

https://gist.github.com/donmelton/83d8022dc9cb273f6f638ac746037a63

Download the script and make sure it's executable and in your $PATH. Since it's just a stupid wrapper and doesn't detect anything about your input, you have to use it like this for a Blu-ray Disc rip:

experimental-simple-transcode-video.sh --blu-ray "/path/to/Blu-ray.mkv"

And like this for a DVD rip:

experimental-simple-transcode-video.sh --dvd "/path/to/DVD.mkv"

Let me know what you think. Thanks.

[RodBrown1988]

I think there’s definitely value in a limited quality option where it dramatically reduces the size accounting for issue #3, and issue #2 seems like it would be a valid concern.

That said, I’m not convinced about the name “Simple” - I don’t think this option should really class as simple - more as “limited” or something like that. I’m aware this is bikeshedding but I do think you’re doing the simplicity of your current system a disservice 😜.

I’m not sure the warnings alone are a valid reason. If they class as noise, but can be ignored, then the issue is more with the warnings that you cannot muffle out, and should be left as a documentation note.

I’ll take a look at the performance/quality as well, this is just a cursory review of the idea itself at this stage.

[lisamelton]

@RodBrown1988 Thanks for the feedback!

You make a good point about the name, actually. I'm not married to "simple." I just think that better describes how it's implemented compared to the default or ABR. Calling it "limited" has the same problem as calling the old ratecontrol system "CVBR" because these are all limited or constrained ratecontrol systems.

I agree that warnings alone aren't a valid reason but you would be surprised at the number of questions I get about that every week. :) Even with the explanation to ignore them in the FAQ, the sad truth is that most people don't read the FAQ.

[samhutchins]

Currently I transcode using --abr --target big (and 2 pass, though I think I'm gonna stop doing that). I've gone with abr over the other ratecontrol system because I'm targeting a Plex set up (streaming from a DS418play to a Roku 2), and I wanted to avoid big spikes in bitrate which (I think) cause my set up to stop and start buffering on occasion (either because of the network becoming a bottleneck, or the Roku not decoding video above a certain bitrate; not sure which). Since switching to abr this has stopped happening.

Am I correct in thinking that this new "simple" ratecontrol would have this benefit as well, seeing as it won't exceed the target bitrate?

Does this new ratecontrol system still generate crap frames occasionally? Or does "That risk is signifcantly reduced by the improved x264 video encoder included in HandBrake version 1.1.0 and later." mean it basically never happens?

I guess what I'm looking for it why this is a proposal to add a new option, rather than a proposal to replace one (or both) of the existing ratecontrol systems you have, because it sounds like the best of both worlds. What's the catch?

[lisamelton]

@samhutchins Thanks for the feedback with your, as usual, good questions and good concerns!

Yes, this proposed "simple" ratecontrol system has the same benefit as ABR for streaming, i.e. no unpredictable bitrate spikes. That's why I'm able to signal HRD information in metadata with it just as I do with ABR.

Unlike my special, or default, ratecontrol system, there are no occasional "crap" frames generated with this "simple" system. However, because the target bitrate will never be exceeded, there is the risk of occasional "noise" during high-complexity scenes if that target is too low. The good news is that risk is significantly reduced when using the --target big option and argument. The same cannot be said for my special ratecontrol system.

(BTW, my definition of "high-complexity scenes" is probably different that what you might expect. I don't necessarily mean high-motion as you would see in your typical action movie. I mean scenes that already contain textural noise, often caused by coarse grain in motion, confetti, etc. This is where the x264 video encoder often needs more bitrate for faithful depiction.)

I don't want to replace my special ratecontrol system. Not yet, anyway. It still produces the most consistent quality at the default target bitrates, despite its annoying-ass side effects.

And I don't want to replace my ABR ratecontrol system because that gives users the opportunity to do industry-standard two-pass transcoding. ABR is also the best solution when you need to use --target small.

So, this proposal needs to be a new ratecontrol system for now. If x264 continues to improve and if users want to raise the default target bitrates, I could see this "simple" system eventually replacing the default.

[lisamelton]

@samhutchins BTW, the only example of occasional "noise" during high-complexity scenes with this "simple" ratecontrol system that I've found so far can be seen very briefly when transcoding chapters 2, 3 and 4 of the Blu-ray version of "Saving Private Ryan (1998)." Of course, you have to stare at these chapters on a Retina 5K iMac from a foot away to really notice it. :)

And this is only the case with the default target bitrate of 6000 Kbps. You can't see it using --target big with a bitrate of 8000 Kbps.

I've now transcoded over 200 Blu-ray Discs and DVDs using --target big --quick with this "simple" ratecontrol system and, so far, they all look slightly more consistent and sharper than that same content transcoded using --abr --target big --quick. And for at least two of those videos, "simple" is definitely better than ABR for a few passages.

[samhutchins]

Well, seeing as I use --target big already I'm not sure the issues with noise will affect me much.

I'll give your wrapper script a try over the weekend, and see if I can even spot any differences :-P

Off topic:

Got a surround sound system recently. Life changing event, lol. It can decode the Dolby Pro Logic II stuff, and I'm amazed at how well it works. I might stop adding the ac3 track to my transcodes to be honest, I can't tell the difference. Crazy clever stuff, I have to say

[lisamelton]

@samhutchins Thanks! Let me know what you think.

Off topic:

Congratulations and I completely agree! All my transcoded audio is only Dolby Pro Logic II now. It sounds great on my surround system, too, and it saves significant space compared to AC-3. I'm seriously thinking about proposing that we make a single AAC track in Dolby Pro Logic II format the default for transcode-video. :)

[lisamelton]

@samhutchins BTW, I've found a few other videos that give this proposed "simple" ratecontrol system difficulties. And these difficulties could be perceptible, even when using --target big.

It's less of an issue of "noise" than it is of fidelity. Since, by design, this system will never exceed the target bitrate, it can't always faithfully render certain scenes as well as ABR, which has a 50% larger maximum than that target, or the default ratecontrol system, which has no limit at all.

Here are the difficulties I've found from three different Blu-ray Discs:

• Chapter 2 of "Tombstone (1993)" when the Mexican soldier falls to the ground.
• Chapter 3 of "Prometheus (2012)" when viewing the "memory" of the person in hibernation.
• Chapter 3 of "The Great Gatsby (2013)" when there is confetti on screen.

The question is how objectionable are these few scenes?

Any fidelity problems with single-pass ABR can usually be improved by tweaking the bitrate of temporal zones or simply using two-pass (although that's not the panacea everyone assumes).

But for "simple," there's no trick I can pull to "fix" these difficulties.

Thoughts?

[lisamelton]

@samhutchins and @RodBrown1988 Just to be clear, I don't recommend replacing any of your existing transcodings, whether they use the default or ABR ratecontrol, with "simple" ones. Not yet! I'm just asking for testing and feedback. I'm not replacing any of mine yet. Thanks.

[lisamelton]

@samhutchins and @RodBrown1988 OK, after spending another day doing comparison viewings between my ABR and "simple" transcodings, both using --target big --quick, I'm less enamored of the sharper image from the proposed "simple" ratecontrol system.

The problem with "simple" is that it loses some of the soft grain and subtle depth that I see in the ABR videos. Which I suspect is due to the higher maximum bitrate allowed in ABR, i.e. 1.5 times the target bitrate.

And I'm not sure I can compensate for that loss.

To be honest, this is also a problem when comparing videos transcoded with the ABR and default ratecontrol systems.

[damorrison]

It’s interesting isn’t it, because I notice a real difference when switching from a pro logic II sound track to a 5.1 one, and always pick the 5.1 if it’s avaialbe when watching at home.

While the ‘surround’ part doesn’t change much, To me the base sub only comes alive when it’s fed it’s own track and I don’t get that with Pro Logic.

On Fri, 29 Jun 2018 at 16:14, Don Melton notifications@github.com wrote:

@samhutchins https://github.com/samhutchins Thanks! Let me know what you think.

Off topic:

Congratulations and I completely agree! All my transcoded audio is only Dolby Pro Logic II now. It sounds great on my surround system, too, and it saves significant space compared to AC-3. I'm seriously thinking about proposing that we make a single AAC track in Dolby Pro Logic II format the default for transcode-video. :)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/donmelton/video_transcoding/issues/211#issuecomment-401385183, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYJDVvAobdOFGQ_rNGPq7f05ipCyTg4ks5uBkRTgaJpZM4U6ZEM .

-- Kind regards, Dave

[samhutchins]

I shall test prometheus this afternoon

[RodBrown1988]

@donmelton Yes, from my testing the thing I noticed was the finer-grained detail was lost, and I wasn't a fan. I tried with Prometheus and noticed that. I don't have the other titles on your list personally, so couldn't test them.

[lisamelton]

@damorrison With Dolby Pro Logic II, the Low Frequency Effects (LFE) channel is simply derived from the low-frequency content in the two original channels so it will never sound as unique as a discrete channel. But I don't have a problem with that.

[lisamelton]

@samhutchins Cool! Let me know what you think.

@RodBrown1988 I assume you mean less finer-grain detail in "simple" compared to ABR?

[samhutchins]

I think simple looks worse than abr in that Prometheus scene, but I couldn't articulate why. Viewed in isolation I'm not entirely sure I'd notice.

Compared to the original rip from MakeMKV, both abr and simple look significantly worse, lol.

[lisamelton]

@samhutchins Thanks for the quick feedback! Yeah, that scene is problematic for transcoding if you limit the maximum bitrate which ABR does and "simple" does even more. The default ratecontrol system renders it with more fidelity, but the bitrate spikes are significant.

[RodBrown1988]

@donmelton Yeah, simple seemed lower quality than ABR.

[samhutchins]

FWIW, I just got someone to rename files so I didn't know which one was which, and I have correctly identified simple.

Like you Don, I suspect the lower peak bitrate really hurts it in this scene

[lisamelton]

@samhutchins Wow! What a great way to test! :) Seriously, I have to try that.

I suspect "simple" will stay a proposal for now. A pity since it does so well elsewhere.

BTW, a two-pass ABR transcode of the entire movie handles that scene better. It's still not as good as the original, but it's passable.

[samhutchins]

@donmelton Haha, it did occur to me after getting them to rename the files that I could probably write a "shuffle" script that does it and saves the mapping to a text file somewhere

And yeah, I'm gonna stick with ABR for now. The default ratecontrol system definitely looks the best, but I need the limited bitrate for my streaming environment

[lisamelton]

After much evaluation, I'm going to shelve this proposal. And I've found a much easier way to provide this as an option. More on that later.

[lisamelton]

I'm re-opening this issue and plan to include the simple ratecontrol system in the next release. Why?

After much experimentation with the hardware-based video encoders available in HandBrake nightly builds, I've decided this simple ratecontrol system for x264 and x265 is the perfect compliment to those.

The hardware-based video encoders (at least vt_h264 and vt_h265 available on macOS) produce surprisingly good quality. Good enough, I think, to use 98% of the time. However, their one failing is occasional color banding. This is most noticeable when transcoding Blu-ray Disc rips of movies like "Blade Runner 2049 (2017)" and "American Sniper (2014)," which have some very dim and/or "flat" scenes.

And it seems the hardware-based video encoders are using a poorly-named CBR (constant bitrate) ratecontrol algorithm. Oddly, the simple ratecontrol system mimics the behavior and appearance of hardware-based CBR, but has a significantly reduced risk of color banding.

[lisamelton]

OK, this went into version 0.22.0 released just a few minutes ago.

Thanks for all the feedback!