Hardware accelerated video decoding fails with gstreamer on Radxa Zero SBC

langweiler · August 11

I am running the Ubuntu Noble 24.04 XFCE image on a Radxa Zero SBC (first generation device). Trying to play a video with parole (gstreamer video player) produces the error message "GStreamer Backend Error: Could not read from resource. "

errormessage.png.64ceb6533663a76d6eea29295e49ca04.png

Increasing the gstreamer debug level produces the following additional information:

0:00:00.329008719 131342 0xaaab079354e0 WARN     GST_ELEMENT_FACTORY gstelementfactory.c:765:gst_element_factory_make_valist: no such element factory "autoimagesink"!
0:00:05.702394971 131342 0xffff7c0013d0 ERROR         v4l2bufferpool gstv4l2bufferpool.c:716:gst_v4l2_buffer_pool_streamon:<v4l2h264dec0:pool0:sink> error with STREAMON 22 (Invalid argument)
0:00:05.702572595 131342 0xffff7c0013d0 ERROR         v4l2bufferpool gstv4l2bufferpool.c:2233:gst_v4l2_buffer_pool_process:<v4l2h264dec0:pool0:sink> failed to start streaming
0:00:05.703109216 131342 0xffff7c000da0 WARN                    v4l2 gstv4l2object.c:5887:gst_v4l2_object_poll:<v4l2h264dec0> error: poll error 1: Connection timed out (110)
0:00:05.703217049 131342 0xffff7c0011a0 WARN                 qtdemux qtdemux.c:7423:gst_qtdemux_loop:<qtdemux0> error: Internal data stream error.
0:00:05.703483881 131342 0xffff7c0011a0 WARN                 qtdemux qtdemux.c:7423:gst_qtdemux_loop:<qtdemux0> error: streaming stopped, reason error (-5)

Looks like there is an issue with the v4l device provided by the meson_vdec kernel module. Removing the meson_vdec kernel module indeed eliminates problem. Videos are played without error message using software decoding. The frame rate is unfortunately low. Otherwise I would not care about hardware decoding.

Interestingly, the v4l2-compliance command suggests that the v4l device for the VPU is in good shape:

$ v4l2-compliance
v4l2-compliance 1.26.1, 64 bits, 64-bit time_t

Compliance test for meson-vdec device /dev/video0:

Driver Info:
    Driver name      : meson-vdec
    Card type        : Amlogic Video Decoder
    Bus info         : platform:meson-vdec
    Driver version   : 6.6.31
    Capabilities     : 0x84204000
        Video Memory-to-Memory Multiplanar
        Streaming
        Extended Pix Format
        Device Capabilities
    Device Caps      : 0x04204000
        Video Memory-to-Memory Multiplanar
        Streaming
        Extended Pix Format
    Detected Stateful Decoder

Required ioctls:
    test VIDIOC_QUERYCAP: OK
    test invalid ioctls: OK

Allow for multiple opens:
    test second /dev/video0 open: OK
    test VIDIOC_QUERYCAP: OK
    test VIDIOC_G/S_PRIORITY: OK
    test for unlimited opens: OK

Debug ioctls:
    test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
    test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
    test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
    test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
    test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
    test VIDIOC_ENUMAUDIO: OK (Not Supported)
    test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
    test VIDIOC_G/S_AUDIO: OK (Not Supported)
    Inputs: 0 Audio Inputs: 0 Tuners: 0

Output ioctls:
    test VIDIOC_G/S_MODULATOR: OK (Not Supported)
    test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
    test VIDIOC_ENUMAUDOUT: OK (Not Supported)
    test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
    test VIDIOC_G/S_AUDOUT: OK (Not Supported)
    Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
    test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
    test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
    test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
    test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls:
    test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
    test VIDIOC_QUERYCTRL: OK
    test VIDIOC_G/S_CTRL: OK
    test VIDIOC_G/S/TRY_EXT_CTRLS: OK
    test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
    test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
    Standard Controls: 2 Private Controls: 0

Format ioctls:
    test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
    test VIDIOC_G/S_PARM: OK (Not Supported)
    test VIDIOC_G_FBUF: OK (Not Supported)
    test VIDIOC_G_FMT: OK
    test VIDIOC_TRY_FMT: OK
    test VIDIOC_S_FMT: OK
    test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
    test Cropping: OK (Not Supported)
    test Composing: OK (Not Supported)
    test Scaling: OK (Not Supported)

Codec ioctls:
    test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
    test VIDIOC_G_ENC_INDEX: OK (Not Supported)
    test VIDIOC_(TRY_)DECODER_CMD: OK

Buffer ioctls:
    test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
    test CREATE_BUFS maximum buffers: OK
    test VIDIOC_EXPBUF: OK
    test Requests: OK (Not Supported)

Total for meson-vdec device /dev/video0: 46, Succeeded: 46, Failed: 0, Warnings: 0

What is the current status of meson VPU support? Is this a known issue? Has anyone ever got video hardware decoding to work with the Radxa Zero SBC?

Thanks for any hint in advance!

armbianmonitor.txt

Edited August 11 by langweiler

usual user · August 11

2 hours ago, langweiler said:

What is the current status of meson VPU support?

See here.

langweiler · August 25

Thanks for pointing me to the other thread. I have to admit that I am quite disappointed. The summary of the situation by chewitt was already posted in Aug 2021. And still hardware accelerated video decoding is broken at least on the Radxa Zero device albeit it seemed to have been working for some time and the hardware has been around for ages (that is at least my impression).

This is no by no means an accusation and I very much love the work done by Armbian developers. I am more frustrated about the marketing by companies like Radxa who advertise the impressive capabilities of their SBCs, but do not ensure the necessary driver support. What is the point of having powerful hardware (and having to pay the price for it) if in the end software support is not mature and you cannot benefit from it?

Hopefully, somebody from Radxa is reading this. There is room for improvement! Be outstanding and deliver the best hardware *and* software combination available on the market! I am willing to pay for it!

Igor · August 26

9 hours ago, langweiler said:

I am willing to pay for it!

From our point of view, end users cover less then 0.5% of the software investment we provide for everyone, including projects that competes with us with our investments ...

Hardware dealers sells hardware with promise of software support. You buy numbers and features ... and then there is new HW coming out. And new, and new ...

10 hours ago, langweiler said:

somebody from Radxa is reading this

This is everyone's biz case. The more HW sell the better for them, the bigger is the pressure on us and the rest of developers community. Sadly a lot of Linux distributions contributes close to nothing, or 1/1000 of what we contribute, but can sell the same. Investing even more into development + support and less in sales is self-destructive. Remember, you want this for free, while getting here costs are extreme.

10 hours ago, langweiler said:

I very much love the work done by Armbian developers.

Than you for your support!. Sadly expressions of love and support doesn't pay our bills You have to improve your share One day of support financial damages are not collected at GitHub in one year. For those that have time, but no money, we support them instead of you. We do everything possible to improve software and this huge discrepancy.

langweiler · September 14

Hi Igor,

Thanks for your comprehensive reply. As written before, I did not mean to accuse the Armbian developer team in any way. I am only a private end user. I am tinkering around with SBCs and run Armbian on two devices. I can donate a few Euros (and just did). Unfortunately, that is not going to change the situation. You probably need 100 times the amount I donated to implement hardware accelerated video decoding realiably - at least if done by a professional.

I am not sure if I understand the Armbian business model. In my view, the only model that will work reliably is if the cost for software development is factored into the price for the hardware. When I buy a device from Radxa, I expect the proper software to come with it. If Radxa is not able to provide the necessary software, they should pay someone else to do so. That is why I wrote "I hope someone from Radxa is reading this." in my previous post.

This would also take the pressure from new hardware coming out. New hardware would mean new revenues for everyone. In general, new hardware should only be launched after reasonably stable software can be provided with it. At the moment, I buy hardware from Radxa with great features, which I am not able to use. And those deficits are not clearly stated on their web page. This is where my frustration comes from. It has nothing to do with Armbian at all.