# 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