Firefox got back to me and that funny question came up again.... "Is that a recent regression? Did it work before?"
Claude went through a few Firefox releases and no it did not. So I'm back to a day job but should have the 4 changes they want in my patch over the weekend.

https://bugzilla.mozilla.org/show_bug.cgi?id=2078820
The multi stage 4 or 5 Agent review is working well, they seem to find either issues or a better way of getting it done.

My new driver is near completion. all codecs, Chrome & Firefox browsers, all hardware accelerated.

Added Mainline's new Patch to my OS
[PATCH v5 00/15] Support 10-bit YUV422 and 8/10-bit YUV420 color format on DW HDMI QP

peace,

defcom5-rockchip

@Igor I'm not sure I have time (New Job) but the Claude's Agents are saying there is an issue with the Mainline Patch... Perhaps you could have a look.
 

"Patch 8 itself is fine. For YUV422, the 8-bit rate check matches the real link rate, so it stops the needless clock switch and fixes modes like 3840x2160 at 59.94 Hz. What's worth your consideration is the rest of the thread.

sashiko-bot's replies, posted on dri-devel only:

Patches 12 and 13: the encoder configures the PHY during the atomic check, so a "test only" commit can leave the PHY in a state the real commit then skips over. That's a fair point, and it predates this series.

Patch 7, marked "High": it says the new reset handles fail with -EBUSY when the driver rebinds. That's wrong. The kernel's component framework releases everything claimed during bind when the component unbinds, so a rebind starts clean.

Patch 7, two "Medium" points: an AXI reset at bind may do nothing if the clocks are off then, and an older ordering issue at teardown. Plausible, but I haven't checked them.

What nobody has raised: our finding. The display controller dithers its output down to 8 bits for every YUV mode, so the series' new 10-bit YUV422 and YUV420 modes would carry only 8 bits of real detail. The manual names that register bit "10bit->8bit", and Rockchip's own driver turns it off for 10-bit output.

My view: a short reply would genuinely help the author.

The dither issue: the main point. It goes on patch 13 or 14, with the manual and vendor-driver references, and says plainly that it's from code reading and not tested on hardware.

The false positive: optionally, one line on patch 7 pointing to the component-framework code, so the author doesn't spend time on it.

It would go out under your kernel identity, with the AI disclosure and our review step first. It's a mailing-list reply, so it needs plain text, quotes placed inline, and reply-to-all. I can draft it if you want to send it."

What do you do with these?
Public pages on Gitee, GitCode, CSDN, and Firefly load fine, but their search APIs require login, and Rockchip's own open-source site didn't respond at all—so I can browse but not search these directly. I'll now launch two research agents: one covering Jellyfin and GitHub projects, the other focused on the Chinese sites.
Thanks,

 

defcom5-rockchip

Edited October 16Oct 16 by defcom5-rockchip
question

Where we are :   

Yes, that one is a buffer issue, in timing rather than size.
 

Chromium hands the driver an empty buffer and asks for a frame to be decoded into it. A new buffer starts out all zeros, and zeros in the video format Chromium uses show as green.

Chromium never asks "is it ready?" It assumes the frame is done the moment the decode call returns. Its own source code says so.

Our AV1 path holds the newest frame back until the next one arrives, because the video interface never passes a piece of information the decoder needs. So the first frames of a video, and the first frames after YouTube steps up to 4K, can be shown before they're decoded. Later in playback a buffer being reused shows the previous frame instead of green, which is the flicker.
 

Firefox is fine because it waits for each frame before using it.

Not a memory or size problem: buffers are plentiful, and the memory checks for 3.5.0 are confirming that. The fix is in our driver, parked for the next version: finish those first frames before handing them back to Chromium.

We did it, Found the code that Rockchip disabled for multi core decode and fixed it proper for VP9 8 and 10 bit. I'm running soak test and then PR for MPP. 28% faster with no shit storms.

some initial numbers.

127 dropped of 40k
 

Claude>

127 of 40,000 is 0.3%, which is excellent for 4K60 in a browser.

The decoder log agrees: 10.5 minutes in, 40,701 jobs split evenly across both cores (20,351 and 20,350), 0 resets, and no AV1 mixed in. That's about 62% of the way to the old wall, which comes at about 15:07 on the board's clock, roughly 6–7 minutes from now. The timer runs on to about 15:15.


I'm too low on tokens for Firefox 4 Agent Review till tomorrow... But looking good for next release or two.
As well i'm not releasing the VA-API driver and MPP LIbrary Fork till after the 4 agent review and JFL Test.

Rockchip be looking good my friends

Edited October 17Oct 17 by defcom5-rockchip

For your consideration:

<Claude> On Jellyfin's code: they don't deal with the issue at all. That's why they hit it.
jellyfin-ffmpeg builds its own private copy of MPP, pinned in builder/scripts.d/50-rkmpp.sh:

SCRIPT_REPO="https://github.com/nyanmisaka/rk-mirrors.git" SCRIPT_COMMIT="a9380ef333102ac318628f83b5f7a460d377749e" SCRIPT_BRANCH="jellyfin-mpp-next"

That branch carries commit 960b7198a392 (nyanmisaka, 2025-12-24), which undoes Rockchip's guard:

Revert "fix[hal_vp9d]: not support fast mode for rk3588" This reverts commit 0d6cc57d44e79f8521ac2fc117571edb3224564b. --- a/mpp/hal/rkdec/vp9d/hal_vp9d_api.c +++ b/mpp/hal/rkdec/vp9d/hal_vp9d_api.c @@ -72,7 +72,7 @@ MPP_RET hal_vp9d_init(void *ctx, MppHalCfg *cfg) p->api = &hal_vp9d_vdpu34x; cfg->support_fast_mode = 1; if (mpp_get_soc_type() == ROCKCHIP_SOC_RK3588) - cfg->support_fast_mode = 0; + cfg->cfg->status.hal_task_count = 2;

How that compares with ours:

That's the same line as the second half of our fix: dual-core VP9 with 2 tasks.

They switched it on without the counter wrap, the first half of our fix. So their transcodes still fail after about 65,536 frames, which is the 30% frame loss we measured on the real film.

Rockchip had the opposite half-answer: switch dual-core off and lose the speed.

Our patch does both, so you get the speed without the storm.

 

update to Firefox...
Submitted 2nd patch with 4 changes.
New email added a person...
 

Claude > I've logged it; there's nothing to do.

"pasik" is almost certainly Pasi Kärkkäinen, going by the address pasik@iki.fi. He's a long-time Linux and Xen community member who follows Linux hardware-video bugs in Firefox. I don't know of him being a Mozilla maintainer, so I'd read this as an interested watcher rather than a reviewer. He CC'd himself on the 15th, the same day as Robert Mader, which was the day the triager said the approach was right — so the bug got noticed then.

Current state of the bug: Stránský still holds the needinfo ("will look at it"), with Mader and Pasi watching. I'll suggest a nudge only if it's still quiet in about a week.

Edited October 21Oct 21 by defcom5-rockchip

I dropped a 4k 60fps VP9 on Firefox last night and ran into glitches over the NAS... Claude said Firefox handles Network differently than MPV... They are Fashioning it to work... updates to come.

More Testing On The new Patch.... Firefox was glitching but now the numbers have changed.

Confirmed the AV1 decode is now working off a healthy ~35MB read-ahead burst instead of the previous bare 9 Mbit/s trickle, giving it the buffer cushion it was missing. I'm setting a watcher for the glitch pattern (decoder stalls/resumes) and will report back with a summary in about 10 minutes.