- Ya
- 19 Agosti 2026, 02:22 UTC
- Mwandishi
- Kamo
- Ahadi ya
- 8193920
MediaMTX serves live channels over HLS, WebRTC, RTSP and RTMP, and loops the marketing reel as an always-available channel via alwaysAvailableFile — no ffmpeg sidecar, and any RTMP/RTSP publisher transparently takes the channel over and reverts to the reel on disconnect. The homepage video itself is NOT served through MediaMTX. MediaMTX is a live server with no VOD mode; looping a file into a live channel would drop every visitor into the middle of the reel instead of the first frame. So hero-hls-encode-job builds a 720p/540p/360p HLS ladder from the same MP4 and publishes it to MinIO, routed as /vod/ on the streaming host. Measured against the 31.8 MB single-bitrate original: 18.8 MB at 720p (SSIM 0.989), 9.8 MB at 540p, 5.4 MB at 360p, in ~4s segments the player fetches only while watching. The job is ETag-idempotent, so it no-ops on every deploy that is not a video swap, and it also publishes public/kamo12-poster.jpg — referenced by the homepage since it was written, but a 404 until now. Routes live on stream.* and theme.*: theme.<domain> already has DNS and a certificate for every tenant, so this works today, and the stream.* form activates on its own once a DNS record exists. The WebRTC route matches **************** rather than a prefix deliberately — MediaMTX serves WHIP on the same port, and a prefix match would publish an unauthenticated ingest endpoint to the internet. This touches .forgejo/, which forces FULL=true and a full-cluster reconcile. Audited first per the documented procedure: kubectl diff over all 112 apply targets is clean on 104; five are these new files, two are the nats/mail bootstrap Jobs the workflow deliberately deletes and re-applies, and mail/mysql-permissions-job.yaml fails as an immutable completed Job, which the workflow already tolerates with `|| echo`. Every kubectl delete target was confirmed absent.