Tracking issue for Hardware transcoding support

[highfrog]

This is currently the next major feature planned for Transcodarr.

The goal is to support hardware-accelerated transcoding to reduce processing time and CPU usage for larger libraries.

Initial targets:

• NVIDIA NVENC
• Intel Quick Sync
• Docker GPU passthrough support/documentation
• Encoder selection in configuration

Longer term I'd like this to tie into the planned multi-node architecture so workers can advertise available hardware capabilities and jobs can be routed accordingly.

[maxnatamo]

Is this something which could theoretically be done without any changes, since you can set the video codec ffmpeg uses? So, to use NVENC, you'd use h264_nvenc instead of h264. Admittedly, I think it might also need to be passed something like -hwaccel cuda -hwaccel_output_format cuda for it to work correctly (according to NVIDIA's docs, at least).

[highfrog]

Yeah, you nailed it — that's basically the direction I went. Just tagged it as v1.3.0.

It's all per-preset, so the whole chain can run on the GPU or stay on the CPU depending on how you set it up — presets are granular. And your -hwaccel point was the one that actually mattered: just swapping the encoder still decodes on the CPU, which is where most of the time was going. So on a hardware preset, frames now stay on the card through scaling and tonemapping too, not just the encode.

Fair warning though — I've only measured it on my Intel iGPU (~4x faster there). NVENC is wired up the same way (-hwaccel cuda), but it's code, not a verified result: I've got an Nvidia card, just haven't passed it through yet. So no promises on the cuda path until I (or someone) actually runs it — would be curious if it works for you.

Going to leave this open until the NVENC path is actually verified, then I'll close it out.