sorb/axion1337.chat-gitops
1
0
Fork 0
Code Issues Pull Requests Packages Projects 1 Releases 24 Wiki Activity

[MEDIUM] Element Call: VP9 codec retry #11

New Issue
Closed
opened 2026-07-28 14:31:47 +00:00 by sorb · 2 comments
sorb commented 2026-07-28 14:31:47 +00:00
Owner
Copy Link
Copy Source

Retry video_codec: vp9 for better compression efficiency than the current H.264. First attempt (2026-07-28) broke calls entirely (no audio/video transmitted). Likely cause: LiveKit uses SVC for vp9/av1 instead of classic simulcast, but the threadnet-call fork's buildPublishOptions() (src/livekit/options.ts) always builds simulcast-shaped videoSimulcastLayers regardless of codec. Needs a code fix (branch SVC vs simulcast config by codec) before retrying, plus a real browser-console repro if it fails again. H.264 is live and working well in the meantime (7/8 tracks native, 1 clean VP8 fallback).

Retry `video_codec: vp9` for better compression efficiency than the current H.264. First attempt (2026-07-28) broke calls entirely (no audio/video transmitted). Likely cause: LiveKit uses SVC for vp9/av1 instead of classic simulcast, but the threadnet-call fork's `buildPublishOptions()` (`src/livekit/options.ts`) always builds simulcast-shaped `videoSimulcastLayers` regardless of codec. Needs a code fix (branch SVC vs simulcast config by codec) before retrying, plus a real browser-console repro if it fails again. H.264 is live and working well in the meantime (7/8 tracks native, 1 clean VP8 fallback).
sorb added the priority:mediumarea:element labels 2026-07-28 14:31:47 +00:00
sorb commented 2026-07-29 05:32:08 +00:00
Author
Owner
Copy Link
Copy Source

Update 2026-07-29 — echter Live-Test durchgeführt, wieder zurückgerollt

Test-Setup: room.enabled_codecs am SFU per matrixRTC.sfu.additional um video/VP9 und
video/AV1 erweitert (alles Bestehende beibehalten), VP9/AV1 im Codec-Dropdown (Video-Tab)
wieder freigeschaltet, als separates Test-Image (v0.2.7-elementcall-vp9av1test) gepatcht und
deployed - nicht als neuer Default, nur wählbar.

Ergebnis: VP9 wurde in keinem der drei echten Testanrufe tatsächlich negotiated - trotz
expliziter Auswahl im Dropdown, sowohl auf Safari (macOS + iOS) als auch auf echtem Desktop-
Firefox mit frischem Call-Rejoin (Codec-Einstellung wird nur beim Room-Join gelesen,
ConnectionFactory.ts generateRoomOption(), nicht bei laufendem Call/Kamera-Toggle - das
haben wir dabei auch geklärt). In allen Fällen fiel der Client automatisch und ohne Fehler auf
den backupCodec (VP8) zurück.

Konkreter Beleg aus den SFU-Logs (Livekit loggt bei einem Fallback-Event die tatsächlich
aktive Codec-Liste):

"falling back to alternative video codec" codec=video/vp9 altCodec=video/VP8
enabledPublishCodecs: [VP8, H264, H265, rtx, PCMU, PCMA, opus, red]

Diese vom SFU selbst gemeldete Liste enthielt kein VP9/AV1 - obwohl unsere Config-Änderung
zu dem Zeitpunkt längst deployed war und derselbe SFU-Pod seit dem Config-Rollout durchgehend
lief (kein Neustart dazwischen). Unsere Server-seitige Freigabe ist also nie in der aktiven
Codec-Liste angekommen.

Mögliche Ursache (nicht abschließend verifiziert): Sobald matrixRTC.sfu.additional gesetzt
ist, ändern sich die Argumente des render-config-sfu-Init-Containers von
[config-underrides.yaml, config-overrides.yaml] auf
[config-underrides.yaml, <additional-secret>] - die reguläre, vom Chart generierte
config-overrides.yaml (mit Port/Logging/RTC-Defaults) wird dabei ersetzt statt gemergt.
Das allein erklärt noch nicht, warum unser eigener enabled_codecs-Eintrag ebenfalls nicht
ankam, ist aber ein echtes, bisher unbekanntes Verhalten des ESS-Charts, das bei künftigen
additional-Konfigurationen an SFU/Synapse/etc. relevant sein könnte. Die ursprünglich
vermutete Simulcast/SVC-Client-Ursache (buildPublishOptions() setzt immer simulcast: true)
ist damit nicht bewiesen - die Server-Config kam schlicht nie an, ein Test der Simulcast-
Theorie wäre erst nach einem funktionierenden Config-Merge sinnvoll.

Zusätzlich geprüft, was sonst noch an Codecs tatsächlich lief (Antwort auf die Frage, ob
H.264/H.265/AV1 je außerhalb von VP9 verwendet wurden):

  • H.265: ja, echt negotiated und gepublisht (ein Call, Safari/macOS)
  • VP8: mehrfach bestätigt (Standard-Fallback)
  • H.264: nie als tatsächlich gepublishter Codec beobachtet in dieser Testreihe (nur in der
    Allow-Liste erwähnt) - vermutlich unproblematisch (breiteste Encoder-Unterstützung aller
    Browser), aber ohne direkten Log-Beleg aus diesem Test
  • AV1: gar nicht getestet (Test endete beim VP9-Fehlschlag)

Revertiert: SFU-Codec-Freigabe entfernt, Dropdown wieder auf VP8/H.264/H.265 beschränkt,
Image-Tag zurück auf v0.2.6-elementcall-realcodecs. Sicherer, bekannt funktionierender Stand
wiederhergestellt.

Für einen erneuten Versuch nötig: erst klären, warum sfu.additional die Codec-Liste
nicht verändert hat (Chart-Doku/Sourcen genauer prüfen oder Livekit-Config direkt im laufenden
Pod inspizieren - war in dieser Sitzung durch Secret-Zugriffsbeschränkungen nicht möglich),
danach erst die Simulcast/SVC-Frage erneut betrachten. Bleibt offen, bis dieser Vorverständnis-
Schritt geklärt ist.

**Update 2026-07-29 — echter Live-Test durchgeführt, wieder zurückgerollt** Test-Setup: `room.enabled_codecs` am SFU per `matrixRTC.sfu.additional` um `video/VP9` und `video/AV1` erweitert (alles Bestehende beibehalten), VP9/AV1 im Codec-Dropdown (Video-Tab) wieder freigeschaltet, als separates Test-Image (`v0.2.7-elementcall-vp9av1test`) gepatcht und deployed - nicht als neuer Default, nur wählbar. **Ergebnis: VP9 wurde in keinem der drei echten Testanrufe tatsächlich negotiated** - trotz expliziter Auswahl im Dropdown, sowohl auf Safari (macOS + iOS) als auch auf echtem Desktop- Firefox mit frischem Call-Rejoin (Codec-Einstellung wird nur beim Room-Join gelesen, `ConnectionFactory.ts` `generateRoomOption()`, nicht bei laufendem Call/Kamera-Toggle - das haben wir dabei auch geklärt). In allen Fällen fiel der Client automatisch und ohne Fehler auf den `backupCodec` (VP8) zurück. **Konkreter Beleg aus den SFU-Logs** (Livekit loggt bei einem Fallback-Event die tatsächlich aktive Codec-Liste): ``` "falling back to alternative video codec" codec=video/vp9 altCodec=video/VP8 enabledPublishCodecs: [VP8, H264, H265, rtx, PCMU, PCMA, opus, red] ``` Diese vom SFU selbst gemeldete Liste enthielt **kein VP9/AV1** - obwohl unsere Config-Änderung zu dem Zeitpunkt längst deployed war und derselbe SFU-Pod seit dem Config-Rollout durchgehend lief (kein Neustart dazwischen). Unsere Server-seitige Freigabe ist also nie in der aktiven Codec-Liste angekommen. Mögliche Ursache (nicht abschließend verifiziert): Sobald `matrixRTC.sfu.additional` gesetzt ist, ändern sich die Argumente des `render-config-sfu`-Init-Containers von `[config-underrides.yaml, config-overrides.yaml]` auf `[config-underrides.yaml, <additional-secret>]` - die reguläre, vom Chart generierte `config-overrides.yaml` (mit Port/Logging/RTC-Defaults) wird dabei **ersetzt statt gemergt**. Das allein erklärt noch nicht, warum unser eigener `enabled_codecs`-Eintrag ebenfalls nicht ankam, ist aber ein echtes, bisher unbekanntes Verhalten des ESS-Charts, das bei künftigen `additional`-Konfigurationen an SFU/Synapse/etc. relevant sein könnte. Die ursprünglich vermutete Simulcast/SVC-Client-Ursache (`buildPublishOptions()` setzt immer `simulcast: true`) ist damit **nicht bewiesen** - die Server-Config kam schlicht nie an, ein Test der Simulcast- Theorie wäre erst nach einem funktionierenden Config-Merge sinnvoll. **Zusätzlich geprüft, was sonst noch an Codecs tatsächlich lief** (Antwort auf die Frage, ob H.264/H.265/AV1 je außerhalb von VP9 verwendet wurden): - H.265: ja, echt negotiated und gepublisht (ein Call, Safari/macOS) - VP8: mehrfach bestätigt (Standard-Fallback) - H.264: nie als tatsächlich gepublishter Codec beobachtet in dieser Testreihe (nur in der Allow-Liste erwähnt) - vermutlich unproblematisch (breiteste Encoder-Unterstützung aller Browser), aber ohne direkten Log-Beleg aus diesem Test - AV1: gar nicht getestet (Test endete beim VP9-Fehlschlag) **Revertiert**: SFU-Codec-Freigabe entfernt, Dropdown wieder auf VP8/H.264/H.265 beschränkt, Image-Tag zurück auf `v0.2.6-elementcall-realcodecs`. Sicherer, bekannt funktionierender Stand wiederhergestellt. **Für einen erneuten Versuch nötig**: erst klären, warum `sfu.additional` die Codec-Liste nicht verändert hat (Chart-Doku/Sourcen genauer prüfen oder Livekit-Config direkt im laufenden Pod inspizieren - war in dieser Sitzung durch Secret-Zugriffsbeschränkungen nicht möglich), danach erst die Simulcast/SVC-Frage erneut betrachten. Bleibt offen, bis dieser Vorverständnis- Schritt geklärt ist.
sorb commented 2026-08-01 14:25:58 +00:00
Author
Owner
Copy Link
Copy Source

Migriert nach git.lab: axion1337.chat/axion1337.chat-gitops#11 (nur im Lab bzw. via VPN erreichbar — das Lab ist seit 2026-08-01 die Quelle der Wahrheit, siehe gitops#48). Weiterarbeit dort; dieses Gitea-Issue bleibt als Verweis stehen.

**Migriert nach git.lab**: [axion1337.chat/axion1337.chat-gitops#11](https://git.lab/axion1337.chat/axion1337.chat-gitops/-/issues/11) (nur im Lab bzw. via VPN erreichbar — das Lab ist seit 2026-08-01 die Quelle der Wahrheit, siehe gitops#48). Weiterarbeit dort; dieses Gitea-Issue bleibt als Verweis stehen.
sorb closed this issue 2026-08-01 14:25:58 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area:authentik
Authentik Identity Provider
 area:database
Database and backups
 area:element
Element and UI
 area:infrastructure
K3S and infrastructure
 area:security
Security hardening
 priority:critical
Critical - This week
 priority:high
High - 1-2 weeks
 priority:low
Low - nice to have
 priority:medium
Medium - ~1 month
No labels area:element priority:medium
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
sorb (ScrublordMcBad)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sorb/axion1337.chat-gitops#11