Genio-520 (MT8371) VPU hardware decoder not working

General Discussion
, , , ,
1

Hello,

We are working with MediaTek Genio-520 EVK (MT8371) and facing an issue where VPU hardware decoding is not functional, while the same software stack works correctly on Genio-510 (MT8370).

Below are the observations and differences we found. We would appreciate your guidance on what is missing or needs to be enabled for MT8371.

Working Platform
Board: Genio-510 EVK
SoC: MT8370
Kernel: 6.6.37-mtk
Result: VPU hardware decoding works
G510 – dmesg output
read_img: vpu_fw request_firmware cam_vpu1 success
read_img: vpu_fw request_firmware cam_vpu2 success
read_img: vpu_fw request_firmware cam_vpu3 success
apusys_load_image: vpu_fw request_firmware mediatek/mt8370/apusys.sig.img success
vpu_probe: succeed
G510 – runtime
/sys/class/devfreq/soc:vpu_devfreq
G510 – firmware present
/lib/firmware/mediatek/mt8370/
├─ cam_vpu1.img
├─ cam_vpu2.img
├─ cam_vpu3.img
└─ apusys.sig.img
Non-working Platform
Board: Genio-520 EVK
SoC: MT8371
Kernel: 6.6.37-mtk
Result: Hardware decoder not used (software decode only)
G520 – dmesg output
mvpu_init: register platform driver pass
mtk-apu: creating channel mvpu-tx-rpmsg
[VCU] mtk_vcu_open name: vpud
Missing on G520

No vpu_fw request_firmware
No vpu_probe: succeed
No soc:vpu_devfreq
G520 – firmware check
/lib/firmware/mediatek/
├─ apusys.sig.img
└─ mt8371/apusys.sig.img
:cross_mark: No cam_vpu*.img for MT8371

Kernel Configuration
The following options are enabled in kernel:

CONFIG_MTK_VPU=y
CONFIG_MTK_VPU_FW=y
CONFIG_MTK_VPU_DEVFREQ=y
However:

/sys/class/devfreq/soc:vpu_devfreq is not created
request_firmware(cam_vpu*) is never triggered
Questions / Clarification Needed
Does MT8371 (Genio-520) require cam_vpu*.img firmware similar to MT8370?

If yes, where can we obtain the correct MT8371 VPU firmware?
Is VPU camera/codec firmware intentionally not provided for MT8371 in current BSP?

Are additional device-tree nodes required to enable VPU firmware loading on MT8371?

If possible, could you share the required DT bindings or reference DTS?
Is mvpu + VCU support sufficient for video decode on MT8371, or is classic vpu_core not supported?

Is hardware video decode officially supported on Genio-520 in the current Linux BSP?

If yes, which components must be enabled (firmware / DT / userspace)?
Summary
VPU hardware exists on MT8371
Kernel driver loads (mvpu_init)
But firmware is not loaded
No devfreq node is created
Hardware decoder is not used
We would appreciate clarification on missing firmware, DT requirements, or BSP limitations for enabling VPU hardware decoding on Genio-520.

Thank you for your support.

2

Yes, we support HW video decode on Genio-520.
Please refer to the web doc:

And video decoder does not need cam_vpu*.img.

3

Hi @macross.chen ,

I am attempting to decode an H.264 encoded video stream using hardware acceleration on my system. However, the pipeline fails to utilize the hardware decoder and consistently falls back to software-based decoding, or fails to initialize entirely with an error.

Command Executed:

gst-launch-1.0 filesrc location=raw.h264 ! \
  h264parse config-interval=1 ! \
  v4l2h264dec ! videoconvert ! autovideosink

Observed Behavior:

  • The v4l2h264dec element is failing to process the stream.

  • System logs indicate a fallback to software libraries.

  • occuring with a specific error “Internal data stream error.”

I have attached following scenario i tried and there observations for the hardware H.264 encoder and decoder on the Genio-520 platform are functional using GStreamer, and to compare behavior with software decoding.

Step 1: Hardware H.264 Encoding Validation (Camera → H.264 File)

The following pipeline is used to validate hardware-based H.264 encoding using v4l2h264enc with a USB camera (/dev/video2).

gst-launch-1.0 -e -v \
v4l2src device=/dev/video2 ! \
videoconvert ! \
video/x-raw,format=NV12,width=640,height=480,framerate=30/1 ! \
v4l2h264enc extra-controls="controls,h264_profile=0" ! \
h264parse config-interval=1 ! \
filesink location=test_baseline.h264

Result

  • H.264 file test_baseline.h264 is successfully generated.

  • Confirms that camera capture + hardware H.264 encoder are working correctly.

Step 2: Hardware H.264 Decoding Validation (File → Display)

The encoded H.264 file is decoded using the hardware decoder v4l2h264dec and displayed using Wayland sink.

gst-launch-1.0 -v \
filesrc location=test_baseline.h264 ! \
h264parse ! \
v4l2h264dec ! \
gtkwaylandsink

Result

  • Pipeline fails / video is not rendered.

  • Indicates hardware H.264 decoder is not functional on this platform.

Step 3: Software H.264 Decoding Validation (File → Display)

The same H.264 file is decoded using the software decoder avdec_h264.

gst-launch-1.0 -v \
filesrc location=test_baseline.h264 ! \
h264parse ! \
avdec_h264 ! \
gtkwaylandsink

Result

  • Video plays successfully.

  • Confirms that:

    • The H.264 bitstream is valid

    • Display pipeline and Wayland sink are functional

    • Failure is not related to the encoder, camera, or file format

Conclusion

  • Hardware H.264 encoding (v4l2h264enc) works correctly

  • Hardware H.264 decoding (v4l2h264dec) does not work

  • Software decoding (avdec_h264) works reliably

  • This strongly indicates a hardware decoder / driver / firmware issue, not a GStreamer pipeline or caps negotiation issue.

    This is the error signature i am observing when i use hardware decoder.

    image
    image1860×152 35.5 KB

Thank you for your support.

4

The video decoder output format is MM21 format, which waylandsink cannot display directly. (Output Format of Video Decoder)

As the online document states, you need to add a “v4l2convert“(hardware converter) or “videoconvert“(software converter) between v4l2h264dec and waylandsink. (MDP and Format Conversion)

For example:

gst-launch-1.0 -v \
filesrc location=test_baseline.h264 ! \
h264parse ! \
v4l2h264dec ! \
v4l2convert ! video/x-raw,format=NV12 ! \
gtkwaylandsink

Please try it again with the video converter. Thank you.

6

Hi @macross.chen,

Thank you for the clarification regarding the MM21 output format and the requirement for v4l2convert in the GStreamer pipeline. We have tested the pipeline exactly as suggested:

gst-launch-1.0 -v \
 filesrc location=test_baseline.h264 ! \
 h264parse ! \
 v4l2h264dec ! \
 v4l2convert ! video/x-raw,format=NV12 ! \
 gtkwaylandsink

However, hardware decoding on Genio‑520 (MT8371) is still not working.

So the issue does not appear related to the output format or sink compatibility the decoder itself is still not engaging the hardware VPU on MT8371.

7

Hi @chetan_g ,

Could you please provide the error log? (gstreamer console log)

Alternatively, did you try the example in the online documentation?

Video encode example:

gst-launch-1.0 -v videotestsrc num-buffers=300 ! "video/x-raw,format=NV12,width=720,height=480,framerate=30/1"  ! v4l2h264enc extra-controls="cid,video_gop_size=30,video_bitrate=512000,sequence_header_mode=1" ! "video/x-h264,level=(string)4.1,profile=main" ! h264parse ! mp4mux ! filesink location=/tmp/test-h264.mp4

Then, run the video decode command to decode the encoder output mp4 file:

gst-launch-1.0 -v filesrc location=/tmp/test-h264.mp4 ! parsebin ! capssetter caps="video/x-h264, colorimetry=(string)bt601" ! v4l2h264dec ! v4l2convert output-io-mode=dmabuf-import capture-io-mode=dmabuf ! waylandsink

Thanks.

8

Hi @chetan_g ,

It might be the issue mentioned in the online documentation – The Colorimetry Issue of v4l2* Plugins.

Please try adding “capssetter” to overwrite the colorimetry to pass the GST v4l2object check.

gst-launch-1.0 -v filesrc location=test_baseline.h264 ! h264parse ! capssetter caps=“video/x-h264,colorimetry=bt709” ! v4l2h264dec ! videoconvert ! waylandsink

Thanks.

9

Hi @macross.chen,

Thanks for the suggestion. I tested the pipeline with the capssetter to force colorimetry=bt709, as recommended:

gst-launch-1.0 -v filesrc location=test_baseline.h264 ! \
h264parse ! \

capssetter caps="video/x-h264,colorimetry=bt709" ! \

v4l2h264dec ! videoconvert ! waylandsink

Unfortunately, hardware decoding on Genio‑520 (MT8371) is still not working.

Here are the detailed observations:

  1. Even with the colorimetry override, the system never triggers request_firmware() for any of the cam_vpu*.img files (unlike MT8370 on Genio‑510).

  • No vpu_fw load messages appear in dmesg

  • No vpu_probe: succeed

  • No soc:vpu_devfreq node is created under /sys/class/devfreq

    1. Firmware Folder Still Missing MT8371 VPU Binaries
      The available firmware files under /lib/firmware/mediatek/ only contain:

  • apusys.sig.img

  • mt8371/apusys.sig.img

There are no cam_vpu1.img, cam_vpu2.img, or cam_vpu3.img equivalents for MT8371, which exist for MT8370 on Genio‑510.

Output logs:
30-05-2025 08:59:08 - INFO : START_LIVE
30-05-2025 08:59:08 - INFO : CRtspClientViewer created
30-05-2025 08:59:08 - INFO : rtsps://192.168.2.3:8554/live
30-05-2025 08:59:08 - INFO : rtspsrc name=src location=rtsps://192.168.2.3:8554/live protocols=tcp latency=100 ! rtph264depay ! h264parse ! capssetter caps=‘video/x-h264,colorimetry=bt709’ ! v4l2h264dec ! videoconvert ! gtksink sync=false
30-05-2025 08:59:08 - INFO : Checking certificate: /root/clinetEXE/server.crt
30-05-2025 08:59:08 - INFO : server.crt found, loading
30-05-2025 08:59:08 - INFO : server.crt loaded successfully
30-05-2025 08:59:08 - INFO : Pipeline PLAYING
30-05-2025 08:59:08 - INFO : OK_STARTED

30-05-2025 08:59:09 - WARNING : GStreamer error �~@~T retrying in 3s
30-05-2025 08:59:15 - INFO : STOP_LIVE
30-05-2025 08:59:16 - INFO : Pipeline stopped and released
30-05-2025 08:59:16 - INFO : OK_STOPPED

screenshot of the outcome:

image
image800×600 74.4 KB

thank you,

10

Hi @chetan_g ,

Please verify HW encoder and decoder with the command in online documentation first.

Genio-520 (MT8371) VPU hardware decoder not working - #7 by macross.chen

Thanks.

11

Hi @macross.chen,

Thank you for your support.

We’ve verified that the hardware decoder on the G520 handles MP4 files correctly.

However, RAW video frame capture remains non-functional. Since this same code works on the G510 SoC, the issue appears specific to the G520 hardware decoder integration.

We are still blocked by the same error : Genio-520 (MT8371) VPU hardware decoder not working - #9 by chetan_g

12

Hi @chetan_g ,

If the H264 MP4 file test passes, the G520 HW decoder should work properly.

Regarding the raw video frame playback issue, could you please provide the error log?

(please provide gstreamer console log (with -v), kernel log, and vpud log)

journalctl -o short-monotonic -u vpud > /tmp/vpud.log
journalctl -o short-monotonic -k > /tmp/dmesg.txt

Since RTSP streaming can be affected by many factors (such as network, firewall, and UDP packet loss), we recommend testing it with local file playback first.

Thanks.

13

Hi @macross.chen

We tested RTSP streaming with the Genio-520 hardware decoder (v4l2h264dec) and collected the requested logs. Since the logs are huge and cannot be attached here, i’ll paste the error logs

Client pipeline:


rtspsrc location=rtsps://192.168.2.3:8554/live protocols=tcp latency=100 !
rtph264depay !
h264parse !
v4l2h264dec !
videoconvert !
gtksink sync=false

GStreamer error log:


/GstPipeline:pipeline0/GstH264Parse:h264parse0.GstPad:src: caps = video/x-h264,
width=(int)640, height=(int)480, framerate=(fraction)0/1, profile=(string)baseline
ERROR: from element /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0:streaming stopped, reason not-negotiated (-4)

VPUD log:

try decode_id -1, svp -1try decode_id 1, svp 0codec id match! VDEC_H264 codec fmt (1)

handle_init_msg ap_vdec_inst[0]: 0x8, codec_id: 1== handle_init_msg()- == ctx_id 8, ret=0

eVDecDrvDeInit NULL phHandle->hDrvHandle

Kernel log:

No additional V4L2 or decoder related errors were observed during playback.

Could you please help identify why v4l2h264dec fails with not-negotiated (-4) when decoding the RTSP stream?

14

Hi @chetan_g ,

We have tried gst-rtsp-server on Genio-720 as an RTSP streaming server.

To stream the colorbar test pattern, use the following command:

root@genio-720-evk-ufs:~# test-launch “( videotestsrc is-live=true ! video/x-raw,rate=30,width=640,height=480 ! v4l2h264enc ! rtph264pay name=pay0 pt=96 )”

On the Genio-520, as the client:

root@genio-520-evk-ufs:~# gst-launch-1.0 -v rtspsrc location=rtsp://192.168.68.59:8554/test latency=0 ! rtph264depay ! h264parse ! capssetter caps=“video/x-h264,colorimetry=bt601” ! v4l2h264dec ! capssetter caps=“video/x-raw,colorimetry=bt601” ! v4l2convert ! waylandsink

The colorbar test image shows normally on the Genio 520 panel.

NOTE: There is a colorimetry issue with gst-v4l2object; using capssetter serves as a workaround.

15

Hi @macross.chen

Thank you for your support.

The hardware decoder issue was resolved by applying the colorimetry workaround suggested in your reply. Adding the following elements fixed the negotiation problem with v4l2h264dec:

capssetter caps=“video/x-h264,colorimetry=bt601”
capssetter caps=“video/x-raw,colorimetry=bt601”

After adding capssetter and a queue after rtph264depay, the stream decodes correctly using the hardware decoder on Genio-520.

Thank you for the suggestion.