GStreamer DMA issue.[radxa-a733_bullseye_kde_r3.output_512.img]

Cubie Series A7S
1

Hello Radxa team,

I am using the Radxa Cubie A7S and experiencing a GStreamer DMA issue. (radxa-a733_bullseye_kde_r3.output_512.img)

When attempting to stream a USB webcam to HDMI output using GStreamer with kmssink or fbdevsink, the pipeline fails with the following error:

VIDIOC_SET_DMA_MERGE error

I noticed that the uvcvideo module has quirks set to 0xFFFFFFFF, which suggests DMA is not properly implemented in the BSP kernel (5.15.147).

As a workaround, FFmpeg with mmap mode works fine:
ffmpeg -f v4l2 -input_format mjpeg -video_size 1920x1080 -framerate 30 -i /dev/video0 -pix_fmt bgra -f fbdev /dev/fb0

However, GStreamer pipelines consistently fail due to this DMA issue. Could you please look into implementing VIDIOC_SET_DMA_MERGE support in the uvcvideo driver for the sunxi USB controller?

Environment:

  • Board: Radxa Cubie A7S
  • Kernel: 5.15.147-15-a733
  • OS: Debian GNU/Linux
  • GStreamer version: installed via apt

Thank you.

2

I also experienced a similar problem.

I use r4 cli.

In the end, I couldn’t solve it with gstreamer, so I solved it by piping it with ffmpeg.

ffmpeg -f v4l2 -c:v mjpeg -video_size 3200x1200 -framerate 25 -i /dev/video0
-f rawvideo -pix_fmt yuvj422p - |
gst-launch-1.0 fdsrc blocksize=5760000 do-timestamp=true !
rawvideoparse width=3200 height=1200 format=y42b framerate=25/1 !
queue leaky=downstream max-size-buffers=1 !
videoconvert !
omxh264videoenc control-rate=constant target-bitrate=10000000
periodicity-idr=25 interval-intraframes=25 b-frames=0 !
video/x-h264,profile=baseline,stream-format=byte-stream ! h264parse !
rtspclientsink location=rtsp://localhost:8554/mystream protocols=udp sync=false

3

The entire process is as follows.

sudo apt update

sudo rsetup # system → update

sudo apt install task-a733-vpu

sudo apt -f install

sudo apt install -y
gstreamer1.0-tools
gstreamer1.0-plugins-base
gstreamer1.0-plugins-good
gstreamer1.0-plugins-bad
gstreamer1.0-plugins-ugly
gstreamer1.0-libav
gstreamer1.0-nice
gstreamer1.0-plugins-rtp
gstreamer1.0-rtsp
ffmpeg
v4l-utils

#make file
sudo nano /etc/udev/rules.d/99-cedar-permissions.rules

#send to file ‘99-cedar-permissions.rules’ below 3 line
KERNEL==“cedar_dev*”, MODE=“0666”
SUBSYSTEM==“dma_heap”, KERNEL==“system”, MODE=“0666”
KERNEL==“video*”, MODE=“0666”, GROUP=“video”

#re launch
sudo udevadm control --reload-rules && sudo udevadm trigger

sudo usermod -aG video radxa

#check rights
ls -l /dev/cedar_dev* /dev/dma_heap/system

#omx enc test command
ffmpeg -f v4l2 -video_size 1280x480 -i /dev/video0 -f rawvideo -pix_fmt nv12 - |
gst-launch-1.0 fdsrc blocksize=921600 !
videoparse width=1280 height=480 format=nv12 framerate=15/1 !
queue max-size-buffers=100 !
omxh264videoenc ! h264parse !
video/x-h264,stream-format=byte-stream !
filesink location=stereo_final.h264

#check file size
ls -l stereo_final.h264

#install mediamtx
wget https://github.com/bluenviron/mediamtx/releases/download/v1.17.0/mediamtx_v1.17.0_linux_arm64.tar.gz
tar -xvzf mediamtx_v1.17.0_linux_arm64.tar.gz

#run on another session
#./mediamtx

#from usb camera
#run! but 30fps performance is lacking.
ffmpeg -f v4l2 -c:v mjpeg -video_size 3200x1200 -framerate 25 -i /dev/video0
-f rawvideo -pix_fmt yuvj422p - |
gst-launch-1.0 fdsrc blocksize=5760000 do-timestamp=true !
rawvideoparse width=3200 height=1200 format=y42b framerate=25/1 !
queue leaky=downstream max-size-buffers=1 !
videoconvert !
omxh264videoenc control-rate=constant target-bitrate=10000000
periodicity-idr=25 interval-intraframes=25 b-frames=0 !
video/x-h264,profile=baseline,stream-format=byte-stream ! h264parse !
rtspclientsink location=rtsp://localhost:8554/mystream protocols=udp sync=false

#check speed=1.0

4

As far as I understand, FFmpeg and GStreamer (gst-launch) use different processing methods.

In my case, FFmpeg works properly, but gst-launch does not operate correctly due to a DMA-related issue.

For performance reasons, we need to process data using hardware blocks. However, if gst-launch cannot be used due to the DMA issue, it will significantly impact our development progress.

I understand that this issue may require kernel modifications. Has Radxa released any updated kernel version addressing this problem?

5

In adxa_cubie_a733_trixie_cli_beta_v2(https://dl.radxa.com/cubie/a7s/images/radxa_cubie_a733_trixie_cli_beta_v2.gpt.zip), GStreamer runs independently. However, hardware encoding does not work.