MPP +pd35 — AV1 film grain applied on RK3588 (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. On top of +pd34 (VP9 on both decoder cores, AV1 without the double decode) it fixes one thing: AV1 film grain is now applied by the hardware. MPP programmed every grain register and never set the bit that turns the synthesis on, so every AV1 stream with film grain decoded to the clean picture under it. Built from the snapshot Plaid Pi ships (1.5.0+git20260805.a8b19653) with nine 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 decoding AV1 through MPP on an RK3588/RK3588S — browsers via rockchip-vaapi, mpv, ffmpeg and GStreamer builds with rkmpp — who wants grainy AV1 (Netflix-style encodes, libaom/SVT with grain tables) to look as the encoder meant it. Everything in +pd34 is still here; if you do not care about grain, +pd34 is fine. rockchip-vaapi 4.0.0 documents its AV1 numbers with this build (libaom 215/242 conformance vectors, Chromium 11/13 and 23/23; the three film-grain streams are the difference to +pd34). Plaid Pi 6.0 ships it.

Before you install: librockchip-mpp1 is the board's shared hardware-video-decode library — every program that decodes through MPP will use this build once it is installed, not only the one you installed it for. Applying grain costs decoder time: on a 3840×2160 10-bit AV1 stream with grain on every frame MPP's own test tool ran at 85 fps without grain and 67–70 fps with it (about 3 ms per 4K frame), still above 60 fps; players that apply grain themselves are not affected (ffmpeg's hwaccel only asks the hardware for grain when it does not export the grain itself), and rockchip-vaapi has RKVA_AV1_NO_GRAIN=1 to switch it off per decode. Streams and frames without grain are untouched: 14 libaom vectors without film grain decode identically with +pd34 and +pd35, frame by frame.

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+pd35_arm64.deb
# Ubuntu 24.04 (codename "noble")
sudo apt install ./librockchip-mpp1_1.5.0+git20260805.a8b19653+ds-0ubuntu1.rk1+pd35.noble1_arm64.deb

The version sorts above +pd34, the Ubuntu-Rockchip PPAs' and Plaid Pi 5.x'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.x holds all three: 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+pd35 and …~rk1+pd35~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, or the +pd34 package from the previous release; if you also installed -vpu1/-dev, sudo apt remove librockchip-vpu1 librockchip-mpp-dev first.

Check it is in use: with MPP's test tool on libaom's av1-1-b8-23-film_grain-50.ivf, mpi_dec_test -t 16777224 -i av1-1-b8-23-film_grain-50.ivf -o out.yuv now equals ffmpeg -c:v libdav1d -i av1-1-b8-23-film_grain-50.ivf -pix_fmt nv12 -f rawvideo ref.nv12 byte for byte; with +pd34 the two differ on every frame. Through rockchip-vaapi, Fluster's film-grain vectors pass.

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

• Film grain on the post-processor output (debian/patches/0009). vdpu_av1d_set_fgs() in the RK3588 AV1 HAL built the scaling tables and grain blocks for every frame with apply_grain set but left swreg7.sw_apply_grain at 0 — the line that sets it had come over from the Hantro reference code as a comment. The fix sets the bit when the post-processor output is enabled, which MPP always does on this decoder; mainline Linux sets the same bit for the same hardware. The change was reported, with the patch, by lukaszsobala in rockchip-linux/mpp issue rockchip-linux#974; the fix is nyanmisaka's. A pull request with it (plus the removal of the dead Hantro per-buffer grain code) is prepared for upstream; this repository carries the two commits on the fix-av1d-film-grain branch (tag pd35).
  • Bit-exact against dav1d (Orange Pi 5B, MPP API test program, one packet per temporal unit, every output frame compared by MD5): libaom av1-1-b8-23-film_grain-50 and av1-1-b10-23-film_grain-50 10/10 frames each (0/10 with +pd34); eight 1280×720 streams encoded from film-grain tables, 8- and 10-bit, 48 frames each, all 48 (at most 14 before — the frames where the grain changes no pixel), covering inherited parameters (update_grain = 0 from all eight reference slots), show_existing_frame, chroma_scaling_from_luma, luma-only grain, ar_coeff_lag 0–3, partial scaling ranges and clip_to_restricted_range; an SVT-AV1 3840×2160 60 fps 10-bit stream, 30/30; a Tears of Steel 1080p 10-bit clip with one new grain table and eleven inherited frames, 12/12. libaom's decoder agrees with dav1d on every stream.
  • AFBC output (MPP_FRAME_FBC_AFBC_V2, decompressed with RGA): 436 of 436 frames bit-exact. 8-bit output from 10-bit streams (MPP_DEC_SET_OUTPUT_FORMAT = YUV420SP): the grain is applied before the conversion — the output equals dav1d's grained decode rounded as the post-processor rounds, on every sample of 70 frames.
  • Unchanged without grain: 14 libaom vectors without film grain (quantizer 00/31/63 at 8 and 10 bits, 66×66 and 226×226, allintra, cdfupdate, mv, mfmv, svc-L1T2, svc-L2T2) decode identically with +pd34 and +pd35.
  • Speed: free-running mpi_dec_test on the 1201-frame 4K60 10-bit stream, two runs each: 85.1 / 85.8 fps with +pd34, 67.0 / 69.5 fps with +pd35.
• Still here from +pd34: VP9 on both RK3588 decoder cores (rockchip-linux/mpp PR rockchip-linux#976, accepted by Rockchip) and the deferred reference refresh that lets rockchip-vaapi 3.5.0+ decode each AV1 picture once (4K60 AV1 in Firefox). See the +pd34 release for the details and measurements.

Tested on: Orange Pi 5B (RK3588S), vendor kernel 6.1.189, Ubuntu 26.04 (a Plaid Pi image). rockchip-vaapi 4.0.0's whole conformance set (H.264, HEVC, AV1, VP9 — 940 vectors) and its browser and mpv checks were run on this build. Other RK35xx SoCs: untested here — RK3588 is the only SoC with this AV1 decoder, so the change cannot reach the others. The noble build was smoke-tested on the same board inside a noble chroot: its own mpi_dec_test on av1-1-b8-23-film_grain-50.ivf equals dav1d's grained decode byte for byte.

Source: mpp_pd35-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–0009. The orig tarball is yisding/mpp ysp/main at a8b19653 (upstream 1.0.12 plus ysp fixes, see debian/README.source); this repository carries the VP9 change (pd34 tag, PR rockchip-linux#976) and the film-grain change (pd35 tag, branch fix-av1d-film-grain). To rebuild the noble package: dpkg-source -x, then dch -l '~noble' -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) wrote the second commit (the dead-code removal), the test program and the test-stream generator, ran the comparisons on my board over ssh and drafted this text; the one-line fix is nyanmisaka's from issue rockchip-linux#974. I checked the results and I am responsible for them. — defcom5-rockchip

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.deb

The 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-size set 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