Docker Jellyfin HW accelarated transcoding in Raspberry pi

  • Hi...

    I'm trying to deploy jellyfin docker container to support gpu hw transcoding in Raspberry. Following jellyfin/ guidelines it's necessary to mount OpenMax libraries (/opt/vc/lib) inside the container to make it working and here it's where it's failing due to a linking error. When I execute the following command to create the container:

    docker run -d --name jellyfin --volume /storage/docker/jellyfin:/config --volume /opt/vc/lib:/opt/vc/lib -p 8096:8096 --device=/dev/vchiq:/dev/vchiq --restart=unless-stopped linuxserver/jellyfin

    Jellyfin container logs report the following error not being able to start the app web server:

    [cont-init.d] 40-gid-video: executing... 
    [jellyfin-init] Pi Libs detected loading
    /sbin/ldconfig.real: Can't link /opt/vc/lib/ to
    [cont-init.d] 40-gid-video: exited 0.
    [cont-init.d] 99-custom-scripts: executing... 
    [cont-init.d] 99-custom-scripts: exited 267.
    [cont-init.d] done.
    [services.d] starting services
    [services.d] done.

    Does anybody know how to fix it?.


  • Rpi 4 hw transcode support was just added to that image and since none of the team members have an rpi 4 available for that purpose, we worked with an end user who did testing and troubleshooting for us (developing blind is not an easy task).

    Do you mind posting an issue on our github so we can properly track it?

    GitHub - linuxserver/docker-jellyfin

    • Official Post

    wondering if it is enough to just compile ffmpeg with the needed options ?

    same problem like at tvheadend (not sure this was fixed for the dockers)

  • After taking a look at docker-jellyfin project, it seems that the libraries appearing in /opt/vc/lib, mounted as volumen inside the container, are preloaded:

    # openmax lib loading
    if [ -e "/opt/vc/lib" ] && [ ! -e "/etc/" ]; then
        echo "[jellyfin-init] Pi Libs detected loading"
        echo "/opt/vc/lib" > "/etc/"

    The problem is that this folder in Libreelec is a symlink to /usr/lib, so these openmax libraries are mixed with usual OS staff ones, which maybe is making things go wrong.

    Do you know how any other docker apps solve this in LIbreelec?.


  • Curiously if I mount as volume inside the container exclusively and try to link only this library using ldconfig -l, this works:

    [email protected]38739bbd5:/opt/vc/lib# ldconfig -l
    [email protected]:/opt/vc/lib# ls -la
    total 29
    drwxr-xr-x 2 root root  1024 Jan 20 20:35 .
    drwxr-xr-x 3 root root  1024 Jan 20 20:31 ..
    -rwxr-xr-x 1 root root 26328 Nov 23 00:46
    lrwxrwxrwx 1 root root     9 Jan 20 20:35 ->

    It's a privilege issue. Container tries to create the simlink -> in host /usr/lib (/opt/vc/lib) without writing privileges for that folder. What would be the correct way of doing in similar docker images in Libreelec? Installing OpenMax libraries directly in the container?.


  • Just to provide an update here, we updated both jellyfin and emby addons in the linuxserver repo. They now both support omx hw transcode.

    Go into the addon settings and toggle openmax. When the container is recreated, necessary devices and drivers will be mapped in.

    One gotcha though, neither supports hw decode. They only do hw encode. According to jellyfin documentation, that is an upstream limitation: Hardware Acceleration | Documentation - Jellyfin Project

    I also tested v4l2 (everyone says it's the future). It is detected and used by both emby and jellyfin (again, only for encode) but unfortunately the image has a green filter over it. No idea why, so we didn't enable that in the addon yet. Let me know if you have any idea what causes it and/or how to fix it.