[Feature] Implement hardware accelerated decoding

[NodudeWasTaken]

Is your feature request related to a problem? Please describe. Generating and transcoding are CPU heavy operations, offloading the decoding of videos to the GPU can help performance/speed greatly.

Describe the solution you'd like A checkbox enabling hardware accelerated decoding for:

• Generation (of previews and scrubber sprites).
• Live transcoding.
• Task transcoding.

Hardware accelerated decoding can be easily enabled in ffmpeg by prepending -hwaccel auto before the input video file.

Describe alternatives you've considered Another solution could be user customizeable ffmpeg commands.

Additional context Its important to note that hardware accelerated decoding can reduce the quality of the videos. It should be noted that im unaware of what happens if the selected decoder cant decode the selected video because of resolution problems or some other incompatibility.

[deepradio]

This should help to reduce the load on CPU, because even integrated GPU now supports encode/decode HEVC, VP9 etc.

I see there is a PR for this https://github.com/stashapp/stash/pull/1041 sitting for more than a year now. Will -hwaccel auto make it much easier (without specifying the method)?

[NodudeWasTaken]

This should help to reduce the load on CPU, because even integrated GPU now supports encode/decode HEVC, VP9 etc.

I see there is a PR for this #1041 sitting for more than a year now. Will -hwaccel auto make it much easier (without specifying the method)?

That PR is for transcoding/encoding video, which is unrelated. All hwaccel will do is speed up video decoding (and by that notion, preview generation, and possibly cpu transcoding if low on resources). Although you could instead specify the decoder for full-hardware transcoding, that should probably be reserved for its own PR.

[deepradio]

That PR is for transcoding/encoding video, which is unrelated. All hwaccel will do is speed up video decoding (and by that notion, preview generation, and possibly cpu transcoding is low on resources). Although you could instead specify the decoder for full-hardware transcoding, that should probably be reserved for its own PR.

Thanks for clarification! Not very familiar with this. So for live transcoding, will -hwaccel auto help? I would like that to be faster. Looks like Stash is using pure CPU right now for that.

[NodudeWasTaken]

That PR is for transcoding/encoding video, which is unrelated. All hwaccel will do is speed up video decoding (and by that notion, preview generation, and possibly cpu transcoding is low on resources). Although you could instead specify the decoder for full-hardware transcoding, that should probably be reserved for its own PR.

Thanks for clarification! Not very familiar with this. So for live transcoding, will -hwaccel auto help? I would like that to be faster. Looks like Stash is using pure CPU right now for that.

If you currently hit 100% cpu usage while transcoding, it will help.

[WithoutPants]

$150 bounty assigned (ref: 595560)

[WithoutPants]

My preferred implementation for the first iteration is to allow customisation of the ffmpeg command line for generation and live streaming. We can put more hard-coded options in a subsequent iteration.

[NodudeWasTaken]

My preferred implementation for the first iteration is to allow customisation of the ffmpeg command line for generation and live streaming. We can put more hard-coded options in a subsequent iteration.

One thing, even if that goes through, docker users wouldn't be able to use it without gpu passthrough

[Kruk2]

One note from me because I did modify the stash code to use gpu decoding and encoding (no PR because because I just hardcoded specific values I wanted). I end up with removing hardware accelerated sprites generation because it was actually slower. Probably asking GPU to decode one frame was slower than just doing it via software decoder.

[dsrtusr88]

@NodudeWasTaken honestly we're pretty used to it at this point