Add FFmpeg V4L2 Request + DRM PRIME display backend

[praxis88]

New backend (ffmpeg_drm) for embedded Linux devices with V4L2 stateless hardware decoders and KMS/DRM atomic display.

Architecture:

• FFmpeg hwaccel: AV_HWDEVICE_TYPE_DRM + AV_PIX_FMT_DRM_PRIME output
• Hardware decode via V4L2 Request API (rkvdec, hantro, cedrus etc.)
• Display thread with blocking atomic KMS commits (never stalls decode)
• av_frame_clone holds DRM PRIME buffer ref across vsync
• Blanks fbcon and other CRTC planes at startup via atomic commit

Tested on RK3399 (rkvdec): 1080p60 HEVC @ 20 Mbps, 2.7ms average decode time, 0% frame drops. Should work on any device where LE's patched FFmpeg supports V4L2 Request hwaccel.

Build: cmake -DENABLE_FFMPEG_DRM=ON (requires libdrm, libavcodec with DRM hwaccel)

Description

Purpose

[cgutman]

Is there a use case where Moonlight Qt is not sufficient? It has an even more fully featured DRM renderer capable of both legacy and atomic modes, statistics overlays, HDR, configurable v-sync, hardware or software decoding, etc.

Moonlight Embedded is really just for those old embedded devices that use bespoke decoding/rendering APIs rather than the standard V4L2 stateful/stateless decoder and DRM renderer. Even the Raspberry Pi, which was the original moonlight-embedded target platform, has moved on to standard APIs years ago and is well supported on Moonlight Qt nowadays (with the exception of extremely old hardware like the Pi 1).

[praxis88]

This was originally done when updating scripts.luna for libreelec/coreelec and there's no qt there, just some kodi interfacing around moonlight embedded. I ended up just ripping kodi out altogether and compiling qt6 in the elec build system and booting straight into moonlight-qt. But it did work, and it seemed like an expansion of capability so I submitted it. QT is a hefty one and access to the graphics pipeline with embedded seemed like a worthwhile path, but i eventually just bit the bullet and compiled it