encoder_encode(): ioctl(VIDIOC_QBUF) failed

[mwolfeu]

Which version are you using?

v1.2.0

Which operating system are you using?

• Linux amd64 standard
• Linux amd64 Docker
• Linux arm64 standard
• Linux arm64 Docker
• Linux arm7 standard
• Linux arm7 Docker
• Linux arm6 standard
• Linux arm6 Docker
• Windows amd64 standard
• Windows amd64 Docker (WSL backend)
• macOS amd64 standard
• macOS amd64 Docker
• Other (please describe)

Describe the issue

Ioctl errors occur at low rpiCameraBitrates (100000) with rapid video changes.
Currently my camera is immobilized to prevent the cable jiggling. The 3mo old RPi 4 is on a solid platform without vibration. I have tested 5 different cameras (4 were just unboxed yesterday). All exhibit the same issue.
rpiCameraBitrate: 700000 seems stable.

I wrote a script to restart mediamtx whenever the ioctl problem prints to the logs. The camera has always (thus far) come back without issue.

Describe how to replicate the issue

1. set rpiCameraBitrates to something low (I used 1/10th the default value)
2. start the server with the rpi mipi camera configured
3. rapidly/repeatedly change the full frame of the video. I pointed it at a white wall and quickly waved my hands in front of it blocking the lens with my hand, and pulling my hand away. This never took more than 1min to break it.

Did you attach the server logs?

no

Did you attach a network dump?

no

[kawogi]

I'm having the same issue but wasn't able to nail down a root cause:

• Raspberry Pi OS (Bookworm) 32 bit on a Raspberry Pi Zero 2W with Camera Module 3
• mediamtx v1.8.1 against libcamera v0.2.0 (via symlink-hack)
• resolution/fps: 1920x1080 10 fps (iirc)
• 1-3 clients on an RTSP stream

The stream works flawlessly for a couple of hours but then it suddenly starts to endlessly report the mentioned error:

…
2024/05/13 12:07:47 INF [RTSP] [conn 10.9.9.127:34234] opened
2024/05/13 12:07:47 INF [RTSP] [session eaa5d52c] created by 10.9.9.127:34234
2024/05/13 12:07:47 INF [RTSP] [session eaa5d52c] is reading from path 'cam', with TCP, 1 track (H264)
encoder_encode(): ioctl(VIDIOC_QBUF) failed
encoder_encode(): ioctl(VIDIOC_QBUF) failed
encoder_encode(): ioctl(VIDIOC_QBUF) failed
encoder_encode(): ioctl(VIDIOC_QBUF) failed
encoder_encode(): ioctl(VIDIOC_QBUF) failed
encoder_encode(): ioctl(VIDIOC_QBUF) failed
…

I cannot tell the time difference between the last timestamped log line and the encoder_encode error.

In between the error lines there was some attempt to resume something (the camera?) and the connected clients were endlessly switching between a still image and a short video sequence which was likely the recently buffered frames in some kind of ringbuffer.

Sorry for the vague description. I'm still not able to reliably reproduce the issue. Turning down the bitrate as suggested and swinging the camera around didn't trigger it for me.

Before coming across this issue I assumed the symlink-hack was the causing this instability. I have a second setup using a freshly compiled version if mediamtx against libcamera 0.2.0 which I will try next. But without a reliable way to reproduce this issue it will be hard to tell whether things improved.

I report back as soon as I know more.

@mwolfeu Did you ever find a solution other than restarting the service?

[jknigga]

I am also having this issue.

• MediaMTX 1.8.3
• Raspberry Pi 4 running 64bit Bookworm
• Arducam OV5647

I had been running motioneye on this hardware setup for years without issue, but wanted to incorporate this camera into Frigate with an RTSP stream. I kept getting this error so I replaced the cable but that didn't fix it. Mine seems to be completely random, as sometimes it fails immediately, even before clients connect to the stream, and other times not. The longest I have had it run before dying was around 10 minutes.

[the0]

According to the link above, problem lies within the encoder and currently there is no estimation for the fix. @aler9 any chances to get libav support for rpi camera streaming anytime soon?

[aler9]

@the0 libav support for rpi camera streaming has already been implemented, it's enough to set rpiCameraCodec to softwareH264:

paths:
  rpi:
    source: rpiCamera
    # Codec. Available values: auto, hardwareH264, softwareH264
    rpiCameraCodec: softwareH264

[the0]

@aler9 I'm using 1.9.1 binary with this config section appended to the default config:

csi:
    source: rpiCamera
    rpiCameraWidth: 480
    rpiCameraHeight: 360
    rpiCameraMode: 1296:972:10:P
    rpiCameraFPS: 16
    rpiCameraCodec: softwareH264
    rpiCameraBitrate: 262144 

And getting this:

Oct 03 13:04:42 1112 mediamtx[16489]: [0:01:53.836874024] [16489]  INFO Camera camera_manager.cpp:313 libcamera v0.3.0+65-6ddd79b5-dirty (2024-09-06T11:15:57+00:00)
Oct 03 13:04:42 1112 mediamtx[16489]: [0:01:53.872167394] [16498]  WARN RPiSdn sdn.cpp:40 Using legacy SDN tuning - please consider moving SDN inside rpi.denoise
Oct 03 13:04:42 1112 mediamtx[16489]: [0:01:53.879690025] [16498]  INFO RPI vc4.cpp:446 Registered camera /base/soc/i2c0mux/i2c@1/ov5647@36 to Unicam device /dev/media1 and ISP device /dev/media2
Oct 03 13:04:42 1112 mediamtx[16489]: [0:01:53.881275593] [16489]  INFO Camera camera.cpp:1183 configuring streams: (0) 480x360-YUV420 (1) 1296x972-SGBRG10_CSI2P
Oct 03 13:04:42 1112 mediamtx[16489]: [0:01:53.882482880] [16498]  INFO RPI vc4.cpp:621 Sensor: /base/soc/i2c0mux/i2c@1/ov5647@36 - Selected sensor format: 1296x972-SGBRG10_1X10 - Selected unicam format: 1296x972-pGAA
Oct 03 13:04:42 1112 mediamtx[16489]: using software H264 encoder
Oct 03 13:04:42 1112 mediamtx[420]: 2024/10/03 13:04:42 ERR [path csi] [RPI Camera source] encoder_create(): unsupported stride: expected 480, got 512

Any ideas? Standalone rpicam-vid works fine with the same settings.

[aler9]

@the0 the problem you have is related to a limitation that happens when using that specific width/height combination, and is fixed by bluenviron/mediamtx-rpicamera#18.

I have to close this issue since there are too many, unrelated, problems reported here.

Error encoder_encode(): ioctl(VIDIOC_QBUF) failed happens when RAM is full or system is under pressure. In case someone encounters the error in a different situation and can provide useful insights, open another bug report.