@JFL   Can you tell me your OS build out. 

Edited September 11Sep 11 by defcom5-rockchip

Hi @JFL — I found it, and your clean run was the clue that cracked it. You were right all along that your
box was fine. So is mine. **The variable was the video format, not the hardware.**

**It only happens on 10-bit VP9.**

 

I rebuilt the bench from scratch tonight and ran the same test three times, changing only one thing each
time — same board, same kernel, same driver, same MPP, same player:

| Content | Frames decoded | Exports | Result |
|---|---|---|---|
| VP9 **Profile 0** (8-bit), cached-export client | 73,330 | 294 | clean |
| VP9 **Profile 0** (8-bit), per-frame-export client | 73,381 | 168,384 | clean |
| VP9 **Profile 2** (10-bit) | **64,338** | 17,028 | **608 resets, picture breaks up** |

The 8-bit runs sailed past 73,000 frames with nothing. The 10-bit run died just short of **65,536** frames
in a single decode session — 608 resets in 25 seconds, about 24 per second, first `err 0x107` and then a
steady stream of `err 0x23`.

Note the export counts, because they kill the theory I posted earlier: the clean 8-bit run made **168,384**
exports, and the run that stormed made only **17,028**. It is not about buffer export churn at all. It
tracks **decoded frames in one session**, and only on the 10-bit path.

**Why you never saw it, after 45 minutes and 164,553 frames.** Your stats panel said `4K/60 vp09`. On that
video, that is itag 315 — `vp09.00.51.08`, Profile 0, **8 bit**. The HDR rung of the same title is a
separate stream, `vp9.2` (itag 337). You were watching the format that is immune. Your 164,553 clean frames
are exactly what my 8-bit runs produce, and they always would have been.

So there is nothing to chase on your side, and nothing special about `6.1.172` — I had started porting
kernels to explain a difference between our boards that does not exist. Your result was correct data; I was
interpreting it against the wrong variable.

 

**If you want to reproduce it** (only if you are curious — you have already done more than enough):

    yt-dlp -f 337 "https://www.youtube.com/watch?v=T4fUtvuN_G8" -o oled-hdr.webm   # the 10-bit rung
    sudo dmesg -C
    mpv --fs --hwdec=vaapi --loop-file=inf oled-hdr.webm     # ~18 min at 60fps
    dmesg | grep -c "rkvdec-core.*resetting"

At 60 fps you reach 65,536 frames in about eighteen minutes, and on my board the picture visibly breaks up
at that point.

The practical shape of the bug, as it stands tonight:

- **8-bit playback is unaffected**, at any length.
- **10-bit playback breaks after ~65,536 frames in one continuous decode session** — about 18 minutes at
  60 fps, or 45 minutes at 24 fps. So a long HDR film hits it; ordinary browsing does not, because every
  new video starts a fresh session.
- Anything that restarts the decoder resets the clock.

I am updating the upstream issue with this. Thank you for the 45-minute run — a clean result that
contradicts the theory is worth more than a dozen that agree with it, and this one sent me looking in the
right place.

Working with FumasterLin 

Edited September 11Sep 11 by defcom5-rockchip

16 minutes ago, defcom5-rockchip said:

Hi @JFL — I found it, and your clean run was the clue that cracked it. You were right all along that your
box was fine. So is mine. **The variable was the video format, not the hardware.**

**It only happens on 10-bit VP9.**

Hi @defcom5-rockchip

 

Ran the same 4K/60 video on google-chrome-hw twice again and these two round ended with lots of frames. This third try it ran for 56 minutes, very high dropped frames: 107159 dropped of 205010.  But unfortunately 

jfl@orangepi5-plus:~$ dmesg | grep -c "rkvdec-core.*resetting" 
0
jfl@orangepi5-plus:~$ 

If I do sudo dmesg -C it will clear the "dmesg log" and ran the google-chrome-hw, dmesg will return nothing blank, no idea why.  Tried a few rounds. 

 

Reboot retry and this round did not clear dmesg log.

 

Ran chromium for 56 minutes and dmesg at the end of the file show these:

 

[  109.072222] p2p0: RX AssocResp from 06:ba:d6:c6:11:5e (capab=0x1131 status=0 aid=14)
[  109.179533] p2p0: associated
[  109.179614] p2p0: Limiting TX power to 30 (30 - 0) dBm as advertised by 06:ba:d6:c6:11:5e
[  109.346174] IPv6: ADDRCONF(NETDEV_CHANGE): p2p0: link becomes ready
[  565.274956] dw-dp fde50000.dp: AUX timeout, resetting (cmd=0x9 addr=0x0)
[  565.301633] dw-dp fde50000.dp: AUX timeout, resetting (cmd=0x9 addr=0x0)
[  565.328327] dw-dp fde50000.dp: AUX timeout, resetting (cmd=0x9 addr=0x0)
[  565.354920] dw-dp fde50000.dp: AUX timeout, resetting (cmd=0x9 addr=0x0)
[  565.381477] dw-dp fde50000.dp: AUX timeout, resetting (cmd=0x9 addr=0x0)
[  565.408253] dw-dp fde50000.dp: AUX timeout, resetting (cmd=0x9 addr=0x0)

[  565.434860] dw-dp fde50000.dp: AUX timeout, resetting (cmd=0x9 addr=0x0)
[  565.461543] dw-dp fde50000.dp: AUX timeout, resetting (cmd=0x9 addr=0x0)
[  565.488137] dw-dp fde50000.dp: AUX timeout, resetting (cmd=0x9 addr=0x0)
[  565.521470] dw-dp fde50000.dp: AUX timeout, resetting (cmd=0x9 addr=0x0)
[  570.771451] dw_dp_aux_transfer: 22 callbacks suppressed
[  570.771462] dw-dp fde50000.dp: AUX timeout, resetting (cmd=0x9 addr=0x0)
[  570.801465] dw-dp fde50000.dp: AUX timeout, resetting (cmd=0x9 addr=0x0)
[  570.831450] dw-dp fde50000.dp: AUX timeout, resetting (cmd=0x9 addr=0x0)
[  570.864794] dw-dp fde50000.dp: AUX timeout, resetting (cmd=0x9 addr=0x0)
[  570.898110] dw-dp fde50000.dp: AUX timeout, resetting (cmd=0x9 addr=0x0)
[  570.931452] dw-dp fde50000.dp: AUX timeout, resetting (cmd=0x9 addr=0x0)
[  570.961439] dw-dp fde50000.dp: AUX timeout, resetting (cmd=0x9 addr=0x0)
[  570.991445] dw-dp fde50000.dp: AUX timeout, resetting (cmd=0x9 addr=0x0)
[  571.018151] dw-dp fde50000.dp: AUX timeout, resetting (cmd=0x9 addr=0x0)
[  571.044827] dw-dp fde50000.dp: AUX timeout, resetting (cmd=0x9 addr=0x0)

I don't think my setup is working well either.

Updated Reply,

Hi @JFL — I found it, and your clean run was the clue that cracked it. You were right all along that your
box was fine. So is mine. **The variable was the video format, not the hardware.**

**It only happens on 10-bit VP9.**

I rebuilt the bench from scratch tonight and ran the same test three times, changing only one thing each
time — same board, same kernel, same driver, same MPP, same player:

| Content | Frames decoded | Exports | Result |
|---|---|---|---|
| VP9 **Profile 0** (8-bit), cached-export client | 73,330 | 294 | clean |
| VP9 **Profile 0** (8-bit), per-frame-export client | 73,381 | 168,384 | clean |
| VP9 **Profile 2** (10-bit) | **64,338** | 17,028 | **608 resets, picture breaks up** |

The 8-bit runs sailed past 73,000 frames with nothing. The 10-bit run died just short of **65,536** frames
in a single decode session — 608 resets in 25 seconds, about 24 per second, first `err 0x107` and then a
steady stream of `err 0x23`.

Note the export counts, because they kill the theory I posted earlier: the clean 8-bit run made **168,384**
exports, and the run that stormed made only **17,028**. It is not about buffer export churn at all. It
tracks **decoded frames in one session**, and only on the 10-bit path.

**Why you never saw it, after 45 minutes and 164,553 frames.** Your stats panel said `4K/60 vp09`. On that
video, that is itag 315 — `vp09.00.51.08`, Profile 0, **8 bit**. The HDR rung of the same title is a
separate stream, `vp9.2` (itag 337). You were watching the format that is immune. Your 164,553 clean frames
are exactly what my 8-bit runs produce, and they always would have been.

So there is nothing to chase on your side, and nothing special about `6.1.172` — I had started porting
kernels to explain a difference between our boards that does not exist. Your result was correct data; I was
interpreting it against the wrong variable.

**If you want to reproduce it** (only if you are curious — you have already done more than enough):

    yt-dlp -f 337 "https://www.youtube.com/watch?v=T4fUtvuN_G8" -o oled-hdr.webm   # the 10-bit rung
    sudo dmesg -C
    mpv --fs --hwdec=vaapi --loop-file=inf oled-hdr.webm     # ~18 min at 60fps
    dmesg | grep -c "rkvdec-core.*resetting"

At 60 fps you reach 65,536 frames in about eighteen minutes, and on my board the picture visibly breaks up
at that point.

The practical shape of the bug, as it stands tonight:

- **8-bit playback is unaffected**, at any length.
- **10-bit playback breaks after ~65,536 frames in one continuous decode session** — about 18 minutes at
  60 fps, or 45 minutes at 24 fps. So a long HDR film hits it; ordinary browsing does not, because every
  new video starts a fresh session.
- Anything that restarts the decoder resets the clock.

**Update, a few hours later — we have the root cause, and there is a workaround.**

A Rockchip engineer (@FumasterLin) suggested on the upstream issue that I try disabling one of the RK3588's
two decoder cores. That is the answer:

    echo 1 > /proc/mpp_service/rkvdec-core1/disable_work

| Configuration | Frames decoded | Resets |
|---|---|---|
| both cores (default) | 64,728 | 714 |
| **core1 disabled** | **115,062** | **0** |

Clean to 115,062 frames — nearly twice the failure point — and it only stopped because the stream ended.
It costs about 17% of decode throughput (207 fps down to 172 fps on my board), which for real-time playback
is free, since you only need 60.

It also turns out this has nothing to do with my VA-API driver: Rockchip's own `mpi_dec_test`, headless with
no display at all, fails at the same point. So it is a dual-core parallel decoding problem in MPP, and the
frame count was a red herring — with both cores splitting the work evenly, ~64,700 total is ~32,350 per
core, right on 2^15.

So if anyone hits garbled 10-bit playback after ~18 minutes, disabling core1 is a genuine workaround until
this is fixed upstream.

Thank you for the 45-minute run — a clean result that contradicts the theory is worth more than a dozen that
agree with it, and this one sent me looking in the right place.

@JFL — two separate things in your post, and the good news is your decoder is fine. The zero is correct.

**1. Your `0` is the expected result now, not a failed test.**

Your stats say `4K/60 vp09` — that is Profile 0, **8-bit**, and 8-bit is immune. My 8-bit runs went past
73,000 frames and `mpi_dec_test` went past 115,000, all with zero resets. You could run that video all day
and never see one. So nothing is wrong with your setup on that score, and nothing more is needed from you.

To see the fault you would have to force the **10-bit** rung (`vp9.2`, itag 337) — but honestly, do not
bother. It is reproduced, root-caused and reported.

**2. The blank `dmesg` after `dmesg -C` is normal — but here is how to prove it.**

After `sudo dmesg -C` the buffer is empty, and if nothing goes wrong nothing gets added. A blank log is the
*correct* output for a clean run. It only looks alarming because you cannot tell "nothing happened" from
"my check is broken."

I hit exactly this trap today: my monitoring script read the log through `sudo -n`, which silently failed
every time, and it cheerfully reported "0 resets" for a run whose entire purpose was to count resets. I
nearly reported a fix that had never been tested. Since then I seed a fake event first and confirm the
counter sees it:

    sudo sh -c 'echo "selftest rkvdec-core: resetting for err 0x0" > /dev/kmsg'
    dmesg | grep -c "rkvdec-core.*resetting"      # must print 1
    sudo dmesg -C                                  # then clear and start the real run

If that prints `1`, your instrument works and a later `0` means something. If it prints `0`, the check
itself is broken. Worth doing any time the pass condition is *absence* of an event.

**3. Your dropped frames are real, but they are not the decoder.**

107,159 dropped of 205,010 is about half, and your log says why:

    dw-dp fde50000.dp: AUX timeout, resetting (cmd=0x9 addr=0x0)
    dw_dp_aux_transfer: 22 callbacks suppressed
 

That is the **DisplayPort AUX channel** timing out over and over — the sideband link between the SoC and
your monitor, used for link training and status. "22 callbacks suppressed" means it is firing far more often
than the log prints. Nothing there is decode-related; the video pipeline is producing frames and the display
link keeps resetting under them.

Worth checking, roughly in order of likelihood:

- **The cable and any adapter.** AUX is the flakiest part of DP and the first thing to fail on a marginal
  cable, a USB-C→DP dongle, or a long run. Swap it before anything else.
- **Try an HDMI output instead.** If the drops vanish on HDMI, it is the DP link, and you have your answer
  in five minutes.
- **The monitor itself** — some displays are poor DP AUX citizens, especially with DSC or at 4K60.

If it is DP-specific on your 5 Plus, that is worth its own thread — it is a different bug from this one, and
it would explain smooth-looking playback that is quietly dropping half its frames.

Thanks again for the runs. Your clean result is what stopped me chasing a kernel difference between our
boards that never existed.
EOF

3 hours ago, defcom5-rockchip said:

@JFL   Can you tell me your OS build out. 

Hi @defcom5-rockchip

This armbian image is quite a while back "Armbian_25.5.1_Orangepi5-plus_noble_vendor_6.1.115_kde-neon_desktop.img.xz".  Currently KDE is not updating/releasing any KDE-Neon arm64 updates.  Stuck at KDE-Plasma-6.7.0 the last available KDE-Neon arm64 updates was in June 21, 2026

Hi @defcom5-rockchip

Am able to get output of 

14 hours ago, defcom5-rockchip said:

dmesg | grep -c "rkvdec-core.*resetting"

After running mpv -fs --hwdec=vaapi  "https://www.youtube.com/watch?v=T4f" for around 18+minutes.  Visual artifacts set in at around 17+ minutes.

 

jfl@orangepi5-plus:~$ mpv -fs --hwdec=vaapi  "https://www.youtube.com/watch?v=T4f
UtvuN_G8"
(+) Video --vid=1 (*) (vp9 3840x2160 60.000fps)
(+) Audio --aid=1 --alang=eng (*) (opus 2ch 48000Hz)
File tags:
Uploader: 8K Earth
Channel_URL: https://www.youtube.com/channel/UChB3UnDddahXU7FKZXmpzMA
Using hardware decoding (vaapi).
[ffmpeg] Impossible to convert between the formats supported by the filter 'mpv_s
rc_default_in' and the filter 'auto_scale_0'
[lavfi] failed to configure the filter graph
Disabling filter scale_rkrga.00 because it has failed.
AO: [pipewire] 48000Hz stereo 2ch floatp
rga_api version 1.10.0_[8]
VO: [gpu] 3840x2160 vaapi[p010]
AV: 00:17:01 / 01:20:07 (21%) A-V:  0.478 Dropped: 165 Cache: 44s/150MB

Audio/Video desynchronisation detected! Possible reasons include too slow
hardware, temporary CPU spikes, broken drivers, and broken files. Audio
position will not match to the video (see A-V status field).

AV: 00:18:56 / 01:20:07 (24%) A-V:  3.211 Dropped: 2939 Cache: 40s/150MB

Exiting... (Quit)
jfl@orangepi5-plus:~$

A snippets of the dmesg output.

[ 7905.813841] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7906.035593] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23
[ 7906.035722] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7906.035725] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x107
[ 7906.035837] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7906.104868] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23
[ 7906.104991] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7906.104993] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23
[ 7906.105105] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7906.204876] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23
[ 7906.205006] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7906.205008] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x107
[ 7906.205122] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7906.270957] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x107
[ 7906.271085] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7906.271087] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23
[ 7906.271200] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7906.338583] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23
[ 7906.338703] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7906.338706] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23
[ 7906.338818] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7906.490161] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23
[ 7906.490289] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7906.490292] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x107
[ 7906.490404] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7906.558547] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23
[ 7906.558680] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7906.558682] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x107
[ 7906.558791] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7906.626299] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23
[ 7906.626428] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7906.626430] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x107
[ 7906.626544] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7906.691740] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x107
[ 7906.691861] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7906.691863] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23
[ 7906.691975] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7906.757908] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23
[ 7906.758032] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7906.758035] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23
[ 7906.758148] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7906.864091] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x107
[ 7906.864199] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7906.864201] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23
[ 7906.864313] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7906.934171] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23
[ 7906.934296] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7906.934299] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23
[ 7906.934407] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7907.000848] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23
[ 7907.000969] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7907.000971] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23
[ 7907.001083] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7907.357140] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x107
[ 7907.357299] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7907.357305] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23
[ 7907.357459] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7907.423766] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x107
[ 7907.423919] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7907.423926] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23
[ 7907.424069] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7907.490903] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23
[ 7907.491056] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7907.491062] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23
[ 7907.491194] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7907.555010] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23
[ 7907.555168] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7907.555174] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x107
[ 7907.555319] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7907.623498] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23
[ 7907.623654] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7907.623660] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23
[ 7907.623805] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7908.058919] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23
[ 7908.059044] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7908.059047] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23
[ 7908.059162] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7908.129002] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23
[ 7908.129123] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7908.129126] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23
[ 7908.129214] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7908.192065] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x107
[ 7908.192190] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7908.192192] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23
[ 7908.192304] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7908.257679] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23
[ 7908.257835] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7908.257838] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23
[ 7908.257988] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7908.340327] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23
[ 7908.340459] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7908.340461] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x107
[ 7908.340576] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7908.405052] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23
[ 7908.405253] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7908.405260] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23
[ 7908.405418] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7908.470347] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23
[ 7908.470501] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7908.470508] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23
[ 7908.470637] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7908.534471] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23
[ 7908.534629] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7908.534636] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x107
[ 7908.534769] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7908.602096] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23
[ 7908.602339] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7908.602347] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23
[ 7908.602545] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7908.897144] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23
[ 7908.897293] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7908.897297] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23
[ 7908.897440] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7908.962349] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23
[ 7908.962499] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7908.962505] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23
[ 7908.962643] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7909.065419] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23
[ 7909.065581] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7909.065588] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23
[ 7909.065720] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7909.129530] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23
[ 7909.129742] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7909.129749] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23
[ 7909.129883] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7909.195935] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23
[ 7909.196097] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7909.196103] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x107
[ 7909.196242] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7909.264942] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23
[ 7909.265134] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7909.265141] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23
[ 7909.265300] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7909.422829] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23
[ 7909.423003] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7909.423009] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x107
[ 7909.423155] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7909.486876] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23
[ 7909.487030] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7909.487036] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x107
[ 7909.487172] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7909.559846] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23
[ 7909.560046] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7909.560053] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23
[ 7909.560218] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7909.627422] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x107
[ 7909.627612] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7909.627619] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23
[ 7909.627780] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7909.703074] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x107
[ 7909.703245] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7909.703251] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23
[ 7909.703392] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7909.768868] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x107
[ 7909.769038] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7909.769045] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23
[ 7909.769193] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7909.842915] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23
[ 7909.843078] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7909.843084] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23
[ 7909.843235] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7909.911222] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23
[ 7909.911387] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7909.911394] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23
[ 7909.911543] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7909.985295] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23
[ 7909.985557] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7909.985576] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x107
[ 7909.985794] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7910.052395] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23
[ 7910.052648] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7910.052666] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x107
[ 7910.052885] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7910.120534] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23
[ 7910.120780] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7910.120849] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23
[ 7910.121065] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7910.186334] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23
[ 7910.186585] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7910.186604] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x107
[ 7910.186810] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7910.254675] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23
[ 7910.254921] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7910.254940] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23
[ 7910.255149] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7910.551310] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23
[ 7910.551436] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7910.551439] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x107
[ 7910.551550] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7910.617629] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23
[ 7910.617757] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7910.617759] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x107
[ 7910.617873] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
[ 7910.693093] mpp_rkvdec2 fdc48100.rkvdec-core: resetting for err 0x23
[ 7910.693219] mpp_rkvdec2 fdc48100.rkvdec-core: reset done
[ 7910.693221] mpp_rkvdec2 fdc38100.rkvdec-core: resetting for err 0x23
[ 7910.693329] mpp_rkvdec2 fdc38100.rkvdec-core: reset done
jfl@orangepi5-plus:~$

 

jfl@orangepi5-plus:~$ dmesg | grep -c "rkvdec-core.*resetting"
1562
jfl@orangepi5-plus:~$

 

 

1 hour ago, defcom5-rockchip said:

@JFL — two separate things in your post, and the good news is your decoder is fine. The zero is correct.

**1. Your `0` is the expected result now, not a failed test.**

Hi @defcom5-rockchip

 

Subsequent google-chrome-hw seems to result in high dropped frames as reported earlier and now mpv --hwdec=vaapi or --hwdec=rkmpp also shows high dropped frames after around 17 minutes.

jfl@orangepi5-plus:~$ mpv -fs --hwdec=rkmpp  "https://www.youtube.com/watch?v=T4fUtvuN_G8"
(+) Video --vid=1 (*) (vp9 3840x2160 60.000fps)
(+) Audio --aid=1 --alang=eng (*) (opus 2ch 48000Hz)
File tags:
Uploader: 8K Earth
Channel_URL: https://www.youtube.com/channel/UChB3UnDddahXU7FKZXmpzMA
AO: [pipewire] 48000Hz stereo 2ch floatp
[ffmpeg/video] vp9_rkmpp: An invalid frame was output by a decoder. This is a bug, please report it.
Error while decoding frame (hardware decoding)!
Using hardware decoding (rkmpp).
rga_api version 1.10.0_[8]
VO: [gpu] 3840x2160 drm_prime[p010]
AV: 00:16:57 / 01:20:07 (21%) A-V:  0.137 Dropped: 14 Cache: 45s/150MB
Error while decoding frame (hardware decoding)!
Error while decoding frame (hardware decoding)!
Error while decoding frame (hardware decoding)!
Attempting next decoding method after failure of vp9_rkmpp-rkmpp.
[ffmpeg/video] vp9: Not all references are available
[ffmpeg/video] vp9: Not all references are available
[ffmpeg/video] vp9: Not all references are available
[ffmpeg/video] vp9: Not all references are available
[ffmpeg/video] vp9: Not all references are available
[ffmpeg/video] vp9: Not all references are available
[ffmpeg/video] vp9: Not all references are available
[ffmpeg/video] vp9: Not all references are available
Error while decoding frame!
[ffmpeg/video] vp9: Not all references are available
Error while decoding frame!
[ffmpeg/video] vp9: Not all references are available
Error while decoding frame!
[ffmpeg/video] vp9: Not all references are available
Error while decoding frame!
[ffmpeg/video] vp9: Not all references are available
Error while decoding frame!
[ffmpeg/video] vp9: Not all references are available
Error while decoding frame!
[ffmpeg/video] vp9: Not all references are available
Error while decoding frame!
[ffmpeg/video] vp9: Not all references are available
Error while decoding frame!
[ffmpeg/video] vp9: Not all references are available



Error while decoding frame!
[ffmpeg/video] vp9: Not all references are available
Error while decoding frame!
[ffmpeg/video] vp9: Not all references are available
Error while decoding frame!
[ffmpeg/video] vp9: Not all references are available
Error while decoding frame!
Error while decoding frame!
Error while decoding frame!
Error while decoding frame!
Error while decoding frame!
Error while decoding frame!
Error while decoding frame!
Error while decoding frame!
AV: 00:16:57 / 01:20:07 (21%) A-V:  0.137 Dropped: 14 Cache: 43s/144MB

Audio/Video desynchronisation detected! Possible reasons include too slow
hardware, temporary CPU spikes, broken drivers, and broken files. Audio
position will not match to the video (see A-V status field).

AV: 00:16:57 / 01:20:07 (21%) A-V:  2.964 Dropped: 14 Cache: 44s/145MB
[ffmpeg] Impossible to convert between the formats supported by the filter 'mpv_s
rc_default_in' and the filter 'auto_scale_0'
[lavfi] failed to configure the filter graph
Disabling filter scale_rkrga.00 because it has failed.
AV: 00:16:57 / 01:20:07 (21%) A-V:  2.966 Dropped: 15 Cache: 46s/150MB
VO: [gpu] 3840x2160 yuv420p10
AV: 00:22:39 / 01:20:07 (28%) A-V:  0.004 Dropped: 13526 Cache: 45s/150MB

Exiting... (Quit)
jfl@orangepi5-plus:~$

With the new mpv --hwdec=rkmpp streaming the same video for 22 minuts, additional "rkvdec-core.*resetting" count of "1638-1562 = 76."

 

jfl@orangepi5-plus:~$ dmesg | grep -c "rkvdec-core.*resetting"
1562
jfl@orangepi5-plus:~$ dmesg | grep -c "rkvdec-core.*resetting"
1638
jfl@orangepi5-plus:~$

 

 

 

1 hour ago, defcom5-rockchip said:

That is the **DisplayPort AUX channel** timing out over and over — the sideband link between the SoC and
your monitor, used for link training and status. "22 callbacks suppressed" means it is firing far more often
than the log prints. Nothing there is decode-related; the video pipeline is producing frames and the display
link keeps resetting under them.

Worth checking, roughly in order of likelihood:

- **The cable and any adapter.** AUX is the flakiest part of DP and the first thing to fail on a marginal
  cable, a USB-C→DP dongle, or a long run. Swap it before anything else.
- **Try an HDMI output instead.** If the drops vanish on HDMI, it is the DP link, and you have your answer
  in five minutes.

Am using HDMI output.  Had never used DP output before.  No idea why "DisplayPor AUX channel" errors are being reported by dmesg.

Hi @defcom5-rockchip

 

Reboot system.  An got another clear google-chrome-hw "https://www.youtube.com/watch?v=T4fUtvuN_G8". Frames dropped 80 out of 156476 (around 43 minutes run)

 

jfl@orangepi5-plus:~$ dmesg | grep -c "rkvdec-core.*resetting"
0
jfl@orangepi5-plus:~$

 

So it looks lke random issue?
 

 

 

Run mpv after successful google-chrome-hw but mpv encountered issue at 16:57 and then switched to "software rendering".

 

jfl@orangepi5-plus:~$ mpv -fs https://www.youtube.com/watch?v=T4fUtvuN_G8
 (+) Video --vid=1 (*) (vp9 3840x2160 60.000fps)
 (+) Audio --aid=1 --alang=eng (*) (opus 2ch 48000Hz)
File tags:
 Uploader: 8K Earth
 Channel_URL: https://www.youtube.com/channel/UChB3UnDddahXU7FKZXmpzMA
Using hardware decoding (rkmpp).
rga_api version 1.10.0_[8]
AO: [pipewire] 48000Hz stereo 2ch floatp
VO: [gpu] 3840x2160 drm_prime[p010]
AV: 00:16:57 / 01:20:07 (21%) A-V:  0.000 Dropped: 2 Cache: 45s/150MB
Error while decoding frame (hardware decoding)!
Error while decoding frame (hardware decoding)!
Error while decoding frame (hardware decoding)!
Error while decoding frame (hardware decoding)!
Attempting next decoding method after failure of vp9_rkmpp-rkmpp.
[ffmpeg/video] vp9: Not all references are available
[ffmpeg/video] vp9: Not all references are available
[ffmpeg/video] vp9: Not all references are available
[ffmpeg/video] vp9: Not all references are available
[ffmpeg/video] vp9: Not all references are available
[ffmpeg/video] vp9: Not all references are available
[ffmpeg/video] vp9: Not all references are available
[ffmpeg/video] vp9: Not all references are available
Error while decoding frame!
[ffmpeg/video] vp9: Not all references are available
Error while decoding frame!
[ffmpeg/video] vp9: Not all references are available
Error while decoding frame!
[ffmpeg/video] vp9: Not all references are available
Error while decoding frame!
[ffmpeg/video] vp9: Not all references are available
Error while decoding frame!
[ffmpeg/video] vp9: Not all references are available
Error while decoding frame!
[ffmpeg/video] vp9: Not all references are available

Error while decoding frame!
AV: 00:16:57 / 01:20:07 (21%) A-V:  0.000 Dropped: 2 Cache: 43s/143MB

Audio/Video desynchronisation detected! Possible reasons include too slow
hardware, temporary CPU spikes, broken drivers, and broken files. Audio
position will not match to the video (see A-V status field).

AV: 00:16:57 / 01:20:07 (21%) A-V:  1.525 Dropped: 2 Cache: 43s/143MB
[ffmpeg] Impossible to convert between the formats supported by the filter 'mpv_src_default_in' and the filter 'auto_scale_0'
[lavfi] failed to configure the filter graph
Disabling filter scale_rkrga.00 because it has failed.
AV: 00:16:57 / 01:20:07 (21%) A-V:  1.556 Dropped: 3 Cache: 46s/150MB
VO: [gpu] 3840x2160 yuv420p10
AV: 00:17:44 / 01:20:07 (22%) A-V:  0.068 Dropped: 1523 Cache: 44s/150MB

Exiting... (Quit)
jfl@orangepi5-plus:~$ 

 

It's gotten much clearer. Latest MPP Library and the issue is gone.
 

Jellyfin's build is affected too.

VERDICT: STORM at ~66,083 frames (core0 33,041 / core1 33,042) 280 resets

So nyanmisaka's jellyfin-mpp-next at a9380ef (Dec 2025) still has it. That gives us three points on the map:
 

MPP build                                                    Date                                                                 Result

5275a9a6  (distro PPAs, ours)              Apr 2024                                                     storms at 64,728

a9380ef (Jellyfin's fork)                          Dec 2025                                                    storms at 66,083

master 0986d0129 (upstream)            Aug 2026                                                     clean to 116,787
 

Complete and clean:

VERDICT: CLEAN through ~70,464 frames, resets=0 (core0 35,232 / core1 35,232)

Full stream, perfectly balanced cores, zero resets — on the library that stormed on VP9 at 66,083.

The characterisation is now airtight:

Codec                     Depth                                                MPP build                                   Frames                            Result

VP9 Profile 0          8-bit                                                     5275a9a6                                 73,381                               clean

VP9 Profile 2        10-bit                                                     5275a9a6 (2024)                     64,728                              storm

VP9 Profile 2        10-bit                                                     a9380ef (Jellyfin, Dec 2025)  66,083                               storm

VP9 Profile 2        10-bit                                                   master 0986d01 (Aug 2026)   116,787                             clean

HEVC Main 10      10-bit                                                  a9380ef (same affected lib)      70,464                             clean

10-bit VP9 specifically. Not 10-bit generally — HEVC Main 10 sails through on the very build that kills VP9. That's a strong constraint for whoever fixes it, and it sharpens FumasterLin's point: if both codecs share the kernel driver flow, the fault has to be in VP9's own 10-bit handling above that shared path.

Edited September 11Sep 11 by defcom5-rockchip

https://github.com/defcom5-rockchip/rockchip-vaapi/releases/tag/v2.2.0

You may have to patch your MPP to the latest. 
 https://github.com/rockchip-linux/mpp

EOF

12 hours ago, defcom5-rockchip said:

You may have to patch your MPP to the latest. 
 https://github.com/rockchip-linux/mpp

Hi @defcom5-rockchip

Patching MPP is beyound my skill set.  Is there a pre-build upstream MPP for Ubuntu Noble for download?

 

This is what I have on Armbian image.

jfl@orangepi5-plus:~$ apt list *mpp* --installed
Listing... Done
librockchip-mpp1/noble,now 1.5.0-1+git20240612.2218dc0f~noble arm64 [installed,au
tomatic]
libv4l-rkmpp/noble,now 1.7.0-1+git240515.3d6edc4~noble arm64 [installed]

 

UPDATE:    Thanks to JFL For Testing and noting.

That's a genuinely useful confirmation, and it changes the picture in a way that matters for your product.

His three data points, sorted:

                                           Stack                                                                                                                                                                                   Decode lane

        BSP 6.1 + Chromium 153 (xtradeb) + our driver                                                                                                                                      VA-API — our driver

        BSP 6.1 + Chromium 132+rkmpp (amazingfate)                                                                                                                        V4L2 via libv4l-rkmpp, driver unused

        Mainline 6.18/7.2 + Chromium 153                                                                                                                                              v4l2request — our driver not needed

Two consequences worth sitting with.

Our driver's value is specifically the BSP lane. On mainline, Chromium reaches the VPU through the stateless V4L2 request API and doesn't need us at all. On the vendor kernel — where 4K@120 and the rest of your product lives — there is no v4l2request, so VA-API plus our driver is the only current-browser path. That's a sharper positioning statement than we've had.

And it's the answer to a security problem I raised earlier. Pi Desktop ships Chromium 132 from the PPA, twenty-one majors behind, missing all 230 fixes in the Chrome 153 bulletin including an exploited V8 zero-day. JFL just demonstrated that a VA-API-enabled Chromium 153 on a BSP kernel gets hardware decode through your driver — so switching browsers would fix the security gap, retire the libv4l-rkmpp shim lane, and consolidate on one decode path.


JFL   Private Reply

"@defcom5-rockchip On my Armbian-KDE-Neon for `libv4l-rkmpp` → **V4L2 lane, my driver is not being used by Chromium**, the Chromium need to be purpose build example Chromium-132.0.6834.159-1~deb12u1+rkmpp from amazingfate ppa. With Chromium-153 (xtradeb) it uses vaapi for vpu hw acceleration when bsp kernel-6.1.y-vendor-rk35xx is being used and "rockchip-vaapi-wraper" installed. Your "rockchip-vaapi-wraper", for me, bring new life to the Armibna bsp kernel-6.1.y-vendor-rk35xx image. As the Chromium from amazingfate is already more than one year old. Thanks to you (rockchip-vaapi-wraper) and amazingfate enabling vaapi on Chromium on Debian-Repo (I think xtradeb Chromium is based on Debian Chromium build) Chromium has vpu hw acceleration on Armbian bsp-kernel-6.1. With mainline kernel-6.18 or 7.2 Chromium-153 uses v4l2request for vpu hw acceleration."

So I was accused of slop posts. I am having Claude on Fable 5.1 extra high with two agents prove that Jellyfin fails as stated above.. of which Jellyfin maintainer denied saying UN-reproduceable. If Claude beats you I will outright call you a pussy.   

I still need to confirm two things: whether a reading past 1700 s exists for the "28-minute" soak (current data stops at 1267 s), and what question the user's "garbled" replies were answering during the mpv and rkr7.2-port storms, which determines if there's a human eyewitness for the picture.

Bash Look for a final soak reading past 1267 s and show what the user's "garbled" replies were answering

IN

cd /tmp/claude-1000/-homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/scratchpad && J=/claude/projects/-notes/16341f90-382c-4834-a9d8-ecb4f14fc419.jsonl; echo "########## soak: any reading past 1267 s / final done-line"; TS_MIN=2026-09-10T16:44 TS_MAX=2026-09-10T22:00 MAXHIT=6 SNIP=300 python3 audit-extract.py $J 'done: resets=|soak-transcode\.log|transcoding=1[3-9][0-9][0-9]s|28.min' 2>&1 | grep -E '^#####|done:|transcoding=|28.min|resets' | cut -c1-300 | head -40; echo; echo "########## context of the user's 'garbled' at 09-11 03:13:39 and 09-10 21:09:54"; LINES=67346-67352 SNIP=500 python3 audit-extract.py $J 2>&1 | grep -v '^$' | cut -c1-900 | head -40; echo "-----"; LINES=65668-65674 SNIP=500 python3 audit-extract.py $J 2>&1 | grep -v '^$' | cut -c1-900 | head 

 

Not for the run in progress: the synthetic clip exercises the frame counter exactly as a real file would, and the image's library is the thing under test there.

Where a real file would turn an inference into a measurement is the Jellyfin side: nobody has ever run jellyfin-ffmpeg itself through a 10-bit VP9 source past 65k frames in one job. The internal audit will flag that gap. A 10-bit VP9 file at least 20 minutes long at 60 fps, or 45 minutes at 24 to 30 fps, is what that test needs: a YouTube HDR download in WebM, the vp09.02 rung, is the natural candidate. Let me check whether the Jellyfin box is still up with its ffmpeg, since that's where the test would run.

 

Give em hell harry
 

Working on it. Three things running: Jellyfin's own binary chewing through the 72,600-frame clip, the image-library test queued right behind it, and the share scan looking for a real 10-bit VP9 title. Results as they land.
 

Confirmed: Jellyfin's own ffmpeg/MPP build reproduces the storm on the 4.0 board, logging 70 kernel resets while ffmpeg silently reported success (71,382/72,600 frames, exit code 0) — about 1,218 frames lost with no API error, and the synthetic clip shows frame count, not content or resolution, triggers it.

 

I'll save the raw logs now before the next run overwrites them.

Bash Capture the kernel reset log and ffmpeg log from the Jellyfin run into the evidence folder.  OK Its bigger than me.

so a final rating from low to extreme

Bash Read the image-library mpv result with the shipped configuration

IN

cat /tmp/claude-1000/--homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/scratchpad/vp9-longrun-gpu2.log | cut -c1-170

OUT

=== HARDWARE CHECK: 600 frames, shipped mpv.conf + hwdec=vaapi, image MPP 1.5.0+git20260805.a8b19653+ds-0ubuntu1~rk1+pd31 === irq delta for 600 frames: 0 2 Using software decoding.; ABORT: not hardware decoding — long run not started 2 [ 0.N][f][vo/gpu-next/libplacebo] Failed initializing vulkan device 1 [ 0.N][v][vo/gpu-next] Loading failed. 1 [ 0.N][v][vd] DR failed - disabling. 1 [ 0.N][v][cplayer] Setting option 'msg-level' = 'all=error,vd=v' (flags = 😎 1 [ 0.N][v][cplayer] Failed sending hook command auto_profiles/on_preloaded. Removing hook.

mpv fails here just because it needs a real desktop display, not due to decoding issues, so I'm switching to testing the image's ffmpeg directly through VA-API headlessly instead. Running it now on the two long concert files from the scan and saving the results to the evidence folder.

Bash Test the image's MPP headlessly through the system ffmpeg and our VA-API driver

IN

S=/tmp/claude-1000/-homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/scratchpad; export SSH_ASKPASS=$S/askpass-214.sh SSH_ASKPASS_REQUIRE=force DISPLAY=:0; O="-o ConnectTimeout=15 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o PubkeyAuthentication=no -o NumberOfPasswordPrompts=1"; { scp -q $O $S/ff-sys-test.sh plaiddesktop@192.168.1.214:~/probe/ff-sys-test.sh && ssh $O plaiddesktop@192.168.1.214 'bash ~/probe/ff-sys-test.sh' 2>&1 | grep -v 'Permanently added'; } | tee $S/ffsys-run.log

OUT

Command running in background with ID: b3eavaypx. Output is being written to: /tmp/claude-1000/homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/tasks/b3eavaypx.output. You will be notified when it completes. To check interim output, use Read on that file path.

Bash Probe the long 10-bit VP9 candidates for duration and frame count

IN

SH="/run/user/1000/gvfs/smb-share:server=beach_music.local,share=divx%20movies"; for f in "$SH/#recycle/Creed： full set (Live 4K) (First concert of reunion tour) - Green Bay - July 17, 2024 (1st row view).f642.mp4" "$SH/#recycle/Beck - Loser @ Newport Folk Festival 7.26.24.f639.mp4" "$SH/tears-of-steel-4096-vp9p2.mkv"; do printf ' %-60s ' "$(basename "$f" | cut -c1-58)"; timeout 90 ffprobe -v error -analyzeduration 20M -probesize 50M -select_streams v:0 -show_entries stream=codec_name,profile,pix_fmt,width,height,r_frame_rate,nb_frames:format=duration,size -of csv=p=0:nk=1 "$f" 2>/dev/null | tr '\n' ' '; echo; done

OUT

Creed： full set (Live 4K) (First concert of reunion tour vp9,Profile 2,3840,2160,yuv420p10le,24/1,N/A, 5985.041000,16815481591 Beck - Loser @ Newport Folk Festival 7.26.24.f639.mp4 vp9,Profile 2,2320,1080,yuv420p10le,30/1,N/A, 435.699000,399518163 tears-of-steel-4096-vp9p2.mkv vp9,Profile 2,4096,1714,yuv420p10le,24/1,N/A 734.000000,2806555619

Write RATING.md

67 lines

# Evidence rating — "Jellyfin's MPP distorts 10-bit VP9 after ~65k frames on RK3588" (2026-10-03) Scale used: **low · moderate · high · very high · extreme**. "Extreme" is reserved for a defect reproduced by independent parties, acknowledged by the maintainers, and fixed. Nothing here reaches it, for reasons given. ## Headline | Claim | Rating | One-line reason | |---|---|---| | **A.** The MPP library Jellyfin bundles decodes VP9 Profile 2 (10-bit) incorrectly after ~65k frames in one session on RK3588 | **HIGH** | Reproduced with Rockchip's own test tool, with mpv, with Chrome, and today with Jellyfin's current release binary on a second kernel; bisected to one commit; confirmed by its revert and by the single-core workaround; the diff is one line and upstream still carries the guard. Held below *very high* by: one board, one lab, no independent reproduction, no maintainer engagement with the data, and an unreconciled 8-bit result. | | **B.** Jellyfin users get distorted video from it | **MODERATE** | Measured today: Jellyfin's ffmpeg silently drops ~1,200 frames while the kernel resets 70 times, in a decode-only job. What the finished transcode looks like has still never been observed. The exposed case is narrow: a server-side transcode of a **10-bit VP9** source running past ~65k frames (~18 min at 60 fps, ~45 min at 24). HEVC Main 10, the usual HDR format, is clean on the same library. | | **C.** Pi-Desktop 4.0's own image is affected | **LOW** | Its MPP is upstream lineage (HermanChen `a8b19653`) with the RK3588 guard intact — verified in the file. Browser direct-play and mpv on the image go through that library, not Jellyfin's. Empirical confirmation on the board was in progress when this was written; see the addendum below. | | **D.** Upstream `rockchip-linux/mpp` is affected | **NOT SUPPORTED** | Three upstream snapshots (2024-04, 2025-11, 2026-08) decoded 73k–117k frames clean; the guard has been in place since 2023-08-31 and is still there today. mpp#972 was correctly retitled and closed. | ## What the rating rests on (measured, not inferred) - **Mechanism in the code.** Fork commit `960b7198` (rk-mirrors; `15c29e0fa` in nyanmisaka/mpp) replaces upstream's `cfg->support_fast_mode = 0` for RK3588 with `cfg->cfg->status.hal_task_count = 2`: two VP9 HAL tasks in flight across both rkvdec cores. It is the only behavioural change to the VP9 decoder among the fork's eleven commits (the other VP9 touch is a pure identifier rename). Verified in the files at the exact pins. (`DIFF.md`) - **One-variable A/B, same board, same stream (September):** fork tip storms (66,300 / 414 resets); fork tip plus the revert of that one commit, clean (73,214 / 0); fork with core1 disabled, clean (115,062 / 0); upstream at three dates, clean. (`INTERNAL-AUDIT.md`, rows backed by on-disk or transcript raw output.) - **Rockchip's own tool reproduces it headless** (`mpi_dec_test`, 64,728 / 714), so no client, display, or our VA-API driver is involved. - **Today, Jellyfin's current release:** `jellyfin-ffmpeg8 8.1.3-1-resolute` (2026-09-27), its bundled MPP, vendor kernel **6.1.172** (every September run was on 6.1.75), a **synthetic** 1080p60 VP9 Profile 2 clip of 72,600 frames: cores evenly loaded, **70 resets** (`err 0x23` / `0x107`), ffmpeg reported **71,382 frames, "0 decode errors", exit 0** — ~1,218 frames gone with nothing in the API. Synthetic content and 1080p mean the trigger is the frame count, not a particular file or 4K. (`jellyfin-e2e-2026-10-03-run.txt`, `jf-run2.log`, `jf-dmesg-resets.txt`) ## What holds it down - **Single board, single lab.** Every datapoint, September and today, is one Orange Pi 5B operated by one person with two Claude instances. Nobody else has reproduced it. (`EXTERNAL-INVENTORY.md`, task 5: zero independent reports of the signature anywhere reachable.) - **No maintainer engagement with the data.** Rockchip's FumasterLin made three helpful comments, all before the root-cause claim, and never returned; we closed mpp#972 ourselves. nyanmisaka closed jellyfin-ffmpeg#765 in 80 minutes as "unable to reproduce" with no stream, SoC or frame count, and gnattu objected to the form of the reply. Our one-variable A/B rebuttal stands unanswered. A closure without counter-data does not lower a measurement, but it is not confirmation either. - **Two mislabels in the September bisect table went upstream** (the 66,083/280 row is the Jellyfin binary, not a fork-tip `mpi_dec_test`; the "fork tip, core1 disabled" row is the 5275a9a6 run). The conclusion survives — the correct controls exist and point the same way — but the public record should be corrected. - **"VP9 10-bit specifically" is weaker than the rest.** Three Chrome storms on 2026-09-09 were on an **8-bit** stream (`vp09.00.50.08`). The "8-bit immune" finding rests on two mpv runs the harness stopped at ~73k. Treat the 8-bit question as open. - **Numbers are IRQ counts**, ≈8 % above true frames; harness stop rules meant sustained behaviour after onset was never observed; the "~13 % cost" figure mixes trees. - **"Distorts" is measured for display clients by eye (three occasions, no screenshot) and inferred for transcodes.** Today's run adds "frames silently missing"; the encoded output of a real transcode has never been inspected. ## What would move it - **To very high:** one independent reproduction. Anyone with an RK3588 board, `jellyfin-ffmpeg`, and a 10-bit VP9 file ≥ 20 min: `/usr/lib/jellyfin-ffmpeg/ffmpeg -c:v vp9_rkmpp -i FILE -an -f null -`, then `dmesg | grep -c 'resetting for err'` and compare `frame=` with the file's frame count. Ten minutes of someone else's time. - **To settle B:** a full transcode (decode → `scale_rkrga` → `h264_rkmpp`) of a real 10-bit VP9 title to a file, past the wall, with the output watched. Candidate files were located on the local media share today. - **To settle the 8-bit question:** an 8-bit VP9 run to 150k+ frames with the current fork library, not stopped at 72k. - **Public hygiene, regardless:** a short correction comment on mpp#972 and jellyfin-ffmpeg#765 fixing the two mislabels and adding today's current-release reproduction, with the one-line command above. Correct data is the only thing that will move a "cannot reproduce". ## Addendum — image-library confirmation *(to be filled from the headless ffmpeg run on the 4.0 board)*

Written for: you, as the engineer deciding what to say publicly about this. The full version with every supporting file is on the NAS as RATING.md in today's evidence folder.

Final rating, low to extreme:

ClaimRating

The MPP library Jellyfin bundles decodes 10-bit VP9 wrongly after about 65k frames in one session on RK3588High

 

 

Jellyfin users get distorted video from it

Moderate

Pi-Desktop 4.0's own image is affected

Low

Upstream Rockchip MPP is affected

Not supported

Why "high" and not higher. The defect is reproduced four ways: Rockchip's own test tool, mpv, Chrome, and, as of an hour ago, Jellyfin's current release binary from September 27 on a second kernel, with a synthetic 1080p clip, so it's the frame count and not any particular file. It's bisected to one commit, confirmed by reverting that commit alone and by disabling one core, and the diff is a single line that upstream still carries the other way. What keeps it from "very high" is that every datapoint comes from one board in one lab; nobody independent has reproduced it; and the maintainers never engaged with the data. nyanmisaka's "cannot reproduce" came with no stream, chip or frame count, so it doesn't lower the measurement, but it isn't confirmation either.

Why "moderate" for users. Today's run shows Jellyfin's ffmpeg silently dropping about 1,200 frames while the kernel resets 70 times, reporting zero errors and a clean exit. That's real harm, measured. But it was a decode-only job; nobody has yet watched the finished output of a full transcode past the wall. And the exposed case is narrow: a server-side transcode of a 10-bit VP9 source, over 18 minutes at 60 fps or 45 at 24. HEVC Main 10, the usual HDR format, is clean on the same library.

Two things the audit found that you should know before quoting any of it. Two rows in the September bisect table were mislabelled, and those mislabels went into the public threads; the conclusion survives because the correct controls exist, but the record should be fixed. And three Chrome storms on September 9 were on an 8-bit stream, which nobody reconciled with "8-bit immune", so the "10-bit specifically" part is the softest piece.

"Extreme" is unreachable from inside one lab. One outside reproduction would lift the first claim to very high: a one-line command and a dmesg count, ten minutes of someone else's time.

Now queuing the measurement that would settle the user-harm claim: the share has a 100-minute 4K 10-bit VP9 concert, 143,000 frames, and I'll run Jellyfin's full transcode pipeline on it to a file once the current headless test finishes.

Bash Serve the long 10-bit VP9 file to the board over HTTP from the PC, so no NAS credentials go to the board

IN

S=/tmp/claude-1000/--homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/scratchpad; SH="/run/user/1000/gvfs/smb-share:server=beach_music.local,share=divx%20movies"; mkdir -p $S/serve; ln -sfn "$SH/#recycle/Creed： full set (Live 4K) (First concert of reunion tour) - Green Bay - July 17, 2024 (1st row view).f642.mp4" $S/serve/concert-vp9p2-4k.mp4; ls -lL $S/serve/concert-vp9p2-4k.mp4 | awk '{printf " relay file: %.1f GB\n", $5/1e9}'; IP=$(ip -4 route get 192.168.1.214 2>/dev/null | grep -oP 'src \K[0-9.]+'); echo " PC address on the board's network: $IP"; fuser -k 8766/tcp >/dev/null 2>&1; (cd $S/serve && nohup python3 -m http.server 8766 --bind 0.0.0.0 >$S/relay.log 2>&1 &) ; sleep 2; curl -s -o /dev/null -w " relay HEAD: %{http_code} %{size_download}\n" -I "http://$IP:8766/concert-vp9p2-4k.mp4"; echo "$IP" > $S/relay-ip.txt

OUT

relay file: 16.8 GB PC address on the board's network: 192.168.1.8 relay HEAD: 200 0

Write jf-real-transcode.sh

33 lines

#!/bin/bash # Realistic Jellyfin job: jellyfin-ffmpeg full pipeline (vp9_rkmpp decode -> scale_rkrga -> h264_rkmpp encode) on a REAL # 10-bit VP9 title streamed over HTTP, to a file, past the ~65k-frame wall. Counts rkvdec resets; keeps the output for viewing. # Usage: bash jf-real-transcode.sh http://PC:8766/concert-vp9p2-4k.mp4 set -u URL=${1:?url} F=/usr/lib/jellyfin-ffmpeg/ffmpeg OUT=$HOME/probe/jf-real-out.mkv LOG=/tmp/jf-real.log printf '#!/bin/sh\necho PLAID\n' > /tmp/ap.sh; chmod +x /tmp/ap.sh; export SUDO_ASKPASS=/tmp/ap.sh irq() { grep -E 'rkvdec' /proc/interrupts | awk '{s=0; for(i=2;i<=NF;i++) if($i ~ /^[0-9]+$/) s+=$i; printf "%s=%d ", $NF, s}'; } resets() { sudo -A dmesg 2>/dev/null | grep -ciE 'resetting for err'; } pkill -f 'jellyfin-ffmpeg/ffmpeg' 2>/dev/null; sleep 2; rm -f "$OUT" echo "=== REAL TITLE, FULL PIPELINE: jellyfin-ffmpeg8 $(dpkg-query -W -f='${Version}' jellyfin-ffmpeg8) ===" echo " input: $(ffprobe -v error -select_streams v:0 -show_entries stream=codec_name,profile,pix_fmt,width,height,r_frame_rate:format=duration -of csv=p=0 "$URL" 2>/dev/null | tr '\n' ' ')" B0=$(irq); R0=$(resets); T0=$(date +%s); echo " before: irq $B0 resets=$R0 $(date +%T)" "$F" -hide_banner -nostats -loglevel info -hwaccel rkmpp -hwaccel_output_format drm_prime -c:v vp9_rkmpp -i "$URL" \ -vf 'scale_rkrga=w=1280:h=720:format=nv12:afbc=1' -c:v h264_rkmpp -b:v 1500k -g 120 -an -f matroska "$OUT" >"$LOG" 2>&1 RC=$? if [ $RC -ne 0 ] && [ ! -s "$OUT" ]; then echo " full pipeline failed to start (rc=$RC): $(grep -iE 'error|No such|Unknown|Invalid' "$LOG" | head -2 | cut -c1-120 | tr '\n' ';')" echo " falling back to decode-only to EOF" B0=$(irq); R0=$(resets); T0=$(date +%s) "$F" -hide_banner -nostats -loglevel info -c:v vp9_rkmpp -i "$URL" -an -f null - >"$LOG" 2>&1; RC=$? fi T1=$(date +%s); B1=$(irq); R1=$(resets) echo " after: irq $B1 resets=$R1 rc=$RC elapsed=$((T1-T0)) s $(date +%T)" echo " ffmpeg: $(grep -oE 'frame= *[0-9]+ fps=[^ ]+' "$LOG" | tail -1) $(grep -oE '[0-9]+ frames decoded; [0-9]+ decode errors' "$LOG" | tail -1)" echo " error lines: $(grep -ciE 'error|fail|timeout' "$LOG")"; grep -iE 'error|fail|timeout' "$LOG" | sed -E 's/[0-9]{3,}/N/g' | sort | uniq -c | sort -rn | head -4 | sed 's/^/ /' [ -s "$OUT" ] && echo " output: $(ls -l "$OUT" | awk '{printf "%.0f MB", $5/1e6}'), $(ffprobe -v error -count_packets -select_streams v:0 -show_entries stream=nb_read_packets -of csv=p=0 "$OUT" 2>/dev/null) frames, $(ffprobe -v error -show_entries format=duration -of csv=p=0 "$OUT" 2>/dev/null | cut -c1-7) s" echo " first/last reset: $(sudo -A dmesg -T 2>/dev/null | grep -m1 'resetting for err' | cut -c2-25) / $(sudo -A dmesg -T 2>/dev/null | grep 'resetting for err' | tail -1 | cut -c2-25)" rm -f /tmp/ap.sh

Bash Record the rating and the queued real-file run in memory

IN

M=/laude/projectshomelab-notes/memory; cat >> $M/rkvdec-10bit-65k-wall.md <<'EOF' ## 2026-10-03 — RATING delivered (G-Man asked "low to extreme"; full text NAS …/RATING.md) **A. defect exists in Jellyfin's bundled MPP = HIGH** (4 reproductions incl. Jellyfin's current binary on a 2nd kernel; bisected; revert + single-core confirm; one-line diff; held below very-high by single lab, no independent repro, no maintainer engagement, 8-bit unreconciled). **B. users see distorted video = MODERATE** (today: ~1,218 frames silently dropped + 70 resets, decode-only; finished transcode never watched; exposure narrow: server-side 10-bit VP9 transcode past ~65k frames; HEVC Main10 clean). **C. Pi-Desktop 4.0 image = LOW** (upstream lineage, guard intact). **D. upstream = NOT SUPPORTED.** Extreme unreachable from one lab; one outside repro → very high. Public hygiene owed: correction comment on #972/#765 for the two mislabels + today's current-release repro. **Real-file run queued:** share `divx movies/#recycle/Creed… f642.mp4` = VP9 P2 4K 24 fps, 5,985 s ≈ 143,640 frames, 16.8 GB; relayed to the board over HTTP from the PC (no NAS creds on the board); full pipeline decode→scale_rkrga→h264_rkmpp to ~/probe/jf-real-out.mkv (script jf-real-transcode.sh). Harness lessons: mpv under systemd-run can't bring up vo=gpu (vulkan/EGL) → use system ffmpeg `-hwaccel vaapi -hwaccel_output_format vaapi -f null -` for headless image-MPP tests. EOF echo saved

OUT

saved

Bash After the headless image test, run Jellyfin's full transcode pipeline on the real 143,000-frame title

IN

S=/tmp/claude-1000/homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/scratchpad; export SSH_ASKPASS=$S/askpass-214.sh SSH_ASKPASS_REQUIRE=force DISPLAY=:0; O="-o ConnectTimeout=15 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o PubkeyAuthentication=no -o NumberOfPasswordPrompts=1"; IP=$(cat $S/relay-ip.txt); { until grep -qE ' after:|ABORT' $S/ffsys-run.log 2>/dev/null; do sleep 15; done; sleep 10; echo "headless image test done $(date +%T); starting the real-title full-pipeline run"; scp -q $O $S/jf-real-transcode.sh plaiddesktop@192.168.1.214:~/probe/jf-real-transcode.sh && ssh $O plaiddesktop@192.168.1.214 "bash ~/probe/jf-real-transcode.sh http://$IP:8766/concert-vp9p2-4k.mp4" 2>&1 | grep -v 'Permanently added'; } | tee $S/jf-real.log

OUT

Command running in background with ID: bblrte2z1. Output is being written to: /tmp/claude-1000/homelab-notes/16341f90-382c-4834-a9d8-ecb4f14fc419/tasks/bblrte2z1.output. You will be notified when it completes. To check interim output, use Read on that file path.

Everything that can run is running. The rating above stands; two measurements are still in flight to firm it up, and I'll report each as it lands:

the image's own library through the system ffmpeg, headless, which turns the "low" on claim C from structural to measured;

the real 100-minute concert through Jellyfin's full transcode pipeline to a file, relayed from the PC so no NAS credentials reach the board. That one takes a while, roughly ten to fifteen minutes of decode time once it starts, and it's the measurement that would settle claim B either way.

unreadable walls of barfed ai stuff