I am quite happy with how NVenc accellerated video transcoding works on my Peertube instance, but the binary Nvidia drivers are a real PITA often requiring server restarts etc.

Since I have a more power efficient server with a reasonably new version of Intel Quicksync (Version 6), so I am wondering if that wouldn’t be sufficient for regular video transcoding?

Anyone got that working already and could share some experiences?

I could still use the Nvidia card for an external runner to do other neat stuff like voice transscription on a less uptime critical server then.

  • Admiral Patrick@dubvee.org
    link
    fedilink
    English
    arrow-up
    4
    ·
    edit-2
    16 days ago

    Yep. Works great, at least for my small instance.

    You have to install the ffmpeg-vaapi plugin and then under Config->VOD set the profile to the vaapi one it creates. I’m not using remote runners, but from what I’ve read, this doesn’t work with remote runners since you can’t install plugins on those. You may be able to shim in rffmpeg instead, though.

    The only sticking point is I cannot get the peertube user (inside the container) to consistently have permission to write to /dev/dri/renderD128 .

    Eventually I’m going to tweak the image so this isn’t necessary, but for now have a startup script that brings up the stack and chmod’s the device endpoint to allow any user inside the container to write to it:

    #!/bin/bash
    cd /opt/peertube
    docker compose up -d
    docker compose exec peertube bash -c "chmod o+rw /dev/dri/renderD128; ls -lah /dev/dri/renderD128"
    

    Rather than have Docker engine manage the stack’s lifecycle, I have that startup script called by a systemd unit (ExecStop just does a docker compose down).

    Edit: The other sticking point I ran into is the video studio not working well (or at least the few videos I tried). I haven’t really tried to pin down what that problem is.

    Edit 2: I did have to build a custom image to include the Intel drivers/modules.

    debian.sources (copied from the bookworm image and edited to include non-free)
    # http://snapshot.debian.org/archive/debian/20251117T000000Z
    URIs: http://deb.debian.org/debian
    Suites: bookworm bookworm-updates
    Components: main non-free
    Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
    
    Types: deb
    # http://snapshot.debian.org/archive/debian-security/20251117T000000Z
    URIs: http://deb.debian.org/debian-security
    Suites: bookworm-security
    Components: main non-free
    Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
    
    Dockerfile
    FROM chocobozzz/peertube:production-bookworm
    COPY debian.sources /etc/apt/sources.list.d/debian.sources
    RUN apt update && apt install -y --no-install-recommends vainfo intel-media-va-driver-non-free
    

    I should probably add the step here to setup permissions for /dev/dri/renderD128

    • poVoq@slrpnk.netOP
      link
      fedilink
      arrow-up
      2
      ·
      16 days ago

      Thanks for the explanation. That permission issue sounds indeed a bit annoying. With NVenc the nvidia CUDA toolkit for containers takes care of such annoyances, but I expected it to be less easy with Quicksync.

      Maybe it is worth submitting an upstream PR to their Dockerfile that always changes permissions on these files?