Skip to content
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

Merged
merged 12 commits into from
May 10, 2024

Conversation

NodudeWasTaken
Copy link
Contributor

@NodudeWasTaken NodudeWasTaken commented Apr 16, 2024

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.

@WithoutPants
Copy link
Collaborator

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 alwaysAddHardwareDecoding? Isn't hardwareDecoding sufficient?

This is naturally optional and has a setting in the menu.

Why is this optional? When would a user use the various combinations? I'm assuming transcodeHardwareAcceleration = false implies that the transcodeFullHardwareAcceleration option is also false. What is the impact of both values being true, and why would a user want to not use full hardware acceleration?

Your performance test results aren't really clear to me.

@NodudeWasTaken
Copy link
Contributor Author

NodudeWasTaken commented May 9, 2024

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 alwaysAddHardwareDecoding? Isn't hardwareDecoding sufficient?

This is naturally optional and has a setting in the menu.

Why is this optional? When would a user use the various combinations? I'm assuming transcodeHardwareAcceleration = false implies that the transcodeFullHardwareAcceleration option is also false. What is the impact of both values being true, and why would a user want to not use full hardware acceleration?

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.
You're right that it was unnecessary, the only real downside is increased vram usage, but that should be negligible.
Always add decode is also gone, the only reason its there is because i saw many users using it (-hwaccel cuda etc.), but it conflicts with full hardware transcoding.

@WithoutPants WithoutPants added the improvement Something needed tweaking. label May 10, 2024
@WithoutPants WithoutPants added this to the Version 0.26.0 milestone May 10, 2024
@WithoutPants WithoutPants merged commit c5fef39 into stashapp:develop May 10, 2024
2 checks passed
@feederbox826
Copy link
Contributor

Just a footnote for future - This will cause problems for containerized users as scale_cuda on most ffmpeg builds will require the CUDA drivers and subsequently NVIDIA drivers on the host

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
improvement Something needed tweaking.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants