Earlier todays edit on patch 3 (commit e0af915) replaced the
hw_configs-only sanity check with the dual-mechanism (named codec
first, hw_configs fallback) probe. The patch text body was correct
but the unified-diff hunk header at the .cpp portion still claimed
the original +105-line content while the new content was 130 lines —
so patch -p1 failed with malformed-patch errors.
This commit regenerates the .cpp portion canonically via diff -u
from the boltzmann working tree (which has the corrected logic
applied). The .h portion is unchanged. Patch description body
updated to match the new dual-mechanism behavior.
Empirical evidence the new logic is correct lives in the boltzmann
build; this commit just makes the patch file replay correctly from
scratch.
Diagnostic on fresnel (RK3399 / Mali-T860 / mainline) showed
InitV4L2RequestDecoder running at runtime but failing the
hw_configs sanity check:
FFMPEG: Initialising V4L2 stateless (request API) FFmpeg decoder
FFMPEG: codec h264 has no DRM hwaccel —
libavcodec built without --enable-v4l2-request?
FFMPEG: Initialising V4L2-DRM FFmpeg decoder ← falls through to stateful
FFMPEG: V4L2 codec h264_v4l2m2m : V4L2 mem2mem H.264 decoder wrapper
FFMPEG: Couldn't initialise V4L2 decoder ← stateful also fails
…despite the system libavcodec.so being built with
--enable-v4l2-request and exposing h264_v4l2request, vp8_v4l2request,
etc. as named AVCodec entries.
Root cause: libavcodec exposes v4l2_request through one of two
mechanisms depending on the build:
(a) Named AVCodec entry (legacy, distro-portable): looked up via
avcodec_find_decoder_by_name("h264_v4l2request"). ALARM,
Debian, most distros use this.
(b) hw_configs entry on the generic codec (modern, upstream): the
generic codec's AVCodecHWConfig array advertises
AV_HWDEVICE_TYPE_DRM. Setting hw_device_ctx binds the hwaccel.
Patch 3 originally only probed (b). On builds that ship (a) — the
common case — the check failed even though v4l2_request was fully
functional.
Fix: probe (a) first via the codec-name lookup table, fall back to
(b) walking hw_configs. Both shapes work; the decoder is opened with
whichever AVCodec the probe selected. The DRM hwdevice ctx
attachment is unchanged (both mechanisms need it for surface
allocation).
Patch description and the in-code comment block updated to document
the dual mechanism. Behaviour on stateful-only boards (Pi4 / vendor
MPP) preserved: neither named codec nor hw_configs DRM is registered,
the function bails out, the existing InitV4L2Decoder runs as before.
marfrit