firefox-fourier patch 3: regenerate canonical diff with corrected hunk arithmetic

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.

arch/firefox-fourier/patches/0003-ffmpegvideo-v4l2-request-route.patch

@@ -18,13 +18,14 @@ This patch adds a sibling init path, `InitV4L2RequestDecoder`, that:
   * looks up the codec via two complementary mechanisms libavcodec
     uses for v4l2_request:
       - **named codec** (`h264_v4l2request`, `vp8_v4l2request`, etc.):
-        the legacy AVCodec-per-hwaccel registration, used by ALARM /
-        Debian / most distros that build with --enable-v4l2-request;
+        the legacy AVCodec-per-hwaccel registration. ALARM, Debian,
+        and most distros building with --enable-v4l2-request expose
+        this (avcodec_find_decoder_by_name lookup).
       - **generic codec + AV_HWDEVICE_TYPE_DRM** in `hw_configs`:
-        the modern hwaccel registration, used by some upstream-only
+        the modern hwaccel registration on some upstream-only ffmpeg
         builds.
     Probes named-codec first (explicit, portable) and falls back to
-    walking the generic codec's hw_configs.
+    walking the generic codec's `hw_configs` for the DRM device type;
   * creates an `AV_HWDEVICE_TYPE_DRM` hwdevice context bound to
     `/dev/dri/renderD128` via the new `av_hwdevice_ctx_create` wrapper
     (patch 2/4) and attaches it to the codec context;
@@ -33,11 +34,11 @@ This patch adds a sibling init path, `InitV4L2RequestDecoder`, that:
     `apply_cropping = 0` constraint.
 
 `InitV4L2RequestDecoder` is invoked **before** `InitV4L2Decoder` in
-`InitHWDecoderIfAllowed`. On Rockchip mainline it succeeds. On Pi4 /
-Mediatek / vendor-MPP-stateful boards the codec's `hw_configs` lacks
-a DRM entry (the V4L2-M2M codecs don't register one), the sanity
-check fails, and the existing stateful `InitV4L2Decoder` runs as
-before. No regression of stateful boards.
+`InitHWDecoderIfAllowed`. On Rockchip mainline it succeeds via either
+mechanism (ALARM uses the named codec). On Pi4 / Mediatek /
+vendor-MPP-stateful boards neither mechanism is registered for the
+codec, the function bails out, and the existing stateful
+`InitV4L2Decoder` runs as before. No regression of stateful boards.
 
 `mDRMDeviceContext` is unconditionally `av_buffer_unref`'d in
 `ProcessShutdown` (no-op when null). Gated behind
@@ -73,9 +74,9 @@ diff --git a/dom/media/platforms/ffmpeg/FFmpegVideoDecoder.h b/dom/media/platfor
    // DMABuf and present it as a external texture to rendering pipeline.
    bool mUploadSWDecodeToDMABuf = false;
 diff --git a/dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp b/dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp
---- a/dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp	2026-03-18 19:22:14.000000000 +0000
-+++ b/dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp	2026-04-27 20:44:33.280766228 +0000
-@@ -406,6 +406,105 @@
+--- a/dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp	2026-04-27 16:09:10.000000000 +0200
++++ b/dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp	2026-04-29 00:10:00.098884335 +0200
+@@ -403,6 +403,129 @@
    return NS_OK;
  }
  
@@ -118,7 +119,7 @@ diff --git a/dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp b/dom/media/platf
 +  //       AV_HWDEVICE_TYPE_DRM in its hw_configs array, and setting
 +  //       hw_device_ctx on the codec context binds v4l2_request
 +  //       internally. Some upstream-only builds expose this.
-+  // Probe (a) first — it's the explicit, distro-portable lookup.
++  // Probe (a) first — it is the explicit, distro-portable lookup.
 +  // Fall back to (b) when the named entry isn't registered.
 +  const char* requestName = nullptr;
 +  switch (mCodecID) {
@@ -137,7 +138,6 @@ diff --git a/dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp b/dom/media/platf
 +  if (codec) {
 +    FFMPEG_LOG("  using named v4l2_request codec %s", requestName);
 +  } else {
-+    // Fallback path (b): generic codec + DRM hwaccel.
 +    AVCodec* generic = mLib->avcodec_find_decoder(mCodecID);
 +    if (generic) {
 +      for (int i = 0;; i++) {
@@ -153,7 +153,7 @@ diff --git a/dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp b/dom/media/platf
 +  }
 +
 +  if (!codec) {
-+    FFMPEG_LOG("  no v4l2_request path for codec ID %d — neither named "
++    FFMPEG_LOG("  no v4l2_request path for codec ID %d \u2014 neither named "
 +               "codec %s nor generic codec with DRM hwaccel available "
 +               "(libavcodec built without --enable-v4l2-request?)",
 +               mCodecID, requestName);
@@ -206,7 +206,7 @@ diff --git a/dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp b/dom/media/platf
  MediaResult FFmpegVideoDecoder<LIBAV_VER>::InitV4L2Decoder() {
    FFMPEG_LOG("Initialising V4L2-DRM FFmpeg decoder");
  
-@@ -659,6 +758,16 @@
+@@ -656,6 +779,16 @@
  #  endif  // MOZ_ENABLE_VAAPI
  
  #  ifdef MOZ_ENABLE_V4L2
@@ -223,7 +223,7 @@ diff --git a/dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp b/dom/media/platf
    // VAAPI didn't work or is disabled, so try V4L2 with DRM
    if (NS_SUCCEEDED(InitV4L2Decoder())) {
      return;
-@@ -2046,6 +2155,11 @@
+@@ -2046,6 +2179,11 @@
    if (IsHardwareAccelerated()) {
      mLib->av_buffer_unref(&mVAAPIDeviceContext);
    }