-
-
Notifications
You must be signed in to change notification settings - Fork 794
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
Full hardware transcoding #4765
Full hardware transcoding #4765
Conversation
It's a bit unclear to me what the impacts of these new options are, and the naming is a bit unintuitive. Is there a reason for the naming
Why is this optional? When would a user use the various combinations? I'm assuming Your performance test results aren't really clear to me. |
Alright i removed the options such that it always tries full hardware transcoding if hardware acceleration is enabled. |
Just a footnote for future - This will cause problems for containerized users as |
This adds a "test" that checks if full hardware transcoding is possible for a given file.
The reason its done this way is because there are a gazillion different incompatibilities that i dont want to check for.
This is naturally optional and has a setting in the menu.
I've also added an option to add hardware decoding in any case (-hwaccel auto).
Also contains a fix for that one guy that had an AMD APU that needed atleast 256px.
My tests from 7k60 -> 4k60 using an NVIDIA 10 series (using h264_nvenc for all):
No accelerated decode: 0.7x
Accelerated decode: 0.17x (yes my cpu/ram is slow)
Full hardware transcode: 1.3x
Accelerated decode seems to be a footgun in my system, but i dont know that that's true for all systems.
This is explicitly only tested for NVidia and Intel, i dont know that vaapi works properly.
As a side note it also adds an ffmpeg version check, because i needed it for nvenc 10bit transcoding.