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