Repository navigation
MPP +pd34 — VP9 on both RK3588 decoder cores, AV1 without the double decode (Ubuntu 24.04 and 26.04 builds)
A third-party build of Rockchip's MPP video decode library (librockchip-mpp1) for RK3588 / RK3588S boards that run the rockchip-vaapi driver. It fixes two things: VP9 decoding on both hardware decoder cores (which failed after about 65,000 frames — 16–18 minutes of 60 fps video — in the builds that tried it), and AV1 in Firefox dropping most frames at 4K60. Built from the snapshot Plaid Pi ships (1.5.0+git20260805.a8b19653) with eight patches on top. This is an unofficial rebuild by defcom5-rockchip — not published or endorsed by Rockchip Electronics or by Canonical/Ubuntu.
Who needs it: anyone running rockchip-vaapi on an RK3588/RK3588S board whose MPP is either the stock one (VP9 one frame in flight — correct, but slower) or one of the forks that re-enabled the two-frame VP9 path by reverting Rockchip's guard and inherited that failure (the Ubuntu-Rockchip PPAs, jellyfin-ffmpeg's bundled copy). The AV1 improvement needs rockchip-vaapi 3.5.0 or later; the VP9 fix helps with any version. Plaid Pi 5.0 users already have the earlier form of the VP9 fix (+pd33); 5.5 ships this one.
Before you install: librockchip-mpp1 is the board's shared hardware-video-decode library — every program that decodes through MPP (browsers via rockchip-vaapi, mpv, ffmpeg builds with rkmpp, GStreamer plugins, Jellyfin's ffmpeg if it uses the system library) will use this build once it is installed, not only the one you installed it for. These .debs are built against Ubuntu 24.04 and 26.04; other distributions are untested here.
Install (pick your Ubuntu release). One package is enough for the browsers, mpv, ffmpeg and GStreamer builds that use MPP:
# Ubuntu 26.04 (codename "resolute")
sudo apt install ./librockchip-mpp1_1.5.0+git20260805.a8b19653+ds-0ubuntu1.rk1+pd34_arm64.deb
# Ubuntu 24.04 (codename "noble")
sudo apt install ./librockchip-mpp1_1.5.0+git20260805.a8b19653+ds-0ubuntu1.rk1+pd34.noble1_arm64.debThe version sorts above the Ubuntu-Rockchip PPAs' and Plaid Pi's, so apt keeps it; sudo apt-mark hold librockchip-mpp1 is optional insurance against a future archive build with a higher version. librockchip-vpu1 and librockchip-mpp-dev are only needed to build against MPP or to run the demos; on an Ubuntu-Rockchip PPA system librockchip-vpu1 replaces the PPA's librockchip-vpu0 and removes its rockchip-mpp-demos (apt will say so). Plaid Pi 5.0 holds all three at +pd33: install librockchip-mpp1, librockchip-vpu1 and librockchip-mpp-dev together with --allow-change-held-packages. (File names use . where the package versions have ~ — GitHub renames them on upload; the versions inside are …~rk1+pd34 and …~rk1+pd34~noble1.)
Remove / go back: apt never downgrades by itself. sudo apt-mark unhold librockchip-mpp1 (if held), then sudo apt install --allow-downgrades librockchip-mpp1=<version> with the version apt-cache policy librockchip-mpp1 lists for your archive (for example =1.5.0-1+git20240717.5275a9a6~noble on the jjriek PPA); if you also installed -vpu1/-dev, sudo apt remove librockchip-vpu1 librockchip-mpp-dev first. On a system whose archive has no MPP at all, sudo apt remove librockchip-mpp1 is the way back.
Check it is in use: journalctl -k | grep -c "resetting for err" stays 0 through a long VP9 session; with rockchip-vaapi, RK_VAAPI_LOG reports "deferred refresh available" for AV1.
Problems? Open an issue on the driver's tracker (one place for the whole stack; say which MPP build you have): https://github.com/defcom5-rockchip/rockchip-vaapi/issues
What is fixed
- VP9 on both RK3588 decoder cores. MPP's VP9 frame label never wrapped, and the RK3588 cores behave as if they compare it in 16 bits. Builds that kept two frames in flight (one per core) therefore failed after ~65,536 frames (
resetting for err 0x23/0x107, frames lost silently), which is why Rockchip's own code kept VP9 at one frame in flight on RK3588. This build carries the fix in the form Rockchip asked for in review (rockchip-linux/mpp PR rockchip-linux#976, v2, which Rockchip has accepted and is merging through its internal review): the label wraps within 1..0xffff and the RK3588 exception is gone, so RK3588 runs VP9 with MPP's default number of frames in flight, like the other chips.- MPP's own test tool (Orange Pi 5B): 201,600 frames of 4K60 VP9 in one session (three passes through the wrap), 0 resets, 214 / 231 fps (10-bit / 8-bit); on the same clips at 5,760 frames the one-frame guard gives 149 / 181 fps against 214 / 233 here. Per-frame CRCs identical to the one-frame decode: 4K at 5,760 frames, and 1080p60 at 201,600 frames through three wraps.
- Through rockchip-vaapi 3.5.0 on the same board: ffmpeg decoding 201,600 frames of 4K 10-bit VP9 in one session (three wraps), 0 resets, 173 fps; Firefox and Chromium each playing a 72,000-frame 4K60 10-bit VP9 file (one wrap), 0 resets.
- AV1 without the double decode (seven patches). Firefox asks for each decoded AV1 picture as soon as it is submitted; with stock MPP the driver had to decode most pictures a second time to keep the reference frames right, and 4K60 AV1 dropped 91–95 % of frames. These patches let the driver defer the reference update ("deferred reference refresh"), so each picture is decoded once; with rockchip-vaapi 3.5.0 the same stream drops about 8 % as shipped, and 1.2–1.5 % after start-up with Firefox's
media.video-queue.hw-accel-sizeset to 10 (Plaid Pi's setting). Two exported functions are added; the library's binary interface (soname) is unchanged, so nothing else needs rebuilding.
Tested on: Orange Pi 5B (RK3588S), vendor kernel 6.1.189, Plaid Pi 5.0 (Ubuntu 26.04). The earlier two-frame form of the VP9 fix was also confirmed by a user on an Orange Pi 5 Plus (RK3588, Ubuntu 24.04). The noble build was smoke-tested on the same board (its own mpi_dec_test, 5,760 frames of 4K 10-bit VP9, about 215 fps, 0 resets, both cores). Other RK35xx SoCs: untested here — the label wrap is harmless for them, and the RK3588-only exception that was removed never applied to them.
Source: mpp_pd34-source.tar holds the Debian source package (.dsc, .orig.tar.gz, .debian.tar.xz, original file names, so dpkg-source -x works after untarring); patches are debian/patches/0001–0008. The orig tarball is yisding/mpp ysp/main at a8b19653 (upstream 1.0.12 plus ysp fixes, see debian/README.source); this repository carries only the VP9 change (PR rockchip-linux#976, the pd34 tag). To rebuild the noble package: dpkg-source -x, then dch -l '~noble1' -D noble 'Rebuild for noble.' and dpkg-buildpackage -b in a noble chroot. Upstream: https://github.com/rockchip-linux/mpp . Apache-2.0; the packaging follows Ubuntu Rockchip's.
SHA256SUMS attached (file names as downloaded, so sha256sum -c SHA256SUMS works in the download folder).
An LLM assistant (Claude) prepared the patches and, for this build, ran the test-tool passes and the ffmpeg/Firefox/Chromium soak on my board over ssh; the earlier browser and mpv soaks and the by-eye checks were mine. I checked the results and I am responsible for them. — defcom5-rockchip