Quick Sync Transcoding

[jbslabs]

Acknowledgment

• This is a feature request, not a bug report or a TrueNAS/setup support question. I understand that support questions disguised as feature requests will be closed and I will be banned.

Is your feature request related to a problem?

Currently, transcoding can place a significant load on the CPU, even on systems with Intel CPUs that include an integrated GPU and dedicated media engine. I'm requesting support for Intel Quick Sync Video (QSV) hardware-accelerated transcoding to be added in Fireshare.

Describe the solution you'd like

Add Intel QSV/VA-API support to FFmpeg and allow Fireshare to use /dev/dri for hardware acceleration. This would enable users with Intel CPUs such as 10th–14th gen Core processors to offload H.264/H.265 transcoding to the integrated GPU, significantly reducing CPU usage and improving transcoding performance.

Ideally, this could be configurable through an environment variable, for example:

devices:

• /dev/dri:/dev/dri

environment:

• TRANSCODE_GPU=qsv

This would be especially useful for self-hosted installations running on Intel NUCs, mini PCs, NAS systems, and home servers where Intel Quick Sync is available.

Describe alternatives you've considered

No response

Additional context

No response

Expectations

• I understand that feature requests are simply that — requests. They may not receive a response, and may be declined or go unimplemented without any reason given.

[ShaneIsrael]

This is something I'd like to add eventually, but right now I don't have any Intel hardware with Quick Sync to test against, and I can't verify it in CI either since the runners don't expose /dev/dri. I'm not comfortable shipping hardware acceleration I have no way to confirm actually works. The usual failure mode is a silent fall back to CPU, which just turns into bug reports I can't reproduce.

It's also a bigger change than it looks from the outside. FFmpeg is compiled from source in the image, so this means adding VAAPI/QSV to the build, pulling in the Intel media driver stack at runtime, handling /dev/dri group permissions in the entrypoint (the render GID varies by host), and retuning quality settings since VAAPI doesn't map cleanly to the CRF values used for CPU and NVENC. Picking the encoder is honestly the easy part.

Leaving this open. If someone running Intel hardware wants to take a crack at it and can actually test it, I'm happy to review a PR.

One thing though: I'd want some form of video proof that it was properly tested on real hardware. Anyone can point an AI at this issue and get a PR out of it without ever having run a single transcode.