Patch webrtcsink to put no converter in front of mpph264enc

`make_converter_for_video_caps` builds the chain webrtcsink inserts ahead of an
encoder it selected, special-casing hardware it knows — NVMM, D3D11, CUDA, GL,
VA, and on main also v4l2h264enc — and falling back to software
`videoconvert ! videoscale` for anything else. Rockchip's MPP encoder takes
NV12, I420, YUY2 and more directly and converts on the SoC's 2D accelerator, so
the fallback adds a full CPU pass over every frame to do work the hardware was
going to do anyway, on the four A55s robotd's 50 Hz loop shares.

The reason this matters more than CPU: the robot currently avoids the whole
question by pre-encoding and handing webrtcsink finished H.264. That works, and
it means webrtcsink cannot reach the encoder — so congestion control cannot
adapt the bitrate to the link, and a peer's PLI cannot produce a keyframe, which
leaves a viewer that lost one broken until the next periodic GOP. Letting
webrtcsink own the encoder fixes both. This patch is what makes that affordable.

**This repository is no longer patch-free, and says so.** MPL-2.0 asks that
modifications be identifiable, so the README states it, patches/README.md gives
each patch's reasoning, and build.sh records every applied patch in the release
MANIFEST beside the upstream ref. `git apply --check` runs first, so a patch that
stops applying fails the build naming itself rather than yielding a plugin
quietly missing the change it was carried for.

The trade-off is written down rather than glossed: without videoscale the bin
cannot resize, so the negotiated resolution must be one the source produces.
True on this robot, which pins its caps upstream of the tee — and the reason
upstream may want RGA-backed scaling instead of nothing before taking it. The
v4l2h264enc arm on main is the same shape for another hardware encoder, so the
precedent exists, and if it lands this file is deleted at the next bump.

Verified to apply cleanly against a real 0.15.3 checkout.

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

README.md

@@ -8,7 +8,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. 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. |
+| `libgstrswebrtc.so`, `libgstrsrtp.so` | `webrtcsink`, `webrtcsrc`, `rsrtp*` | `gstreamer1.0-plugins-rs` does not exist in **any** Debian suite — not trixie, backports, sid or experimental. Patched; see [`patches/`](patches/). |
 
 `webrtcbin` is **not** here: it comes from `gstreamer1.0-plugins-bad` in Debian and needs no
 build.
@@ -104,8 +104,18 @@ These are binaries built from other people's source, so where that source is mat
   [the upstream repository](https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs) at the tag in
   `pins.env`.
 
-Nothing here is modified — no patches, no forks. Each release's `MANIFEST` names the repository
-and the exact ref per plugin, which is both the licence answer and the reason a media bug found on
+**`gst-plugins-rs` is patched, and that matters for more than tidiness.** MPL-2.0 asks that
+modifications be identifiable, so it is stated here, listed in [`patches/`](patches/) with what
+each one buys and how it ends, and recorded in every release's `MANIFEST` — a release names the
+upstream ref *and* every patch applied over it. `gstreamer-rockchip` is unmodified.
+
+There is one patch today: `webrtcsink` inserts a software `videoconvert ! videoscale` in front of
+any encoder it does not recognise, and `mpph264enc` converts on the SoC's 2D accelerator instead —
+so a CPU pass over every frame is added to work the hardware was going to do anyway, on cores the
+robot's control loop shares. [`patches/README.md`](patches/README.md) has the reasoning, the
+trade-off it accepts, and the route upstream that would delete it.
+
+Together the ref and the patch list are both the licence answer and the reason a media bug found on
 a robot can be traced to a specific build.
 
 This repository's own build scripts are Apache-2.0, matching the daemon.