Thore CimbalandClaude Fable 5
8fb630cfb3
Registry-Entscheidung evidenzbasiert: das Package ist pnpm-Dependency von ThreadNet-Webs apps/web, der Lockfile pinnt die Tarball-URL auf rohana - Registry bleibt dort. Publish-Auth ueber CI-Variable GITEA_NPM_TOKEN statt lokaler Klartext-.npmrc. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
69 lines
4.0 KiB
Markdown
69 lines
4.0 KiB
Markdown
# threadnet-call: Fork-Anpassungen für axion1337.chat
|
|
|
|
Dieses Dokument beschreibt alles, was dieser Fork gegenüber Upstream Element Call ändert. Die
|
|
übrigen Dateien in `docs/` sind unverändertes Upstream-Material.
|
|
|
|
## 1. Warum Fork von `emmick4/element-call` (Branch `livekit`)?
|
|
|
|
Nicht direkt von `element-hq/element-call` geforkt, sondern von `emmick4/element-call`s
|
|
`livekit`-Branch, weil dieser bereits den noch nicht upstream gemergten PR
|
|
[element-hq/element-call#3736](https://github.com/element-hq/element-call/pull/3736)
|
|
enthält - config-driven `media_quality`. Ohne diesen PR wäre eigener Custom-Code nötig gewesen,
|
|
um Video-/Audio-Qualitätslimits pro Deployment konfigurierbar zu machen.
|
|
|
|
## 2. media_quality-Defaults
|
|
|
|
Konfiguriert in `vite-embedded.config.ts` (im `generateFile`-Plugin-Aufruf, der
|
|
`media_quality` in die zur Build-Zeit gebackene `config.json` des Embedded-Packages schreibt):
|
|
|
|
- Kamera: **1440p / 60fps / ~8 Mbps** (`video.max_resolution/max_framerate/max_bitrate`)
|
|
- Screen-Share: **1440p / 30fps / ~6 Mbps**
|
|
- 720p-Zwischen-Simulcast-Layer (`video.simulcast_layers`) - ohne diesen fiel die Übertragung
|
|
bei kleinsten Netzwerkschwankungen direkt von 1440p auf blockiges 360p
|
|
- `video_codec: "h264"` (siehe Incident unten für die Begründung)
|
|
|
|
Das sind Startwerte, keine harten Limits - Nutzer können in den Call-Settings weiter hochdrehen.
|
|
|
|
## 3. VP9-Incident (2026-07-28) — ⚠️ nicht ohne Browser-Repro erneut versuchen
|
|
|
|
Erster Versuch setzte `video_codec: "vp9"` (Commit `83db5224`). Das hat Calls **live komplett
|
|
kaputt gemacht** (kein Bild/Ton), obwohl die LiveKit-SFU-Server-Logs den
|
|
Codec-Regression-Fallback auf VP8 als scheinbar erfolgreich zeigten. Sofort zurückgerollt
|
|
(Commit `f845d81e`). Vermutete Ursache: LiveKit nutzt für VP9/AV1 SVC statt klassischem
|
|
Simulcast, aber `buildPublishOptions()` in diesem Fork setzt immer Simulcast-Layer - ein
|
|
echter Code-Fix wäre nötig, um das aufzulösen. **Root Cause nie abschließend isoliert** (hätte
|
|
einen Browser-Konsolen-/WebRTC-Internals-Repro gebraucht). Danach auf 720p-Zwischen-Layer +
|
|
`h264` (klassisches Simulcast, kein SVC-Risiko, oft hardwarebeschleunigt v.a. auf iOS)
|
|
umgestellt - live verifiziert (7/8 Tracks nativ H.264, 1 sauberer VP8-Fallback).
|
|
|
|
**Nicht erneut versuchen, ohne vorher einen echten Browser-Repro zu haben.**
|
|
|
|
## 4. npm-Publish zu Gitea (`@sorb/threadnet-call-embedded`)
|
|
|
|
Das Embedded-Package (`embedded/web/package.json`, aktuell `0.19.2-threadnet.5`) wird zu
|
|
Gitea's npm-Registry veröffentlicht (`https://rohana.axion1337.de/api/packages/sorb/npm/`,
|
|
Scope `@sorb`). Der obere Versionierungs-Track hier (`0.19.2-threadnet.N`) ist unabhängig von
|
|
den Docker-Image-Tags, unter denen das fertig gebaute Widget im gitops-Repo deployt wird (z.B.
|
|
`v0.2.3-elementcall-h264` als `threadnet-web`-Image-Tag) - zwei getrennte Versionsschemata für
|
|
zwei verschiedene Artefakte (npm-Package vs. Docker-Image).
|
|
|
|
Der aktuelle Publish-Vorgang läuft manuell/lokal - das committete
|
|
`.github/workflows/publish-embedded-packages.yaml` zielt noch auf `registry.npmjs.org`/
|
|
`@element-hq`-Scope (Upstream-Konfiguration, nicht an die Gitea-Registry angepasst). Registry-
|
|
Zugangsdaten liegen in einer lokalen, **nicht committeten** `.npmrc` - nicht Teil dieses Repos.
|
|
|
|
## 5. Bewusst keine Server-seitige ML-Rauschunterdrückung
|
|
|
|
Nur der client-seitige WebRTC-Standardtoggle (Echo/Noise/Gain-Suppression, aus derselben
|
|
Upstream-PR-Linie) wurde übernommen. Bewusst **kein** LiveKit-Agents-basiertes Server-seitiges
|
|
ML-Noise-Cancellation (z.B. selbst gehostetes DTLN/RNNoise) - LiveKits eigene Dokumentation
|
|
beschreibt diesen Baustein als für AI-Voice-Agents gedacht, nicht für Mensch-zu-Mensch-Calls
|
|
(kein unterstützter Weg, bereinigtes Audio an andere Teilnehmer weiterzuleiten).
|
|
|
|
## Repo-Topologie (seit 2026-07-31)
|
|
|
|
**Kanonisch ist `git.lab/axion1337.chat/threadnet-call`** (Homelab-GitLab) — die Kopie auf
|
|
`rohana.axion1337.de/sorb/threadnet-call` ist ein automatischer **Push-Mirror** (Lesekopie,
|
|
Issues, npm-Registry). **Niemals direkt nach rohana pushen** — der Mirror überschreibt
|
|
divergente Stände.
|