[GH-ISSUE #482] GStreamer NVENC fallback to software encoding due to missing libnvrtc.so #293

New issue

Closed

opened 2026-10-15 12:59:25 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-15 12:59:25 +00:00

Owner

Originally created by @hans-chrstn on GitHub (Aug 18, 2026).
Original GitHub issue: https://github.com/games-on-whales/wolf/issues/482

Describe the Bug

When deploying the ghcr.io/games-on-whales/wolf:stable container via standard Docker Compose / CDI (ran mine on NixOS which mightve contributed to the problem because it's non fhs), Wolf fails to initialize the NVIDIA hardware encoders (nvh264enc / nvh265enc / nvcodec) and silently falls back to software encoding (x264, x265, aom).

The underlying cause is that GStreamer fails to initialize cudaconvertscale because libnvrtc.so is missing from the container's dynamic linker search path:

WARN  cudanvrtc gstcudanvrtc.cpp:163:gst_cuda_nvrtc_load_library_once: Could not open nvrtc library libnvrtc.so: cannot open shared object file: No such file or directory
WARN  GST_ELEMENT_FACTORY gstelementfactory.c:713:gst_element_factory_make_with_properties: no such element factory "cudaconvertscale"!
INFO  | Using h264 encoder: x264
WARN  | Software h264 encoder detected

Steps to Reproduce

Deploy a standard wolf container using Docker Compose with NVIDIA CDI/container toolkit.
Inspect startup logs using docker logs wolf -f.
Observe GStreamer loading errors for cudanvrtc / cudaconvertscale and fallback to software encoders.

my compose:

services:
  wolf:
    image: ghcr.io/games-on-whales/wolf:stable
    container_name: wolf
    restart: unless-stopped
    network_mode: host
    environment:
      - NVIDIA_DRIVER_CAPABILITIES=all
      - NVIDIA_VISIBLE_DEVICES=all
    volumes:
      - ./config/wolf:/etc/wolf:rw
      - ./data/wolf:/data:rw
      - /var/run/docker.sock:/var/run/docker.sock:rw
      - /dev/:/dev/:rw
      - /run/udev:/run/udev:rw
    device_cgroup_rules:
      - 'c 13:* rmw'
    devices:
      - nvidia.com/gpu=all
      - /dev/dri
      - /dev/uinput
      - /dev/uhid

nvidia version: 595.91.07

full logs in case needed: https://pastebin.com/CZPEFmnx

Originally created by @hans-chrstn on GitHub (Aug 18, 2026). Original GitHub issue: https://github.com/games-on-whales/wolf/issues/482 ### Describe the Bug When deploying the `ghcr.io/games-on-whales/wolf:stable` container via standard Docker Compose / CDI (ran mine on NixOS which mightve contributed to the problem because it's non fhs), Wolf fails to initialize the NVIDIA hardware encoders (`nvh264enc` / `nvh265enc` / `nvcodec`) and silently falls back to software encoding (`x264`, `x265`, `aom`). The underlying cause is that GStreamer fails to initialize `cudaconvertscale` because `libnvrtc.so` is missing from the container's dynamic linker search path: ```text WARN cudanvrtc gstcudanvrtc.cpp:163:gst_cuda_nvrtc_load_library_once: Could not open nvrtc library libnvrtc.so: cannot open shared object file: No such file or directory WARN GST_ELEMENT_FACTORY gstelementfactory.c:713:gst_element_factory_make_with_properties: no such element factory "cudaconvertscale"! INFO | Using h264 encoder: x264 WARN | Software h264 encoder detected ``` ## Steps to Reproduce 1. Deploy a standard wolf container using Docker Compose with NVIDIA CDI/container toolkit. 2. Inspect startup logs using docker logs wolf -f. 3. Observe GStreamer loading errors for cudanvrtc / cudaconvertscale and fallback to software encoders. my compose: ```yaml services: wolf: image: ghcr.io/games-on-whales/wolf:stable container_name: wolf restart: unless-stopped network_mode: host environment: - NVIDIA_DRIVER_CAPABILITIES=all - NVIDIA_VISIBLE_DEVICES=all volumes: - ./config/wolf:/etc/wolf:rw - ./data/wolf:/data:rw - /var/run/docker.sock:/var/run/docker.sock:rw - /dev/:/dev/:rw - /run/udev:/run/udev:rw device_cgroup_rules: - 'c 13:* rmw' devices: - nvidia.com/gpu=all - /dev/dri - /dev/uinput - /dev/uhid ``` nvidia version: 595.91.07 full logs in case needed: https://pastebin.com/CZPEFmnx

bsakaguchi closed this issue

2026-10-15 12:59:25 +00:00

bsakaguchi commented

2026-10-15 12:59:25 +00:00

Author

Owner

@r0b0tb4c0n commented on GitHub (Sep 18, 2026):

have you tried loading the drivers via the manual method? i had lots of weird/similar issues with the container toolkit.

@r0b0tb4c0n commented on GitHub (Sep 18, 2026): have you tried loading the drivers via the manual method? i had lots of weird/similar issues with the container toolkit.

bsakaguchi commented

2026-10-15 12:59:25 +00:00

Author

Owner

@ABeltramo commented on GitHub (Sep 21, 2026):

The underlying cause is that GStreamer fails to initialize cudaconvertscale because libnvrtc.so is missing from the container's dynamic linker search path

Sounds like an issue that should be opened in https://github.com/NVIDIA/nvidia-container-toolkit
Unfortunately the toolkit has been the cause of all sort of issues and pain over the years, which is why in our quickstart guide we recommend using the manual driver volume method instead.

@ABeltramo commented on GitHub (Sep 21, 2026): > The underlying cause is that GStreamer fails to initialize cudaconvertscale because libnvrtc.so is missing from the container's dynamic linker search path Sounds like an issue that should be opened in https://github.com/NVIDIA/nvidia-container-toolkit Unfortunately the toolkit has been the cause of all sort of issues and pain over the years, which is why in our quickstart guide we recommend using the manual driver volume method instead.

bsakaguchi referenced this issue

2026-10-15 13:00:19 +00:00

[PR #294] [MERGED] Fix CUDA memory leak #405