fe51a2aa55
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]
70 lines
4.0 KiB
Bash
70 lines
4.0 KiB
Bash
# What this repo builds, and from exactly where.
|
|
#
|
|
# One file, sourced by `scripts/build.sh` and read by the release workflow, so a bump is one
|
|
# commit and the manifest in a release can never disagree with what was built.
|
|
#
|
|
# Pins are commits or tags, never branches. A plugin whose version nobody can name is what makes
|
|
# a media bug unreproducible, and both of these upstreams move.
|
|
|
|
# ── Rockchip MPP: mpph264enc, mpph265enc, mppjpegenc, mppvp8enc, mppvideodec, mppjpegdec ──
|
|
#
|
|
# `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. 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
|
|
# 666203a8 — "mppjpegdec: Get the required size from mpp_sys_cfg", 2026-03-06 — started using
|
|
# `MppSysCfg` and `mpp_sys_cfg_*`, which do not exist in librockchip-mpp 1.5.0-1:
|
|
#
|
|
# gstmppjpegdec.c:219:3: error: unknown type name 'MppSysCfg'
|
|
# gstmppjpegdec.c:235:7: error: implicit declaration of function 'mpp_sys_cfg_get'
|
|
#
|
|
# So this is 1ceaf42c, its parent. Everything else in the plugin builds fine against 1.5.0 —
|
|
# `gstmppenc.c`, `gstmppjpegenc.c`, `gstmppvideodec.c` all compiled; the failure is confined to
|
|
# the JPEG *decoder*, which nothing here needs.
|
|
#
|
|
# What pinning behind it costs is three commits, and none of them matter to us: a `mppvideodec`
|
|
# input-packet-leak fix (a decoder, not the encode path), an `rkximage` aspect-ratio fix (a sink
|
|
# this build disables), and the breaking change itself.
|
|
#
|
|
# The alternative is building a newer librockchip-mpp too — `JeffyCN/mirrors` has `mpp` and
|
|
# `mpp-dev` branches — and then shipping that to the robot as well. Rejected for now: 1.5.0-1 is
|
|
# the version hardware H.264 was *proven* on (`mpi_enc_test`, 720p, a bitstream that decodes
|
|
# clean), and replacing it would invalidate that proof to gain a decoder fix we do not use.
|
|
GST_ROCKCHIP_REPO=https://github.com/JeffyCN/mirrors.git
|
|
GST_ROCKCHIP_BRANCH=gstreamer-rockchip
|
|
GST_ROCKCHIP_REF=1ceaf42ca3189c2c0ca917181cf3cb6db8c4df45
|
|
|
|
# ── gst-plugins-rs: webrtcsink, webrtcsrc, and the rtp sibling the same stack wants ──
|
|
#
|
|
# Why build it: `gstreamer1.0-plugins-rs` does not exist in **any** Debian suite — not trixie,
|
|
# not backports, not sid, not experimental.
|
|
#
|
|
# 0.15.3 rather than the 0.14.5 that Pollen's reachy_mini SDK documents. 0.14.5 is the floor that
|
|
# matters — the tags below it miss a `webrtcsink` deadlock fix between remote description and ICE
|
|
# handling, which presents as a client spinning forever on "connecting" — and 0.15.3 is simply
|
|
# newer than it. Both declare a GStreamer `v1_22` feature floor, and the robot runs 1.26.2, so
|
|
# the newer series costs nothing.
|
|
GST_PLUGINS_RS_REPO=https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs.git
|
|
GST_PLUGINS_RS_REF=0.15.3
|
|
|
|
# ── Rockchip userspace, from Radxa's pool ──
|
|
#
|
|
# Not in Debian either. These are the *build* dependencies of the MPP plugin; the runtime halves
|
|
# of the same versions are what a robot installs. A header/library version mismatch here is a
|
|
# plugin that builds and then misbehaves, so both sides come from one place.
|
|
RADXA_POOL=https://radxa-repo.github.io/bullseye/pool/main
|
|
MPP_VERSION=1.5.0-1
|
|
RGA_VERSION=2.2.0-1
|