marfrit/marfrit-packages
0
0
Fork 1
Code Issues 2 Pull Requests Actions Packages Projects Releases Wiki Activity

ffmpeg-v4l2-request-fourier / libavcodec61-fourier: H.264 v4l2-request hwaccel not registered #60

New Issue
Closed
opened 2026-05-20 21:15:21 +00:00 by claude-noether · 2 comments
claude-noether commented 2026-05-20 21:15:21 +00:00
Contributor
Copy Link
Copy Source

Summary

With the new libavcodec61-fourier 8:7.1.3-0+deb13u1+rpt1+fourier1 installed on higgs (Pi CM5), Firefox-fourier's InitV4L2RequestDecoder still fails for H.264 with the same error as before the libavcodec replacement:

FFmpegVideo FFMPEG: Initialising V4L2 stateless (request API) FFmpeg decoder
FFmpegVideo FFMPEG:   no v4l2_request path for codec ID 27 — neither named codec
                      h264_v4l2request nor generic codec with DRM hwaccel available
                      (libavcodec built without --enable-v4l2-request?)

Root cause

The libavcodec61-fourier build was DONE with --enable-v4l2-request (verified via ffmpeg -buildconf), but only HEVC ended up with the DRM/v4l2-request hwaccel registered:

$ ffmpeg -hide_banner -h decoder=h264
Decoder h264 [H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10]:
    Supported hardware devices: cuda vaapi vdpau vulkan         ← no drm

$ ffmpeg -hide_banner -h decoder=hevc
Decoder hevc [HEVC (High Efficiency Video Coding)]:
    Supported hardware devices: cuda drm vaapi vdpau vulkan     ← drm present

strings | grep v4l2_request on the .so confirms:

  • system libavcodec.so.61.19.101: only hevc_v4l2request and v4l2_request_* helper functions; no h264_v4l2request symbols
  • /opt/fourier/lib/libavcodec.so.62.28.100: only v4l2_request_vp9_* + ff_v4l2_request_reset_picture; also no h264_v4l2request symbols

So both fourier libavcodec variants are missing the H.264 v4l2-request hwaccel module. Kwiboo's fork has it in source (see e.g. libavcodec/v4l2_request_h264.c upstream); something in the configure / patchset for this build is excluding it.

Effect

YouTube serves H.264 by default to Firefox. With the H.264 v4l2-request hwaccel missing, Firefox-fourier falls all the way back to software decode in the RDD process. Symptom: 25-30% CPU on the firefox parent for a single video tab, ~30 fps achieved against a 60 fps source on a Pi CM5 (single Cortex-A76 SW H.264 decode is roughly that fast at 720p) — user-visible as "every other frame dropped".

When YouTube serves HEVC (rare without explicit user override), Firefox-fourier should be able to engage v4l2-request via libavcodec → DRM hwaccel → kernel V4L2 stateless → daedalus or rpi-hevc-dec. HEVC path is testable as a sanity check but doesn't cover the common-case YouTube flow.

Probable fixes (to investigate)

  1. Check the ffmpeg-v4l2-request-fourier configure invocation for whether all per-codec v4l2-request hwaccels are being enabled. Possible the build script narrows --enable-hwaccel=... to a subset that omits h264_v4l2_request.

  2. Check the patch set for Kwiboo's tree — older patches may have been dropped during rebase. Specifically anything touching libavcodec/v4l2_request_h264.c or that codec's hwaccel registration list.

  3. Configure dep check: v4l2_request_h264_hwaccel_deps="v4l2_request h264 h264_v4l2_request_hwaccel_select" — if one of those deps got disabled by an unrelated --disable-X, it cascades to dropping h264_v4l2request silently. Build log should mention which hwaccels got disabled and why.

Related

  • marfrit-packages #59 — surfaced the libavcodec-path problem on Pi 5 Firefox, fixed by the libavcodec61-fourier package. This issue is the remaining gap inside that package.
  • daedalus-v4l2 PRs #1/#2/#3 + libva PRs #6/#7/#10 — kernel + daemon + libva stack are all routing H.264 correctly when reached (verified via ffmpeg CLI vaapi path on this same higgs install). The miss is purely Firefox-side: lookup against libavcodec finds no DRM hwaccel for h264.

Test plan

After rebuild with h264 v4l2-request enabled:

  • ffmpeg -h decoder=h264 | grep 'Supported hardware' shows drm in the list.
  • strings /usr/lib/aarch64-linux-gnu/libavcodec.so.61.19.101 | grep -i h264.*v4l2request returns at least one match.
  • On higgs with the rebuilt libavcodec61-fourier installed: launch firefox-fourier (with the user.js from issue #59 — FFVPX disabled, media.ffmpeg.v4l2-request.enabled=true) → open YouTube → daedalus daemon journal shows REQ_DECODE codec=3 (H.264) traffic at 30 fps.
  • Firefox parent process CPU drops from ~25% to near-idle on the video tab.
  • MOZ_LOG PlatformDecoderModule:5,FFmpegVideo:5 shows the Initialising V4L2 stateless (request API) FFmpeg decoder line followed by a successful init, no fall-through to V4L2-DRM or software.
## Summary With the new `libavcodec61-fourier` 8:7.1.3-0+deb13u1+rpt1+fourier1 installed on higgs (Pi CM5), Firefox-fourier's `InitV4L2RequestDecoder` still fails for H.264 with the same error as before the libavcodec replacement: ``` FFmpegVideo FFMPEG: Initialising V4L2 stateless (request API) FFmpeg decoder FFmpegVideo FFMPEG: no v4l2_request path for codec ID 27 — neither named codec h264_v4l2request nor generic codec with DRM hwaccel available (libavcodec built without --enable-v4l2-request?) ``` ## Root cause The libavcodec61-fourier build was DONE with `--enable-v4l2-request` (verified via `ffmpeg -buildconf`), but only HEVC ended up with the DRM/v4l2-request hwaccel registered: ``` $ ffmpeg -hide_banner -h decoder=h264 Decoder h264 [H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10]: Supported hardware devices: cuda vaapi vdpau vulkan ← no drm $ ffmpeg -hide_banner -h decoder=hevc Decoder hevc [HEVC (High Efficiency Video Coding)]: Supported hardware devices: cuda drm vaapi vdpau vulkan ← drm present ``` `strings | grep v4l2_request` on the .so confirms: - system libavcodec.so.61.19.101: only `hevc_v4l2request` and `v4l2_request_*` helper functions; **no** `h264_v4l2request` symbols - /opt/fourier/lib/libavcodec.so.62.28.100: only `v4l2_request_vp9_*` + `ff_v4l2_request_reset_picture`; also **no** `h264_v4l2request` symbols So both fourier libavcodec variants are missing the H.264 v4l2-request hwaccel module. Kwiboo's fork has it in source (see e.g. `libavcodec/v4l2_request_h264.c` upstream); something in the configure / patchset for this build is excluding it. ## Effect YouTube serves H.264 by default to Firefox. With the H.264 v4l2-request hwaccel missing, Firefox-fourier falls all the way back to software decode in the RDD process. Symptom: 25-30% CPU on the firefox parent for a single video tab, ~30 fps achieved against a 60 fps source on a Pi CM5 (single Cortex-A76 SW H.264 decode is roughly that fast at 720p) — user-visible as "every other frame dropped". When YouTube serves HEVC (rare without explicit user override), Firefox-fourier should be able to engage v4l2-request via libavcodec → DRM hwaccel → kernel V4L2 stateless → daedalus or rpi-hevc-dec. HEVC path is testable as a sanity check but doesn't cover the common-case YouTube flow. ## Probable fixes (to investigate) 1. **Check the ffmpeg-v4l2-request-fourier configure invocation** for whether all per-codec v4l2-request hwaccels are being enabled. Possible the build script narrows `--enable-hwaccel=...` to a subset that omits h264_v4l2_request. 2. **Check the patch set for Kwiboo's tree** — older patches may have been dropped during rebase. Specifically anything touching `libavcodec/v4l2_request_h264.c` or that codec's hwaccel registration list. 3. **Configure dep check**: `v4l2_request_h264_hwaccel_deps="v4l2_request h264 h264_v4l2_request_hwaccel_select"` — if one of those deps got disabled by an unrelated `--disable-X`, it cascades to dropping h264_v4l2request silently. Build log should mention which hwaccels got disabled and why. ## Related - marfrit-packages #59 — surfaced the libavcodec-path problem on Pi 5 Firefox, fixed by the libavcodec61-fourier package. This issue is the remaining gap inside that package. - daedalus-v4l2 PRs #1/#2/#3 + libva PRs #6/#7/#10 — kernel + daemon + libva stack are all routing H.264 correctly when reached (verified via ffmpeg CLI vaapi path on this same higgs install). The miss is purely Firefox-side: lookup against libavcodec finds no DRM hwaccel for h264. ## Test plan After rebuild with h264 v4l2-request enabled: - `ffmpeg -h decoder=h264 | grep 'Supported hardware'` shows `drm` in the list. - `strings /usr/lib/aarch64-linux-gnu/libavcodec.so.61.19.101 | grep -i h264.*v4l2request` returns at least one match. - On higgs with the rebuilt libavcodec61-fourier installed: launch firefox-fourier (with the user.js from issue #59 — FFVPX disabled, media.ffmpeg.v4l2-request.enabled=true) → open YouTube → daedalus daemon journal shows REQ_DECODE codec=3 (H.264) traffic at 30 fps. - Firefox parent process CPU drops from ~25% to near-idle on the video tab. - MOZ_LOG `PlatformDecoderModule:5,FFmpegVideo:5` shows the `Initialising V4L2 stateless (request API) FFmpeg decoder` line followed by a *successful* init, no fall-through to V4L2-DRM or software.
claude-noether commented 2026-05-20 21:18:51 +00:00
Author
Contributor
Copy Link
Copy Source

Full per-codec audit — only HEVC has DRM hwaccel reachable

Didn't initially enumerate beyond H.264 — fixing that here so the rebuild covers everything in one pass.

Current state (libavcodec61-fourier 8:7.1.3-0+deb13u1+rpt1+fourier1)

$ for c in h264 hevc vp9 vp8 av1 mpeg2video; do
    ffmpeg -hide_banner -h decoder=$c 2>&1 | grep 'Supported hardware devices:'
  done

  h264         cuda vaapi vdpau vulkan         ← NO drm
  hevc         cuda drm vaapi vdpau vulkan     ← drm present (only one!)
  vp9          cuda vaapi vdpau                ← NO drm
  vp8          vaapi cuda                      ← NO drm
  av1          cuda vaapi vdpau vulkan         ← NO drm
  mpeg2video   cuda vaapi vdpau                ← NO drm

Symbol-level confirmation

strings /usr/lib/aarch64-linux-gnu/libavcodec.so.61.19.101 | grep v4l2_request:

  • Per-codec implementations COMPILED IN: v4l2_request_hevc_*, v4l2_request_vp9_*, v4l2_request_vp8_*, v4l2_request_mpeg2_*
  • NOT compiled: any v4l2_request_h264_*, any v4l2_request_av1_*

So for vp9/vp8/mpeg2 the v4l2_request_* source files DID compile (functions are in the .so), but the per-codec AVHWAccel struct isn't being added to the codec's hw_configs list at link time. That's the CONFIG_VP9_V4L2REQUEST_HWACCEL etc. gating in libavcodec/h264dec.c / vp9dec.c etc.

Probable cause: the configure script's per-codec hwaccel dep checks are failing silently (v4l2_request_h264_hwaccel_deps extra h264_v4l2_request_hwaccel_select). Build log should show e.g. Disabled hwaccels: ... h264_v4l2request vp9_v4l2request ....

Complete set to enable in the rebuild

To cover every codec we care about across all consumer paths (Firefox + mpv + ffmpeg CLI on Pi 5 / CM5 / Rockchip):

codec v4l2_request_*_hwaccel vaapi_*_hwaccel needed for
h264 MISSING — add present YouTube default; the big win
hevc present present YouTube HEVC tier, .mkv files
vp9 MISSING — add present YouTube backup, Twitch
vp8 MISSING — add present older WebRTC, legacy WebM
av1 MISSING — add present future-proof, Netflix, YouTube AV1 tier
mpeg2 MISSING — add present DVD content, broadcast streams

The vaapi side is fine because libva-v4l2-request-fourier translates VAAPI → V4L2 stateless and the kernel-side stack works for all of these (verified: vp9 via daedalus, hevc via rpi-hevc-dec, h264 via daedalus from ffmpeg CLI). The gap is purely the v4l2-request hwaccel registration in libavcodec which the firefox-fourier patches use directly.

Configure verification step (post-rebuild)

The rebuild's configure output should include all five hwaccels we currently miss:

ffmpeg configure ...
  Hardware accelerators: ... h264_v4l2request hevc_v4l2request mpeg2_v4l2request vp8_v4l2request vp9_v4l2request av1_v4l2request ...
  (NOT in 'Disabled hwaccels:')

And post-install verification on a target host:

for c in h264 hevc vp9 vp8 av1 mpeg2video; do
  ffmpeg -h decoder=$c 2>&1 | grep -E 'drm' || echo "$c MISSING drm"
done

Should print 'drm' (as part of the Supported hardware devices line) for every codec.

Suspect Kwiboo configure dep

Kwiboo's tree historically requires h264_v4l2_request_hwaccel_select="h264_decoder" in the configure for the h264 v4l2-request hwaccel to be picked up. Check whether that _select is set in this build's configure invocation (or in the patch applied on top of upstream). Same dep pattern likely applies to vp9 / vp8 / av1 / mpeg2.

If the configure script is failing the dep silently (no error, just disabled output), --enable-hwaccel=h264_v4l2request,hevc_v4l2request,vp9_v4l2request,vp8_v4l2request,av1_v4l2request,mpeg2_v4l2request explicit-list might force-enable them and surface the actual failure if there is one.

## Full per-codec audit — only HEVC has DRM hwaccel reachable Didn't initially enumerate beyond H.264 — fixing that here so the rebuild covers everything in one pass. ### Current state (`libavcodec61-fourier 8:7.1.3-0+deb13u1+rpt1+fourier1`) ``` $ for c in h264 hevc vp9 vp8 av1 mpeg2video; do ffmpeg -hide_banner -h decoder=$c 2>&1 | grep 'Supported hardware devices:' done h264 cuda vaapi vdpau vulkan ← NO drm hevc cuda drm vaapi vdpau vulkan ← drm present (only one!) vp9 cuda vaapi vdpau ← NO drm vp8 vaapi cuda ← NO drm av1 cuda vaapi vdpau vulkan ← NO drm mpeg2video cuda vaapi vdpau ← NO drm ``` ### Symbol-level confirmation `strings /usr/lib/aarch64-linux-gnu/libavcodec.so.61.19.101 | grep v4l2_request`: - **Per-codec implementations COMPILED IN**: `v4l2_request_hevc_*`, `v4l2_request_vp9_*`, `v4l2_request_vp8_*`, `v4l2_request_mpeg2_*` - **NOT compiled**: any `v4l2_request_h264_*`, any `v4l2_request_av1_*` So for vp9/vp8/mpeg2 the `v4l2_request_*` source files DID compile (functions are in the .so), but the per-codec AVHWAccel struct isn't being added to the codec's `hw_configs` list at link time. That's the `CONFIG_VP9_V4L2REQUEST_HWACCEL` etc. gating in `libavcodec/h264dec.c` / `vp9dec.c` etc. Probable cause: the configure script's per-codec hwaccel dep checks are failing silently (`v4l2_request_h264_hwaccel_deps` extra `h264_v4l2_request_hwaccel_select`). Build log should show e.g. `Disabled hwaccels: ... h264_v4l2request vp9_v4l2request ...`. ### Complete set to enable in the rebuild To cover every codec we care about across all consumer paths (Firefox + mpv + ffmpeg CLI on Pi 5 / CM5 / Rockchip): | codec | v4l2_request_*_hwaccel | vaapi_*_hwaccel | needed for | |---|---|---|---| | **h264** | **MISSING** — add | present | YouTube default; the big win | | hevc | present | present | YouTube HEVC tier, .mkv files | | **vp9** | **MISSING** — add | present | YouTube backup, Twitch | | **vp8** | **MISSING** — add | present | older WebRTC, legacy WebM | | **av1** | **MISSING** — add | present | future-proof, Netflix, YouTube AV1 tier | | **mpeg2** | **MISSING** — add | present | DVD content, broadcast streams | The vaapi side is fine because libva-v4l2-request-fourier translates VAAPI → V4L2 stateless and the kernel-side stack works for all of these (verified: vp9 via daedalus, hevc via rpi-hevc-dec, h264 via daedalus from ffmpeg CLI). The gap is purely the v4l2-request hwaccel registration in libavcodec which the firefox-fourier patches use directly. ### Configure verification step (post-rebuild) The rebuild's configure output should include all five hwaccels we currently miss: ``` ffmpeg configure ... Hardware accelerators: ... h264_v4l2request hevc_v4l2request mpeg2_v4l2request vp8_v4l2request vp9_v4l2request av1_v4l2request ... (NOT in 'Disabled hwaccels:') ``` And post-install verification on a target host: ``` for c in h264 hevc vp9 vp8 av1 mpeg2video; do ffmpeg -h decoder=$c 2>&1 | grep -E 'drm' || echo "$c MISSING drm" done ``` Should print 'drm' (as part of the Supported hardware devices line) for every codec. ### Suspect Kwiboo configure dep Kwiboo's tree historically requires `h264_v4l2_request_hwaccel_select="h264_decoder"` in the configure for the h264 v4l2-request hwaccel to be picked up. Check whether that `_select` is set in this build's configure invocation (or in the patch applied on top of upstream). Same dep pattern likely applies to vp9 / vp8 / av1 / mpeg2. If the configure script is failing the dep silently (no error, just disabled output), `--enable-hwaccel=h264_v4l2request,hevc_v4l2request,vp9_v4l2request,vp8_v4l2request,av1_v4l2request,mpeg2_v4l2request` explicit-list might force-enable them and surface the actual failure if there is one.
claude-noether commented 2026-05-20 22:02:59 +00:00
Author
Contributor
Copy Link
Copy Source

fourier2 build: hwaccels are now registered for all codecs — but as AV_HWDEVICE_TYPE_V4L2REQUEST, not AV_HWDEVICE_TYPE_DRM — Firefox patch still misses

The +rpt1+fourier2 rebuild added v4l2request to every codec's hwaccel list ✓ — that part of the issue is fixed. But the hwaccel registers with the newer AV_HWDEVICE_TYPE_V4L2REQUEST enum (introduced in FFmpeg ~7.1 as a dedicated type), where the fourier1 build used AV_HWDEVICE_TYPE_DRM.

# fourier1 build (HEVC only)
hevc:  cuda drm vaapi vdpau vulkan          ← drm
# fourier2 build (now all six)
h264:  cuda vaapi vdpau vulkan v4l2request   ← NEW dedicated type
hevc:  cuda vaapi vdpau vulkan v4l2request   ← was 'drm' before
vp9:   cuda vaapi vdpau v4l2request
vp8:   vaapi cuda v4l2request
av1:   cuda vaapi vdpau vulkan v4l2request
mpeg2: cuda vaapi vdpau v4l2request

The firefox-fourier patch 0003-ffmpegvideo-v4l2-request-route.patch walks hw_configs looking for device_type == AV_HWDEVICE_TYPE_DRM. With fourier2's hwaccels declaring device_type = AV_HWDEVICE_TYPE_V4L2REQUEST instead, the patch's walk finds no match and falls through to software — same no v4l2_request path for codec ID 27 log line as before, different underlying cause.

Verified on higgs with fourier2 installed: daedalus daemon journal still shows 0 REQ_DECODE for YouTube playback. Firefox stderr/MOZ_LOG repeats the same fall-through chain through Initialising VA-API FFmpeg decoder → Initialising V4L2 stateless (request API) FFmpeg decoder → no v4l2_request path → Initialising V4L2-DRM FFmpeg decoder → Using preferred software codec h264.

Two fix paths

A. Firefox patch update (preferred)

0003-ffmpegvideo-v4l2-request-route.patch and 0002-libwrapper-hwdevice-ctx-create.patch need to accept BOTH AV_HWDEVICE_TYPE_DRM AND AV_HWDEVICE_TYPE_V4L2REQUEST when walking hw_configs, and create the hwdevice ctx with the matching type. Concrete change in patch 3 (the hw_configs walk):

// Was:
if (cfg->device_type == AV_HWDEVICE_TYPE_DRM &&
    cfg->methods & AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX) { ... }

// Need:
if ((cfg->device_type == AV_HWDEVICE_TYPE_DRM ||
     cfg->device_type == AV_HWDEVICE_TYPE_V4L2REQUEST) &&
    cfg->methods & AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX) {
    target_type = cfg->device_type;
    ...
}

Then patch 2's av_hwdevice_ctx_create call uses target_type (DRM or V4L2REQUEST) instead of hardcoded AV_HWDEVICE_TYPE_DRM.

Accepting both types future-proofs against the FFmpeg-side transition AND keeps the patches working against older libavcodec builds that still use DRM (Pi 5 / RK hosts on previous fourier versions).

B. Re-pin ffmpeg-fourier to a version that uses DRM

Rollback to whatever fourier1 was based on for the hwaccel device_type declaration. Smaller patch on the ffmpeg side, but locks the campaign to an older base.

Recommendation

Ship A. V4L2REQUEST is the canonical new type in upstream FFmpeg and this transition will happen again as future FFmpeg versions reach Debian / rpt. Single Firefox-side patch update covers both.

Happy to draft the Firefox patch update if helpful.

## fourier2 build: hwaccels are now registered for all codecs — but as `AV_HWDEVICE_TYPE_V4L2REQUEST`, not `AV_HWDEVICE_TYPE_DRM` — Firefox patch still misses The `+rpt1+fourier2` rebuild added `v4l2request` to every codec's hwaccel list ✓ — that part of the issue is fixed. But the hwaccel registers with the **newer `AV_HWDEVICE_TYPE_V4L2REQUEST` enum** (introduced in FFmpeg ~7.1 as a dedicated type), where the fourier1 build used `AV_HWDEVICE_TYPE_DRM`. ``` # fourier1 build (HEVC only) hevc: cuda drm vaapi vdpau vulkan ← drm # fourier2 build (now all six) h264: cuda vaapi vdpau vulkan v4l2request ← NEW dedicated type hevc: cuda vaapi vdpau vulkan v4l2request ← was 'drm' before vp9: cuda vaapi vdpau v4l2request vp8: vaapi cuda v4l2request av1: cuda vaapi vdpau vulkan v4l2request mpeg2: cuda vaapi vdpau v4l2request ``` The firefox-fourier patch `0003-ffmpegvideo-v4l2-request-route.patch` walks `hw_configs` looking for `device_type == AV_HWDEVICE_TYPE_DRM`. With fourier2's hwaccels declaring `device_type = AV_HWDEVICE_TYPE_V4L2REQUEST` instead, the patch's walk finds no match and falls through to software — same `no v4l2_request path for codec ID 27` log line as before, different underlying cause. Verified on higgs with fourier2 installed: daedalus daemon journal still shows 0 REQ_DECODE for YouTube playback. Firefox stderr/MOZ_LOG repeats the same fall-through chain through `Initialising VA-API FFmpeg decoder` → `Initialising V4L2 stateless (request API) FFmpeg decoder` → `no v4l2_request path` → `Initialising V4L2-DRM FFmpeg decoder` → `Using preferred software codec h264`. ## Two fix paths ### A. Firefox patch update (preferred) `0003-ffmpegvideo-v4l2-request-route.patch` and `0002-libwrapper-hwdevice-ctx-create.patch` need to accept BOTH `AV_HWDEVICE_TYPE_DRM` AND `AV_HWDEVICE_TYPE_V4L2REQUEST` when walking `hw_configs`, and create the hwdevice ctx with the matching type. Concrete change in patch 3 (the `hw_configs` walk): ```c // Was: if (cfg->device_type == AV_HWDEVICE_TYPE_DRM && cfg->methods & AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX) { ... } // Need: if ((cfg->device_type == AV_HWDEVICE_TYPE_DRM || cfg->device_type == AV_HWDEVICE_TYPE_V4L2REQUEST) && cfg->methods & AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX) { target_type = cfg->device_type; ... } ``` Then patch 2's `av_hwdevice_ctx_create` call uses `target_type` (DRM or V4L2REQUEST) instead of hardcoded `AV_HWDEVICE_TYPE_DRM`. Accepting both types future-proofs against the FFmpeg-side transition AND keeps the patches working against older libavcodec builds that still use DRM (Pi 5 / RK hosts on previous fourier versions). ### B. Re-pin ffmpeg-fourier to a version that uses DRM Rollback to whatever fourier1 was based on for the hwaccel `device_type` declaration. Smaller patch on the ffmpeg side, but locks the campaign to an older base. ## Recommendation Ship A. V4L2REQUEST is the canonical new type in upstream FFmpeg and this transition will happen again as future FFmpeg versions reach Debian / rpt. Single Firefox-side patch update covers both. Happy to draft the Firefox patch update if helpful.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
marfrit (Markus Fritsche)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: marfrit/marfrit-packages#60
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?