ffmpeg error "Hardware does not support image size"

[john-]

I am trying to get vaapi enabled in Viseron. Things looks good initially:

viseron  | ****** Checking for hardware acceleration platforms ******
viseron  | OpenCL cannot be used
viseron  | VA-API is available!
viseron  | CUDA cannot be used                                                                      

However, at end of Viseron initialization I get these errors:

viseron  | 2026-01-18 14:37:36.846 [INFO    ] [viseron.core] - Viseron initialized in 3.2 seconds
viseron  | 2026-01-18 14:37:37.982 [ERROR   ] [viseron.components.ffmpeg.stream.camera_1] - [h264 @ 0x55ce1f1c7200] Hardware does not support image size 1920x1088 (constraints: width 64-0 height 64-0).                                                                                                   viseron  | 2026-01-18 14:37:37.983 [ERROR   ] [viseron.components.ffmpeg.stream.camera_1] - [h264 @
0x55ce1f1c7200] Failed setup for format vaapi: hwaccel initialisation returned error.

Things are working (e.g. object detection and recording of events) however based on error it is without vaapi.

The video stream is 1920x1080 and not 1920x1088. I am basing this on output of mediainfo with streams recorded directly off the camera. Also, all the captured screen shots from Viseron are 1920x1080.

So it seems like maybe there is something going wrong with ffmpeg probing? To bypass the probe here is the current ffmpeg section of my config:

ffmpeg:
  camera:
    camera_1:  # This value has to be unique across all cameras
      name: backyard_1
      host: !secret camera_1_host
      port: 554
      path: /axis-media/media.amp
      username: !secret camera_1_username
      password: !secret camera_1_password
      width: 1920
      height: 1080
      fps: 16
      # codec: mjpeg
      recorder:
        idle_timeout: 1
        codec: h264
        create_event_clip: true
      mjpeg_streams:
        objects:
          draw_objects: true
          draw_zones: true
          draw_motion: true
          draw_motion_mask: true
          draw_object_mask: true

Per the documentation it should be possible to supply the information gathered by the probe. However, I have not been able to provide a value for codec that results in the camera working in Viseron. It shows offline and there is nothing obvious in the logs.

What is the next step to diagnose this? I can provide my full config if that is relevant.

[john-]

I ran this probe:

sudo docker exec -it viseron ffprobe -loglevel trace -print_format json -show_streams -show_error rtsp://my_id:my_password@host/media.amp

The json part of the output:

   "streams": [
        {
            "index": 0,
            "codec_name": "h264",
            "codec_long_name": "unknown",
            "profile": "77",
            "codec_type": "video",
            "codec_tag_string": "[0][0][0][0]",
            "codec_tag": "0x0000",
            "width": 1920,
            "height": 1080,
            "coded_width": 1920,
            "coded_height": 1080,
            "closed_captions": 0,
            "film_grain": 0,
            "has_b_frames": 0,
            "sample_aspect_ratio": "1:1",
            "display_aspect_ratio": "16:9",
            "pix_fmt": "yuvj420p",
            "level": 41,
            "color_range": "pc",
            "color_space": "bt709",
            "color_transfer": "bt709",
            "color_primaries": "bt709",
            "chroma_location": "center",
            "field_order": "progressive",
            "refs": 1,
            "is_avc": "false",
            "nal_length_size": "0",
            "r_frame_rate": "30/1",
            "avg_frame_rate": "30/1",
            "time_base": "1/90000",
            "start_pts": 3000,
            "start_time": "0.033333",
            "bits_per_raw_sample": "8",
            "extradata_size": 40,
            "disposition": {
                "default": 0,
                "dub": 0,
                "original": 0,
                "comment": 0,
                "lyrics": 0,
                "karaoke": 0,
                "forced": 0,
                "hearing_impaired": 0,
                "visual_impaired": 0,
                "clean_effects": 0,
                "attached_pic": 0,
                "timed_thumbnails": 0,
                "captions": 0,
                "descriptions": 0,
                "metadata": 0,
                "dependent": 0,
                "still_image": 0
            }
        }

So I looked at where in the probe 1920x1088 was coming from as the json showed 1080:

[rtsp @ 0x55866ec10940] line=''
[h264 @ 0x55866ec16940] nal_unit_type: 7(SPS), nal_ref_idc: 3
[h264 @ 0x55866ec16940] nal_unit_type: 8(PPS), nal_ref_idc: 3
[h264 @ 0x55866ec16940] nal_unit_type: 7(SPS), nal_ref_idc: 3
[h264 @ 0x55866ec16940] nal_unit_type: 8(PPS), nal_ref_idc: 3
[rtsp @ 0x55866ec10940] sending 56 bytes of RR
[rtsp @ 0x55866ec10940] result from ffurl_write: 56
[h264 @ 0x55866ec16940] nal_unit_type: 5(IDR), nal_ref_idc: 3
[h264 @ 0x55866ec16940] Format yuvj420p chosen by get_format().
[h264 @ 0x55866ec16940] Reinit context to 1920x1088, pix_fmt: yuvj420p
[rtsp @ 0x55866ec10940] sending 56 bytes of RR
[rtsp @ 0x55866ec10940] result from ffurl_write: 56
[h264 @ 0x55866ec16940] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 2

Note: I removed a bunch of what look like control characters so hopefully did not screw anything up.

And later:

  Metadata:
    title           : Session streamed with GStreamer
    comment         : rtsp-server
  Duration: N/A, start: 0.033333, bitrate: N/A
  Stream #0:0^[[0;32m, 28, 1/90000^[[0m: Video: h264, 1 reference frame, yuvj420p(pc, bt709, progressive, center), 1920x1080 (1920x1088) [SAR 1:1 DAR 16:9], 0/1, 30 fps, 30 tbr, 90k tbn

So I figured maybe it is an issue with how my camera responds to a probe. So based on docs I tried to specify what I could of these values:

ffmpeg:
  camera:
    camera_1:
      name: backyard_1
      host: !secret camera_1_host
      port: 554
      path: /axis-media/media.amp
      username: !secret camera_1_username
      password: !secret camera_1_password
      width: 1920
      height: 1080
      fps: 16
      codec: h264
      audio_codec: null
      recorder:
        idle_timeout: 1
        codec: h264
        create_event_clip: true

However, the issue still occurs:

viseron  | 2026-01-23 15:29:55.729 [ERROR   ] [viseron.components.ffmpeg.stream.camera_1] - [h264 @ 0x55baa3d3d7c0] Hardware does not support image size 1920x1088 (constraints: width 64-0 height 64-0).
viseron  | 2026-01-23 15:29:55.731 [ERROR   ] [viseron.components.ffmpeg.stream.camera_1] - [h264 @ 0x55baa3d3d7c0] Failed setup for format vaapi: hwaccel initialisation returned error.

Any ideas?

[roflcoopter]

The probe information is only used to tell Viseron how to process frames, it's not used to specify anything when actually running ffmpeg later. I am not sure how ffmpeg gets that wrong tho, maybe you can force the width and height in the ffmpeg command somehow?

[john-]

Thanks for the information on ffprobe. Also, I did try forcing width/height but that does not seem to be the issue.

I do see that there is difference in vainfo inside and outside the container.

Inside Viserion container:

vainfo --display drm
Trying display: drm
libva info: VA-API version 1.20.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/r600_drv_video.so
libva info: Found init function __vaDriverInit_1_20
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.20 (libva 2.20.0)
vainfo: Driver version: Mesa Gallium driver 24.0.0-devel for HAWAII (radeonsi, , LLVM 15.0.7, DRM 2.50, 6.12.63+deb13-amd64)
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointVLD
      VAProfileNone                   : VAEntrypointVideoProc

On the host:

vainfo --display drm
Trying display: drm
libva info: VA-API version 1.22.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/r600_drv_video.so
libva info: Found init function __vaDriverInit_1_22
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.22 (libva 2.22.0)
vainfo: Driver version: Mesa Gallium driver 25.0.7-2 for HAWAII (radeonsi, , ACO, DRM 2.50, 6.12.63+deb13-amd64)
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointEncSlice
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointEncSlice
      VAProfileNone                   : VAEntrypointVideoProc

The VAEntrypointEncSlice entries are missing in the Viseron container. That is related to encoding which may be what ffmpeg is using and failing on.

I am still investigating. Maybe it is a driver issue but not sure yet.

[john-]

For debugging I modified my running container by installed more recent video drivers (kisak ppa). That seems to address the issue:

vainfo --display drm
Trying display: drm
libva info: VA-API version 1.20.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/r600_drv_video.so
libva info: Found init function __vaDriverInit_1_14
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.20 (libva 2.20.0)
vainfo: Driver version: Mesa Gallium driver 25.0.7 - kisak-mesa PPA for HAWAII (radeonsi, , ACO, DRM 2.50, 6.12.63+deb13-amd64)
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointEncSlice
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointEncSlice
      VAProfileNone                   : VAEntrypointVideoProc

If I kill ffmpeg it restarts without the error. Also, processor utilization is decreased. I am pretty sure the issue is the version of mesa gallium driver that is in the Viseron docker image.

[roflcoopter]

Do you get any more hints if you run the ffmpeg command at the command line with debug?

[john-]

I will edit my previous comment to indicate that after restarting ffmpeg it restarts without the error (I had a typo in the that comment). Also, there is a lot less processor consumed. I am pretty sure the issue is the version of mesa gallium driver that is in the Viseron docker image.

[roflcoopter]

I see, good find. Can you outline the commands that you ran to install the newer version?

[john-]

I did these steps to debug what the issue might be.

From this page I generally followed the steps "Method 2: Install Kisak-Mesa Stable PPA (Ubuntu 22.04 and 24.04 LTS)".

I expect (but not confirmed) that more recent versions of Ubuntu include updated mesa libraries. If Viseron has plans to move to more recent Ubuntu than that may also address this issue.

Also note that the issue may be specific to the driver version and my make/model of graphics card or something else equally esoteric. No one else seems to be complaining about this.

I did these steps after getting a shell in the running Viseron docker container. For example, with docker exec -it viseron /bin/bash.

add-apt-repository ppa:kisak/turtle -y
apt update
apt install mesa-va-drivers    # this brings in multiple other graphics related packages
kill <ffmpeg process>

After this Vierson restarts the ffmpeg process and appears to work as normal. I did not do any testing beyond looking at live view and generating a recording. Events seem to be captured as expected.

I don't see the steps I took as the solution to the problem but more done trying to assess root cause. I can live with the (much) higher processor utilization.

[john-]

Upgrade/install detail from the install step above:

apt install mesa-va-drivers
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  libdrm-amdgpu1 libdrm-common libdrm-dev libdrm-intel1 libdrm-nouveau2 libdrm-radeon1 libdrm2
  mesa-libgallium
The following NEW packages will be installed:
  mesa-libgallium
The following packages will be upgraded:
  libdrm-amdgpu1 libdrm-common libdrm-dev libdrm-intel1 libdrm-nouveau2 libdrm-radeon1 libdrm2
  mesa-va-drivers
8 upgraded, 1 newly installed, 0 to remove and 11 not upgraded.

[roflcoopter]

Thanks! Viseron runs on 22.04 mainly for the many hardware acceleration dependencies that are not always updated with new releases of Ubuntu, but since 24.04 is fairly old now it should be safe to move over.

It requires some work tho so short term i could add the kisak ppa to the builds

[john-]

Thanks for that option but I am thinking that since it is just me impacted it makes more sense to wait until a future switch to 24.04. I am not in a hurry and if performance starts to concern me I can do the update as needed on my side.