VP9-Videouploads automatisch erkennen oder ablehnen, die mit iOS Safari inkompatibel sind

Beitragen Merkmal
1

Ich habe kürzlich festgestellt, dass mehrere Videos auf meinem selbst gehosteten Discourse-Forum auf iPhone und iPad stillschweigend nicht abgespielt wurden. Nach Untersuchungen lag die Ursache darin, dass die Videos mit dem VP9-Codec in einem MP4-Container codiert waren – eine Kombination, die iOS Safari nicht abspielen kann.

Wie es dazu kommt

Facebook (und möglicherweise andere Plattformen) liefert manchmal VP9-codierte Videos aus, wenn Nutzer ihre Inhalte herunterladen. Wenn diese Dateien dann auf Discourse hochgeladen werden, werden sie problemlos akzeptiert – die Endung .mp4 gibt keinen Hinweis auf den enthaltenen Codec. Auf Desktop-Browsern und Android laufen die Videos einwandfrei, sodass das Problem unbemerkt bleibt. Auf iOS Safari wird zwar ein Vorschaubild und eine Wiedergabetaste angezeigt, aber beim Tippen erscheint nur ein rotierendes Symbol. Nutzer gehen meist davon aus, dass es sich um ein Netzwerkproblem handelt, und melden es nicht.

Warum es schwer zu erkennen ist

  • Die Dateierweiterung (.mp4) ist identisch mit einer funktionierenden H.264-Datei
  • Desktop-Browser unterstützen VP9, sodass Administratoren beim Testen auf dem Desktop kein Problem bemerken
  • iOS-Nutzer melden einzelne Medienfehler oft nicht, besonders wenn andere Inhalte im selben Beitrag sichtbar und abspielbar sind
  • Es gibt keine Warnung oder Fehlermeldung für Administratoren

Empfohlene Lösung

Beim Hochladen von Videos könnte Discourse den Videocodec prüfen (ffprobe ist bereits im Docker-Container verfügbar) und entweder:

  1. Das Hochladen ablehnen mit einer klaren Meldung, dass VP9 auf iOS nicht unterstützt wird, und den Nutzer auffordern, das Video erneut in H.264 zu konvertieren, oder
  2. Das Video automatisch in H.264 transkodieren, ähnlich wie einige Plattformen dies bei Uploads tun

Option 1 ist weniger aufwendig und würde bereits eine deutliche Verbesserung darstellen. Option 2 wäre ideal für ein nahtloses Nutzererlebnis.

Umgebung

  • Selbst gehostetes Discourse in Docker, lokaler Speicher (kein S3)
  • Discourse-Version: 2026.4.0-latest
  • Apache Reverse-Proxy vor Discourse nginx

Workaround

Für Administratoren, die auf dieses Problem stoßen, besteht die Lösung darin:

  1. VP9-Dateien mit ffprobe zu identifizieren
  2. Umwandlung in H.264 mit ffmpeg -c:v libx264 -profile:v main -level 3.1 -r 30 -movflags +faststart
  3. Aktualisierung von sha1, url und filesize in der Tabelle uploads
  4. Aktualisierung der upload://-Kurz-URL-Tokens im Rohtext der betroffenen Beiträge
  5. Neuberechnung der betroffenen Beiträge

Dies ist ein nicht unerheblicher manueller Prozess, den die meisten Forum-Administratoren nicht durchführen können.

1 „Gefällt mir“
2

Für eine automatische Transkodierung kannst du Discourse Video Stream :movie_camera: prüfen.

Die automatische lokale Transkodierung funktioniert, aber die sichere Bereitstellung für die meisten Konfigurationen ist das Hauptproblem.

2 „Gefällt mir“
3

Danke für den Hinweis auf das Video Stream-Plugin, @Falco. Für ein kleines Enthusiasten-Forum wie meines wirkt die Einführung einer Abhängigkeit von einem kostenpflichtigen Drittanbieter-Service als übertrieben – obwohl ich die Vorteile für hochfrequentierte Seiten mit intensivem Videonutzung nachvollziehen kann.

Dein Hinweis zur lokalen Transkodierung ist interessant. Ich habe während des Reparaturprozesses manuell ffmpeg auf den 9 betroffenen Dateien auf meinem VPS ausgeführt, und der Server hat dies problemlos bewältigt. Ich verstehe die Bedenken bezüglich einer synchronen Transkodierung während des Uploads – CPU-Spitzen, Timeouts und Festplattenbelastung sind reale Risiken. Würde ein asynchroner Hintergrundprozess-Ansatz jedoch nicht die meisten dieser Probleme lösen? Der Upload würde normal abgeschlossen werden, und die Transkodierung würde anschließend in einem gestarteten Job erfolgen – ähnlich wie Discourse bereits die Erstellung von Bildvorschauen handhabt. Das Video wäre einfach erst nach Abschluss des Jobs auf iOS abspielbar, was als akzeptabler Kompromiss erscheint.

Selbst ohne vollständige Transkodierung wäre eine leichtgewichtige Option hilfreich – etwa die Erkennung von VP9 beim Upload und entweder die Ablehnung mit einer klaren Fehlermeldung oder die Kennzeichnung im Admin-Bereich. Das würde selbst gehosteten Administratoren, die möglicherweise nicht über das technische Hintergrundwissen verfügen, um stille Wiedergabefehler auf iOS zu diagnostizieren, sehr weiterhelfen.

1 „Gefällt mir“
4

Bei Videos ist es etwas komplizierter, da es viele Möglichkeiten gibt, wie ein Benutzer böswillig etwas hochladen könnte, um die CPU zu blockieren, besonders bei vielen selbstgehosteten Instanzen mit nur 1 vCPU.

Ich kann versuchen, hier ein Plugin zu entwickeln, sodass es eine Option wird, auf die der Administrator nur zugreifen kann, wenn er mit den Kompromissen einverstanden ist.

3 „Gefällt mir“