microduck/microduck-gst-plugins
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
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]
This commit is contained in:
Pierre Rouanet 2026-08-24 16:51:22 +02:00
parent f1915a218a
commit fe51a2aa55
2 changed files with 32 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
README.md
View File

@ -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
root:root`. The failure that causes is silent in two different ways: `mpi_enc_test` writes an empty
file and exits 0, and this plugin registers its *decoders* while omitting the *encoders*, because
registration probes MPP. A non-root process needs a udev rule giving the node a group.
`mpph264enc` also needs **read/write access to `/dev/mpp_service`** — see
[the permission trap](#the-permission-trap-that-hid-all-of-this), which is the single most
misleading thing about this stack.
## Bumping a pin

13
pins.env
View File

@ -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
# `gstreamer1.0-rockchip1_1.14-4` is **decode-only** — measured on a Zero 3W, it provides
# `mppvideodec` and `mppjpegdec` and nothing else. 1.14.4 predates the encoders.
# Why build it at all: Debian has no Rockchip encoder in any suite. Radxa publish a
# `gstreamer1.0-rockchip1_1.14-4` that **does** contain every encoder — `strings` on its .so lists
# `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