From 8ee937e56d285195038a1aedf5e7daa4643731bb Mon Sep 17 00:00:00 2001 From: Thore Cimbal Date: Wed, 29 Jul 2026 07:33:03 +0200 Subject: [PATCH] docs: document VP9/AV1 test outcome and revert (Issue #11) --- docs/deployment-guides/04-element-customization.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/docs/deployment-guides/04-element-customization.md b/docs/deployment-guides/04-element-customization.md index c84bd57..bbe4474 100644 --- a/docs/deployment-guides/04-element-customization.md +++ b/docs/deployment-guides/04-element-customization.md @@ -90,6 +90,15 @@ hinter einem "Developer Mode"-Schalter versteckt — in unseren Fork in den regu beschränkt (VP8/H.264/H.265 — live per SFU-Logs verifiziert; VP9/AV1 wurden von der SFU ohnehin nur transparent auf VP8 zurückgefallen, boten aber keinen echten Effekt). +**Update 2026-07-29 — VP9/AV1 live getestet, zurückgerollt (Issue #11)**: SFU-seitige +Codec-Freigabe (`matrixRTC.sfu.additional`) + Dropdown-Wiederfreischaltung getestet. Trotz +echter Auswahl auf Safari und Desktop-Firefox (mit frischem Call-Rejoin) fiel VP9 immer +automatisch auf VP8 zurück. SFU-Logs zeigten: die eigene Codec-Freigabe kam serverseitig nie +in der aktiven `enabledPublishCodecs`-Liste an — Ursache nicht abschließend geklärt (möglicher +Zusammenhang: `sfu.additional` ersetzt die Chart-eigene `config-overrides.yaml` im Config-Merge, +statt sie zu ergänzen). Komplett zurückgerollt auf den bekannt funktionierenden 3-Codec-Stand. +Details: Issue #11. + ## Dateien | Datei | Ort |