New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal to lower target video bitrates (again) #55
Comments
I've got nothing to add to your proposal, I just want to say I really appreciate the work you do on this tool, and what a great maintainer you are in general. In the limited time I've spent trying to learn about the nuances of encoding, I've realized I don't have time to learn about the nuances of encoding. Having this available has enabled me to completely offload the actual video encoding, and instead focus my time and energy on the rest of the automated processing pipeline. It means a lot that I can fully trust that the tool you put out is going to 'do the right thing' and give me the best shot at optimizing any video I throw at it. And I've not had to spend any time debugging issues due to anything your tool has been responsible for. So, keep it up and thanks again! |
@J-Swift Wow! Such praise will just go to my head. :) Seriously, thank you so much! People like yourself are exactly why I keep doing this. (Well, you and the fact that I'm completely nuts.) |
Don, I took 9 movies that I had previously encoded with 0.5.x and the Visual exam: I wouldn't call my eyesight super-sharp by any stretch of the imagination, but in doing a quick review of the video files generated, the 0.6 files look better than the 0.5.x files, and I couldn't really tell the difference between the files generated with 0.6 defaults and 0.6 with What I wasn't sure about was if the file sizes should then move consistently as well. In my 9 test files, 5 of them got smaller between 0.5.x and 0.6, while 4 of them got larger. In the case of Spectre, it grew by 50%. Here are the movies I ran the tests on (please don't judge) and the different file sizes that resulted, in GB.
This this about what you expected to happen? And, if I may be so bold: I echo @J-Swift sentiments above. |
@bpharriss This is great data! Thanks do doing all these tests and collating the results so nicely! (And don't apologize for your title selection. I have most of the same movies. :) Yes, this is what I expected, i.e. that the size of some DVD transcodings will actually be larger between 0.5.x and 0.6. That's due to the new ratecontrol system moving bitrates closer to the targets. Which, of course, is why I want to lower the targets for 0.7. Now, that won't lower all sizes below 0.5.x levels, but the average size will be slightly lower if multiple videos are considered together. Hopefully, they will look as good, if not better, too. Which I think is what you're seeing. And thank you for the kind praise! Much appreciated, sir. |
@lambdan Thanks for posting this in the GitHub issue! I was just going to do that after responding to you on Twitter. :) And thanks for doing all these tests! Yes, the sizes will vary somewhat depending on complexity, grain, etc., but overall they should be slightly smaller if several are considered together. I'm glad you like the visual results, too, with a vote of confidence. The new ratecontrol system is finally making some of my old, grainy black and white full frame movies look halfway decent. |
Update: After more testing by myself and others (thank you all), I'm much more confident in my proposed video bitrate target changes for 480p and 720p content. However, I'm now doubting the wisdom of changing the 2160p (4K) targets. This is because no matter how low I set the target, I can't get the bitrate below 10000 Kbps for any of my, admittedly few, 2160p samples using the new ratecontrol system. Since I don't even document that |
OK, version 0.7.0 of
...to get the latest version. Thanks again for all your help! |
Proposal to lower target video bitrates (again)
The 0.6 release of the video_transcoding Gem contained perhaps the most significant change to the
transcode-video
tool since the deprecated--big
option became the default behavior. Not only was the ratecontrol system enhanced to produce higher quality, the target bitrates for 480i and 720p content were lowered to limit the higher bitrates produced by that higher quality.For the upcoming 0.7 release, I propose to lower those video bitrate targets again, and not just for 480i and 720p content. The targets for 2160p (4K/UHD) content would also be lowered. However, I'm not proposing any change to bitrate targets for 1080p.
Also different for 0.7 would be lowering the targets when using the
--small
or--small-video
options.Default target video bitrate
Target video bitrate with
--small
or--small-video
OK, what's the rationale for doing this?
First, the new ratecontrol system introduced in version 0.6 with a constant rate factor (CRF) quality target of
1
does much better at putting pressure onx264
to hit that target bitrate than the old quality target of16
ever did. So, bitrates are higher now. Weirdly, 480i and 720p content is suddenly too good. And that seems very wasteful of space.Second, these proposed targets seem to be more in line with what Apple, Netflix, warez (you know what I mean), etc. are doing now as opposed to what they were doing when the project started.
This makes sense to me and my tests so far indicate that quality is still good with lower target video bitrates.
BTW, you can try any of these targets yourself by setting
vbv-maxrate
directly like this:So, I'm asking for your feedback. Let me know what you think. Soon. Because I'm liable to make the change as early as next week.
Thanks.
The text was updated successfully, but these errors were encountered: