Hardware acceleration transcoding option for videos

[dsippel]

Feature detail

Could you add an option to harness the integrated hardware transcoding capabilities in most modern CPUs (and GPUs) for video transcoding? This would significantly reduce the load on the server when transcoding video files.

An option could be added under the ffmpeg settings in the administration area to select the transcoding method (software vs. hardware)

You would need to pass through the transcoding device into the docker. For details or as an example you can see how PhotoPrism does that. For details see: https://docs.photoprism.app/getting-started/advanced/transcoding/

Best

Daniel

Platform

Server

[bo0tzz]

Duplicate of #203

[Snuupy]

Can this issue be reopened? https://github.com/immich-app/immich/issues/203 is marked as merged but does not include hardware accelerated transcoding.

[dpnvektor]

Would like to second reopening this issue; presently transcoding has been crushing my 16 core vps for days to encode just a few hundred videos into vp9.

[dpnvektor]

Thanks for re-opening! Just for a baseline bit of info, un-accelerated Immich has managed to consume all cores of a 16 core VPS for 36 hours and has only managed to encode approx 100 videos (all around a couple minutes in length). At this rate, it should have the rest of the library encoded in a couple years. 😂

I'm not much of a dev, but I think to enable the most basic CPU/iGPU level acceleration all we may need to do here is to add the following to the ffmpeg options:

-hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -hwaccel_output_format

and the following to the Docker: devices:

• /dev/dri:/dev/dri

Not sure what it would take to add NV or AMD acceleration, but above might be enough to get most people happy. Thank you again for such a wonderful platform!

[jrasm91]

Just for a baseline bit of info, un-accelerated Immich has managed to consume all cores of a 16 core VPS for 36 hours and has only managed to encode approx 100 videos (all around a couple minutes in length).

To be fair, this sounds like a bug/setup issue. If the CPU is maxed out, it might be context switching a lot and not getting very much work actually done.

[dpnvektor]

Hmm, possibly! My experiences with transcoding (which is largely limited to Plex) is that it can be comically slow when not hardware accelerated, but I wouldn't rule out that there is something else going on. Presently it looks like a whole lot of individual low-priority threads (30+?) of ffmpeg all crunching on the same file:

The complete command shown by htop is:

/usr/bin/ffmpeg -i upload/library/admin/2018/2018-08-03/IMG_0193+1.MOV -y -vcodec hevc -acodec opus -strict experimental -movflags faststart -preset medium -threads 12 -x265-params "pools=none" -x265-params "frame-threads=12" -crf 23 upload/encoded-video/384624b8-7600-4fa5-9ac8-1cc2675808d2/bc9d7e80-4d8c-46d7-a6b2-4b431246efa5.mp4

[jrasm91]

Looks like normal ffmpeg mutli-threading to process a single video and using all available resources.

[lucienn3]

Hey guys,

very interesting topic would just like to highlight that there are complete projects just focusing on transcoding: https://github.com/HaveAGitGat/Tdarr

Maybe an integration with a well-supported toll might yield the best results?

[cibernox]

I wonder if a possible easy change would be to, inside the the FFmpeg Settings section, add a text field for setting any arbitrary arguments to be forwarded to FFmpeg when compressing videos. That way users can try different options like hwaccel to see what works (and eventually that knowledge could be solidified in the docs)

[jrasm91]

I believe ffmpeg has to be compiled with flags to enable hardware acceleration first, before any arguments would have an effect.