Proposal to modify ratecontrol system and target video bitrates

[lisamelton]

Proposal to modify ratecontrol system and target video bitrates

The feature that makes my transcode-video tool unique is the special ratecontrol system it implements to produce consistent high quality output at a reasonable size. And for the third time since its introduction, I'm proposing to change that system again. Why?

While the transcoded output remains high enough quality to be mistaken for the original, often too much bitrate and time is wasted achieving that goal.

We don't need 7600 Kbps to produce a convincing version of the movie "Star Trek (2009)" from Blu-ray Disc. Something around 6000 Kbps would be adequate. In fact, that would be an adequate bitrate for all Blu-ray transcodings.

And writing fewer bits out to disk will improve performance as well.

Obviously, just lowering target video bitrates would solve this problem. But the current rate control system rarely produces a final bitrate anywhere near those targets. It's just not precise.

That imprecision is actually a side effect of my original ratecontrol system design. It's caused by making the value of vbv-bufsize be half that of vbv-maxrate, the target video bitrate. Why did I do this? At the time, it was necessary to prevent quality problems in certain situations, often appearing as if the video was going in and out of focus. It was very annoying.

The good news is that a previous change to my ratecontrol system, on April 3 of this year, makes reducing vbv-bufsize unnecessary. That change was raising the quality limit by setting qpmax, the x264 quantizer maximum, to 34. And it was done to prevent x264 from occasionally generating a single, but still noticeable, very low quality frame because the CRF value is set so low.

So, to fix the imprecise target video bitrates problem, the value of vbv-bufsize should be twice that of vbv-maxrate.

While this change will still produce variable bitrates, the average for multiple videos should be centered more around the target now, at least when transcoding Blu-ray Discs or DVDs.

Default target video bitrates

Input resolution	Current	Proposed
2160p or 4K/UHD video	16000 Kbps	12000 Kbps
1080p or Blu-ray video	8000 Kbps	6000 Kbps
720p	4000 Kbps	3000 Kbps
480i, 576p or DVD video	2000 Kbps	1500 Kbps

You can try the new ratecontrol system and defaults right now using the current version of transcode-video and a few explicit options.

For Blu-ray input:

transcode-video --target 6000 --encoder-option vbv-bufsize=12000 "/path/to/Movie.mkv"

For DVD input:

transcode-video --target 1500 --encoder-option vbv-bufsize=3000 "/path/to/Movie.mkv"

I recommend using a recent nightly build of HandBrakeCLI for such testing. Specifically a version of HandBrakeCLI built after x264 core 148 r2705 was integrated on August 10, 2016. This new x264 library offers noticeable output size reduction and improved quality, albeit at a wee cost to speed.

Optional target video bitrates

Input resolution	--target big	--target small
2160p or 4K/UHD video	16000 Kbps	8000 Kbps
1080p or Blu-ray video	8000 Kbps	4000 Kbps
720p	4000 Kbps	2000 Kbps
480i, 576p or DVD video	2000 Kbps	1000 Kbps

In addition, I propose deprecating the current --small and --small-video options and replacing them with an additional variation of the --target option:

    --target big|small
                    apply video bitrate target macro for all input resolutions
                      (`big` trades some size for increased quality)
                      (`small` trades some quality for reduced size)
    --target [2160p=|1080p=|720p=|480p=]BITRATE
                    set video bitrate target (default: based on input)
                      or target for specific input resolution
                      (can be exceeded to maintain video quality)
                      (can be used multiple times)

You might notice that the --target big numbers are exactly the same as the current default numbers listed above. Don't let that confuse you. With the new ratecontrol system, larger bitrates will be output and quality will be increased. I'm not sure any quality improvement will actually be perceptible in most cases but, hey, beauty is in the eye of the beholder.

Please note that --target small output bitrates will often exceed the numbers listed here. That's a good thing because it means a minimum level of quality is being maintained.

Why not just bring back the old --big option and repurpose the current --small option for these new --target macros? Because the older options also affected audio bitrates. And I don't want there to be any confusion about that.

So, I'm asking for feedback. Let me know what you think. Soon. Because I'm liable to implement this as early as next week since the change is trivial due to the way I've architected the code. In fact, I've already made the change in my local tree. The hardest work remaining will be re-writing the README document.

Thanks.

[JMoVS]

I only had a brief look and wasn't able to test this yet. But what I didn't understand at all is why you would introduce a switch to revert to old behaviour. I just don't see a use case for why this could be needed at the moment, so I'm very open to the reasing behind that. ;-)

[lisamelton]

@JMoVS Thanks! A switch to reproduce the old behavior is there just in case someone is either 1) midway through an encoding series and doesn't want to downgrade and 2) somehow initially hates the new results. :) Of course, I'll deprecate and then remove the switch in later releases.

[bmhayward]

@donmelton I'm always up for faster speed and same or similar results. Looking forward to testing.

Thanks,
Brent

[lisamelton]

@bmhayward Cool! Let me know what you think. :)

[JMoVS]

@donmelton 1) I am not sure I see this as a valid reason. If they are midway, they can mark it. But why would I want to encode everything in an old way when the new way is better and the old way will be deprecated soon?
2) Exactly why would you then care about them? I could see it if you argued "to more easily compare these two, here is a switch and then we can decide on which is the correct to go forward". As you are deprecating them nevertheless, I really don't see a point in them unless you're not 100% sure the new behaviour is better and needs further tweaking. So far, I'm unconvinced this switch is needed. (BTW: If I remember correctly, this is also the first time you built such a switch. When you changed to the current behaviour, there was no such switch. When you changed the default about the --big and --small things, there wasn't a switch.

But it's also very possible that I'm just missing the point and not seeing your argument. ;-)

[lisamelton]

@JMoVS I provided a backward compatibility mechanism for the last big change to the ratecontrol system itself. It's not really hard to do, either.

[JMoVS]

@donmelton Ah ok, I must have missed that.

Is your recommended way of testing this to transcode the same movie twice and then compare as in your guidelines layed out in the Readme?

[lisamelton]

@JMoVS Yeah, transcoding a video you already have in your library, presumably done with the old ratecontrol system and targets, and then comparing them to the new system and targets (using the "hack" I detailed above) would be really useful. Thanks!

Anyway, that's what I've been doing. I'm also making comparisons using the version of the x264 library in the released version of HandBrake and the nightly build that I recommended above. I have two Macs transcoding full-time at the moment. :)

[lisamelton]

@JMoVS My apologies. I had to re-edit that last comment multiple times due to failures with auto-complete. :) But I think it's right now.

[JMoVS]

@donmelton Thx for clarification. I'll probably be able to do 2 transcode runs (my 2009 MBP manages real-time transcoding ;-) ) and compare them coming from a stable handbrake version.

[lisamelton]

OK, I'm seriously thinking about following the advice of @JMoVS and not including the --ratecontrol option to enable the old behavior. What does everyone else think about that?

The old behavior could still be emulated with a combination of --target and --encoder-option, just like emulating the new behavior is possible with the current tool. It's just a little more clunky.

[lisamelton]

I've decided to reuse the --old-behavior option and pre-deprecate it instead of including the proposed --ratecontrol option. And I won't list --old-behavior in the built-in help. I'll just mention it the release notes of the README file.

[lisamelton]

Nevermind what I wrote about the --old-behavior option. Stupid idea. :) I'm not including a single option to enable the old behavior. You'll just have to emulate it with a combination of --target and --encoder-option. That seems the simplest and most forward-thinking way to do it.

[chrispoole643]

Don, as you'll know from prior Twitter interactions, I've "borrowed" your rate control system in my own ripping scripts. Regarding these changes, I have played with the configuration in similar ways, and come to the same conclusions. However, I've only tested these changes on a few Blu-rays, and a few DVDs. In my view, if you think the quality is still acceptable, and you've tested the changes on some number of discs from your own collection, the changes should be pushed up immediately.

[JMoVS]

@donmelton I'm still transcoding but what seems (take it with a big grain of salt) is that I get many many many more VBV buffer underflows and have gone down from roughly 25fps transcoding the DVD from pirates of the carribean down to 20 fps average. Don't know why or whether this is real, right now it at least seems to be the case.

[lisamelton]

@chrispoole643 Cool! Like minds, eh? :) Yeah, this might actually get released by the end of the week. Thanks for the feedback!

[lisamelton]

@JMoVS You should certainly see more VBV underflow warnings. That happens anytime you lower the target bitrate. Just ignore them. But I haven't seen the performance issue you mention. It has always been faster than using the current default. Unless, of course, you're comparing data from two different versions of HandBrake. Keep in mind that the latest version of x264 in HandBrake nightly builds is slightly slower than the x264 in the 0.10.5 version of HandBrake.

[JMoVS]

I'm comparing on current stable handbrake version with these two transcode-video calls:

transcode-video --crop detect --fallback-crop mplayer --quick --small --main-audio=eng --add-audio 2 --copy-audio-name all --audio-width all=double --burn-subtitle scan --add-subtitle=deu -o "old.mkv" Video_fileH10.mkv
transcode-video --crop detect --fallback-crop mplayer --quick --small --main-audio=eng --target 1000 --encoder-option vbv-bufsize=3000 --add-audio 2 --copy-audio-name all --audio-width all=double --burn-subtitle scan --add-subtitle=deu -o "new.mkv" Video_fileH10.mkv

[lisamelton]

@JMoVS Using --small might be invalidating your test. Can you try comparing the old defaults to the new defaults first?

[JMoVS]

Oh, I didn't catch that. I'll do over night. As you can see, 25fps isn't exactly super fast 👯

[lisamelton]

@JMoVS And I'll try some tests today with DVD video at 1000 Kbps again, too.

BTW, always make sure your vbv-bufsize value is twice your target bitrate. Not three times. That's too large and can cause other problems.

[lisamelton]

@JMoVS After testing some more, transcoding DVD video at 1000 Kbps is definitely faster than transcoding at 1500 Kpbs or using the old ratecontrol system. At least for me. So I'm not sure what's causing your slowdown.

[lisamelton]

Folks, one of the reasons I haven't "pulled the trigger" and released this change yet is not the new ratecontrol system — that's working great — but I'm not quite convinced all the bitrate targets are right yet. Specifically, the --target small settings might be too small for 720p and 480p resolutions. Any thoughts on that?

[lisamelton]

Folks, after some more tests, I feel much better about the proposed --target small settings. Let me know what you think.

[JMoVS]

@donmelton I can confirm that the speed thing was a fluke. New method was 3fps faster (so 10%) compared to the old one.

I compared the default now with pirates of the carrebean, and I couldn't spot any difference between the two. Looks good.

How to test the new small behaviour? vbv 2000 then (DVD input) and target 1000?

[lisamelton]

@JMoVS Good to hear! Yes, to emulate the proposed --target small for DVD input, use:

transcode-video --target 1000 --encoder-option vbv-bufsize=2000 "/path/to/Movie.mkv"

[lisamelton]

Folks, unless there are big concerns with this proposal, it's very likely I'll release version 0.12.0 tonight or tomorrow with this change. Now is the time to speak up.

Bueller?... Bueller?... Bueller?

[JMoVS]

@donmelton I am currently on HandBrake Nightly and am transcoding the two small samples. If you can wait another roughly 5 hours or so, I could give you a go or no go with that. Or you could just go ahead. :D

[cnicolai]

With the current settings I am no recognize a difference between the original and transcoded file. If that is still the case with the proposed new version, I can't see any reason not to use 0.12.0. (I haven't tested it, but if you guys can't see a difference, I won't be able as well).

By the way: Do you recommend nightly builds of Handbrake CLI for the new 0.12.0 settings?

Thanks again for you amazing work!

[lisamelton]

@JMoVS Keep transcoding! I'll wait. I'm AFK for the next few hours anyway. :)

[lisamelton]

@cnicolai Thanks! The current nightly builds of HandBrake seem to produce slightly higher quality and slightly smaller output. That's always a good thing. But be aware that they are slightly slower, too.

I've transcoded a little over 75 different Blu-ray Disc movies using the current nightly builds of HandBrake and the new ratecontrol system with target video bitrates described here. I'm very happy with the results. I can't really tell them apart from my previous transcodings even sitting at arms length from my 27-inch iMac screen.

[JMoVS]

@donmelton I couldn't spot a difference. Just excellent video quality. And all output I produced was smaller with the new settings accross the board. So definitely a "go" from my side of the pond! ;-)

[lisamelton]

@JMoVS W00t! Great to hear. :)

OK, this will likely get released tonight or early tomorrow. It's a family member's birthday today and all the celebrating is getting in the way of my coding. :)

[lisamelton]

@JMoVS And, BTW, thanks again for doing all that testing!

[lisamelton]

Version 0.12.0 is out now with these changes. Just gem update video_transcoding to get the new release.

Thanks for all your help!

[joeycortez42]

@donmelton using the new version and I noticed a sharp increase in file size. Looks like it was mostly do to audio bitrates.

Old version with --small
track 0 2449.01 kbps
track 1 172.01 kbps
track 2 384.00 kbps

New version (small no longer needed since target 3000kbps is default)
track 0 2930.34 kbps
track 1 172.01 kbps
track 2 640.00 kbps

I see you recommend the higher bitrate for 5.1 surround. Would using the --target small change the audio bitrates?
(I took your recommendation of using FLAC for my single audio track.)

[lisamelton]

@nokemono42 That's correct. The larger size is due to the AC-3 audio track.

I've changed the approach going forward since feedback from most users indicates that they prefer high-quality surround audio even if that wastes a bit of space. That was actually the default behavior before, too. It was only the --small option which lowered AC-3 audio bitrates. And I had to add the --small-video which didn't affect audio. In retrospect, I shouldn't have added either option.

The --target option, by design, only affects video bitrates. And it will remain that way.

If you really do want smaller AC-3 audio, the solution is simple. Just add --ac3-bitrate 384 to your command line. You can also add --pass-ac3-bitrate 448 to make sure no really big AC-3 tracks slip through. Those two additions are really what the old --small option did, besides lowering target video bitrates.