Correct the claim: Radxa's plugin is not decode-only

It contains every encoder — strings on its .so lists mpph264enc, mpph265enc,
mppjpegenc and mppvp8enc. The earlier claim here was wrong, and it was the
headline reason given for building our own, so it needs correcting rather than
quietly dropping.

What actually happened is one cause behind four symptoms, and this build
surfaced the fourth: an MPP plugin registers its decoders unconditionally but
*probes MPP* before registering its encoders. With /dev/mpp_service at 0600
root:root the probe fails silently. So mpi_enc_test wrote an empty file and
exited 0; Radxa's deb looked decode-only; a third-party deb installed and still
showed no mpph264enc; and this repository's own CI build lists only mppjpegdec
and mppvideodec, because a container has no such node either. That last one is
expected, not a failure, and the README now says so where somebody reading a
green build log will find it.

The reasons to build that survive: no libx11-6, since rkximage and kmssrc are
disabled; a pin we control, recorded in every release; and this repository has
to exist for gst-plugins-rs regardless, which no archive packages at all — so
the MPP plugin riding along costs almost nothing.

Assisted-by: Claude:claude-opus-5[1m]

README.md

@@ -7,7 +7,7 @@ Two plugins, for two unrelated reasons. Neither is packaged anywhere we can inst
 
 | plugin | provides | why it is here |
 |---|---|---|
-| `libgstrockchipmpp.so` | `mpph264enc`, `mpph265enc`, `mppjpegenc`, `mppvp8enc`, `mppvideodec`, `mppjpegdec` | Debian ships no Rockchip encoder in any suite, and Radxa's `gstreamer1.0-rockchip1_1.14-4` is **decode-only** — measured on a Zero 3W: `mppvideodec` and `mppjpegdec`, nothing else. 1.14.4 predates the encoders. |
+| `libgstrockchipmpp.so` | `mpph264enc`, `mpph265enc`, `mppjpegenc`, `mppvp8enc`, `mppvideodec`, `mppjpegdec` | Debian ships no Rockchip encoder in any suite. Radxa's own `gstreamer1.0-rockchip1_1.14-4` does contain them, so this build is about the pin, dropping `libx11-6`, and riding along with the plugin below — see [below](#the-permission-trap-that-hid-all-of-this). |
 | `libgstrswebrtc.so`, `libgstrsrtp.so` | `webrtcsink`, `webrtcsrc`, `rsrtp*` | `gstreamer1.0-plugins-rs` does not exist in **any** Debian suite — not trixie, backports, sid or experimental. |
 
 `webrtcbin` is **not** here: it comes from `gstreamer1.0-plugins-bad` in Debian and needs no
@@ -34,6 +34,24 @@ Building rather than taking a third-party binary also buys one concrete thing be
 headless robot has no use for either, and they are why the prebuilt Radxa deb depends on
 `libx11-6`.
 
+## The permission trap that hid all of this
+
+`/dev/mpp_service` arrives as `0600 root:root`, and **an MPP GStreamer plugin registers its
+decoders unconditionally but probes MPP before registering its encoders.** With the node
+unreadable the probe fails and the encoders are silently omitted — no error, no log line.
+
+That one cause produced four separate misleading results while this was being worked out:
+
+- `mpi_enc_test` wrote an empty file and **exited 0**.
+- Radxa's `1.14-4` looked decode-only. It is not; `strings` on its `.so` lists every encoder.
+- A third-party `1.14-8` deb installed cleanly and still showed no `mpph264enc`.
+- This repository's own CI build shows only `mppjpegdec` and `mppvideodec`, because a container
+  has no `/dev/mpp_service` either. **That is expected, not a failed build.**
+
+So: a plugin that lists only decoders is evidence about the *device node*, not about the plugin. A
+non-root process needs a udev rule giving the node a group — mode `0660`, group `video` — and only
+then does `gst-inspect-1.0 mpph264enc` mean anything.
+
 ## Consuming a release
 
 ```
@@ -60,10 +78,9 @@ The plugins link against libraries a robot needs installed:
   [`pins.env`](pins.env). Not in Debian.
 - `libgstreamer1.0-0`, `libgstreamer-plugins-base1.0-0`, `libglib2.0-0`, `libdrm2` — Debian.
 
-`mpph264enc` also needs **read/write access to `/dev/mpp_service`**, which arrives as `0600
+`mpph264enc` also needs **read/write access to `/dev/mpp_service`** — see
-root:root`. The failure that causes is silent in two different ways: `mpi_enc_test` writes an empty
+[the permission trap](#the-permission-trap-that-hid-all-of-this), which is the single most
-file and exits 0, and this plugin registers its *decoders* while omitting the *encoders*, because
+misleading thing about this stack.
-registration probes MPP. A non-root process needs a udev rule giving the node a group.
 
 ## Bumping a pin
 

pins.env

@@ -11,9 +11,16 @@
 # `rockchip-linux/gstreamer-rockchip` — the homepage both Radxa's and every third-party deb name
 # — is a 404 now. `JeffyCN/mirrors` is the live mirror, same maintainer (Jeffy Chen).
 #
-# Why build it at all: Debian has no Rockchip encoder in any suite, and Radxa's
+# Why build it at all: Debian has no Rockchip encoder in any suite. Radxa publish a
-# `gstreamer1.0-rockchip1_1.14-4` is **decode-only** — measured on a Zero 3W, it provides
+# `gstreamer1.0-rockchip1_1.14-4` that **does** contain every encoder — `strings` on its .so lists
-# `mppvideodec` and `mppjpegdec` and nothing else. 1.14.4 predates the encoders.
+# `mpph264enc` and the rest — so "theirs is decode-only" is not the reason, and an earlier version
+# of this comment claiming so was wrong. On a board it *appears* decode-only, and the cause is the
+# permission trap below, not the build.
+#
+# The reasons that survive: this build drops `rkximage` and `kmssrc` and so needs no `libx11-6`;
+# the pin is one we control and a release records it; and this repository has to exist for
+# `gst-plugins-rs` regardless, which no archive packages at all — so the MPP plugin riding along
+# costs almost nothing.
 # **Not the branch tip, and this is the interesting part of the pin.**
 #
 # Branch HEAD (dcbcd645, 2026-05-21) does not compile against the MPP Radxa ships. Commit