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

iter6 close: drop MPEG-2 from carry list

Browse Source 
iter1 lock's "H.264 first; MPEG-2 next" backlog item is dropped.
MPEG-2 SD/HD decodes trivially in CPU on RK3568's A55 cluster
(well under one core), so the campaign's user audience doesn't
need MPEG-2 HW path. If upstream review surfaces the question,
the answer is "H.264-only by design — CPU handles MPEG-2 fine
on this hardware."

phase0_findings_iter6.md left as historical record of what was
in-scope at that substrate time; the close doc is now the
operative carry-list source.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Claude (noether)
2026-05-06 03:56:30 +00:00
parent 4cd0167d08
commit 7c54d164d9
1 changed files with 3 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
phase8_iteration6_close.md
+3 -3
View File
@@ -51,8 +51,7 @@ Closes GREEN with a single architectural fix.
1. **WiFi-IRQ-induced frame drops** — observed during YouTube playback on ohm; brcm/iwlwifi driver IRQ work spikes CPU usage and the compositor drops late frames. Decode pipeline is unaffected (driver produces frames on time; presentation schedule slips). Out of campaign scope but worth a separate investigation (IRQ affinity, GRO offload, driver buffer tuning).
2. **Slot-leak on RequestSyncSurface error path** — when `media_request_reinit` or `DQBUF` fails mid-cycle, the slot stays `busy=true` and isn't returned to acquire-rotation until `RequestTerminate` runs `request_pool_destroy`. With pool=16 and rare errors this is bounded; acquire returns `-1` cleanly when exhausted. TODO: `request_pool_force_release` for error recovery.
3. **No pixel-correctness verification post-iter5-msync-removal** — iter5 sonnet C3 carry. Probably safe (kernel does DMA sync at DQBUF level on this CMA-backed config) but a frame-hash spot check would anchor formally.
4. **MPEG-2 path never exercised** — iter1 lock said "H.264 first; MPEG-2 next." Six iterations later, still H.264-only.
5. **YouTube codec negotiation** — without `Enhancer for YouTube` or `enhanced-h264ify` browser extension forcing avc1, FF150 negotiates AV1 from YT and SW-decodes. v4l2_request handles only H.264 currently. Worth one line in `firefox-fourier/README.md`.
4. **YouTube codec negotiation** — without `Enhancer for YouTube` or `enhanced-h264ify` browser extension forcing avc1, FF150 negotiates AV1 from YT and SW-decodes. v4l2_request handles only H.264 currently. Worth one line in `firefox-fourier/README.md`.
## Lessons distilled to memory
@@ -76,10 +75,11 @@ iter6 makes the fork structurally cleaner for upstream submission:
Outstanding for upstream-readiness:
- msync pixel-verification (carry from iter5 sonnet C3)
- MPEG-2 path validation (iter1 backlog)
- Slot-leak error recovery (iter6 carry)
- Probe-pattern test harness for cap_pool race (iter5 sonnet C4 / iter6 candidate A — NOW EXERCISED organically by YT's resolution renegotiations, but a synthetic harness would anchor the claim)
iter1 lock's "H.264 first; MPEG-2 next" backlog item is dropped 2026-05-06: MPEG-2 SD/HD decodes trivially in CPU on RK3568's A55 cluster (well under one core), so the campaign's user audience doesn't need MPEG-2 HW path. If an upstream reviewer asks, the answer is "H.264-only by design — CPU handles MPEG-2 fine on this hardware."
Per `feedback_no_upstream.md`, no PR/MR happens without explicit operator instruction.
## Phase 1 success criterion — final