Hardware accelerated transcoding with Intel VAAPI

[kamaeff]

Hi!

If someone is looking for options to enable hardware-accelerated video processing with ffmpeg inside of metube container, here is how I did it.

My setup is Debian 13 running on Intel N150 processor. I've Intel media drivers already installed on host machine and have these devices available:

ls -l /dev/dri
total 0
drwxr-xr-x  2 root root         80 Jul 25 10:32 by-path
crw-rw----+ 1 root video  226,   0 Jul 25 10:32 card0
crw-rw----+ 1 root render 226, 128 Jul 25 10:32 renderD128

Steps:

1. Install intel vaapi driver and video processing library inside of container. I've approached this step by building my own image on top of original metube image: dockerfile.
2. Find GID of render group: getent group render | cut -d: -f3
3. Use that GID as PGID env variable in your container: docker-compose.yml
4. Pass yout /dev/dri/ devices to the container: docker-compose.yml.
5. Set up yt-dlp options to use ffmpeg with hardware-accelerated decoding and encoding: ytdlp-presets.json
   In this example -hwaccel vaapi tells ffmpeg to use your Intel GPU to decode input videos, -vcodec hevc_vaapi tells ffmpeg to use VAAPI hardware accelerated HEVC encoder to encode the output videos, and scale_vaapi is used to perform hardware-accelerated scaling.

If links here stop working, most probably that means I've deleted my github account. In that case you can try to look at these examples by replacing github.com with codeberg.org in that links, probably it should work.

[alexta69]

Thanks for writing this up — it's a genuinely useful recipe, and the two non-obvious bits (the image ships ffmpeg but no VAAPI driver, and needing the host's render GID) weren't documented anywhere.

I've added it to the wiki with attribution: Hardware-accelerated transcoding. The Dockerfile, compose bits and the hwaccel parts of your preset are inlined there, so it'll survive if your links ever go away.

A couple of things I added on top of yours, in case they're wrong for your setup: a note that PGID is also what the entrypoint chowns the download dirs to (so files end up group-owned by render), with user: + group_add as an alternative; a short verification section using vainfo; and a line about AMD/NVIDIA. Corrections welcome — you can edit the wiki directly or comment here.

[kamaeff]

Thank you for rewriting my post and adding it to the wiki. As a non-native English speaker sometimes I struggle with writing good documentation and get tired of it. Your version looks better to me.

Also thanks for pointing out that it's possible to run metube with docker native user and group_add. When setting up metube I somehow missed that else branch in your docker-entrypoint.sh that runs the app without gosu.

I think that docker's user and group_add are more suitable here than PUID:PGID for two reasons:

• files ownership you already mentioned
• not sure of this point, I guess if user prefers to use intel's QSV instead of VAAPI, on Debian that may also require adding video group along with render. I couldn't get QSV to work and I think the reason for this is the missing video group in my setup.