A733 zero copy hardware decoding

If you've tried hardware video on an Allwinner A733 (Orange Pi 4 Pro, Radxa A7Z), you've probably hit this: there's no V4L2 decoder, and omxh264dec advertises video/x-raw(memory:DMABuf) but aborts in gst_omx_video_dec_negotiate if you actually ask for it. So everyone falls back to videoconvert ! ximagesink and burns ~1.8 CPU cores on 1080p.

The vendor OMX component reports the proprietary colour format 0x7f000002 through a malformed port-format enumeration, so gst-omx can't build a negotiation map. You can chase that a long way. Don't.

libOmxVdec.so is a wrapper over libvdecoder.so, and that lower library is what actually owns the decode surfaces. VideoPicture.nBufFd is a genuine dma_buf fd per frame, and the matching headers already ship in /usr/include on the stock image. Import it with drmPrimeFDToHandle, scan it out on a DRM plane, done — the broken layer isn't on the path at all.

Same board, same clip:

CPUthreads

omxh264dec ! videoconvert ! ximagesink174% (+16.5% X)10

zero-copy DRM~8%1

cedarzcdec ! kmssink (GStreamer element)12–13%4

No kernel patches, no custom modules, no SDK build. There's a GStreamer element so existing pipelines work unchanged:

gst-launch-1.0 filesrc location=clip.mp4 ! qtdemux ! h264parse ! cedarzcdec ! kmssink

Code, plus a writeup of the undocumented API traps that cost me the most time (GetVeOpsS takes an argument and has no prototype; use CdcMemOpen not CdcMemSetup; modetest -p hides the fence properties unless you set the atomic client cap):

https://github.com/skamagedon/a733-zero-copy

Tested on A733/sun60iw2, Bullseye, kernel 5.15.147, H.264 only. The same libcedarc family ships on A133/H616/H618/T527 and this likely transfers, but I haven't tested those — VideoPicture's layout is guarded by VE_SUPPORT_DECODER_LBC_MODE, so check your own vbasetype.h.