Video-Wiedergabe auf Android: lange Wartezeit beim Start — ein bekanntes Element-Problem
Mein selbst gehosteter Matrix-Server läuft stabil und zuverlässig. Beim Testen von Audio- und Videonachrichten zwischen iPhone und Android (direkt über Matrix, ohne Bridge) ist mir aber eine auffällige Eigenheit aufgefallen, die es wert ist, festgehalten zu werden — nicht als Fehler in der eigenen Installation, sondern als bekannte, extern dokumentierte Einschränkung in Element selbst.
Video: Matrix Server Setup Nachtrag
Sprache: 🇩🇪|🇬🇧
☝️ Benutze YouTube Untertitel für alle Sprachen.
Der Test
Nachrichten wurden direkt zwischen einem iPhone und einem Android-Gerät (Galaxy A30) ausgetauscht, in beide Richtungen:
- Sprachnachrichten (Audio): funktionieren in beide Richtungen einwandfrei und spielen sofort ab, unabhängig davon, welches Gerät gesendet oder empfangen hat.
- Videonachrichten: funktionieren inhaltlich (Datei kommt vollständig und unbeschädigt an), zeigen aber ein klares Muster bei der Wiedergabe.
Das Muster bei Videos
- Ein auf dem iPhone aufgenommenes und versendetes Video spielt beim Empfänger sofort ab.
- Ein auf Android empfangenes Video (bzw. in Element Web abgespielt) startet die Wiedergabe erst, nachdem die komplette Datei heruntergeladen wurde — bei einer 30-Sekunden-Aufnahme etwa vier Minuten Wartezeit, bevor überhaupt etwas zu sehen ist.
- In Element Web erscheint bei denselben Videos zunächst ein “nicht unterstützt”-Symbol, das nach einer Weile von selbst verschwindet, sobald genug der Datei geladen ist.
Die Ursache
Die Recherche in der Community führte zu einem offenen GitHub-Issue #6436 im offiziellen Repository von Element X Android. Ein anderer Selbsthoster mit einem völlig anderen Server-Stack beschreibt dort exakt dasselbe Verhalten: Videos lassen sich erst nach vollständigem Download ansehen, und auch in der Web-Version verschwindet die anfängliche Fehlermeldung erst nach ein bis zwei Minuten von selbst.
Der Kern: Element implementiert aktuell kein echtes progressives Streaming beim Abspielen von Videos — der Client lädt die Datei intern vollständig, bevor die Wiedergabe beginnt. Das tritt unabhängig vom Server dahinter auf und lässt sich serverseitig nicht beheben.
Fazit
Das eigene Setup ist nicht die Ursache — es handelt sich um eine bekannte, aktuell offene Einschränkung im Element-Client selbst. Wer selbst betroffen ist: Issue #6436 auf GitHub abonnieren, dann kommt automatisch eine Benachrichtigung, sobald sich dort etwas tut.
Element WEB unter Safari und Chrome
Kurz und direkt: Safaris eingebauter Video-Player unterstützt grundsätzlich deutlich weniger Formate/Codecs als Chrome — das ist eine reine Browser-Eigenschaft, kein Matrix- oder Element-Fehler.
Chrome basiert auf einer eigenen, sehr breiten Medien-Engine und spielt praktisch alles ab (H.264, VP8/VP9, WebM-Container, viele Profile/Varianten). Safari nutzt stattdessen Apples systemeigenes Video-Framework, das deutlich wählerischer ist — es lehnt bestimmte Container-Varianten, Zusatz-Datenspuren (wie die Metadaten-Spuren, die wir in den iPhone-Videos gesehen hatten) oder bestimmte Codec-Profile grundsätzlich ab, während Chrome genau dieselbe Datei anstandslos abspielt.
Das bestätigt sich auch extern: Element selbst hat exakt dieses Symptom (Video spielt in Chrome, nicht in Safari) bereits als GitHub-Issue vorliegen — und bewusst als „nicht geplant“ geschlossen, weil es an der Browser-Ebene liegt, nicht an ihrem Code.
Kurz: Es gibt keine Einstellung bei uns oder bei Element, die das behebt — es ist eine grundsätzliche Einschränkung von Safari selbst gegenüber bestimmten Videoformaten.
Link zur Unterstützung / Spende für den Kanal
Wenn meine Beiträge hilfreich sind oder dir geholfen haben, würde ich mich über eine Unterstützung sehr freuen 🙏
#MatrixProtocol #ElementX #ElementWEB #SelfHosted #Synapse #OpenSource
