Détection automatique ou rejet des uploads vidéo VP9 incompatibles avec iOS Safari

Contribuer Fonctionnalité
1

J’ai récemment découvert que plusieurs vidéos sur mon forum Discourse auto-hébergé échouaient silencieusement lors de la lecture sur iPhone et iPad. Après investigation, la cause racine s’est avérée être que les vidéos avaient été encodées avec le codec VP9 dans un conteneur MP4 — une combinaison que Safari sur iOS ne peut pas lire.

Comment cela se produit

Facebook (et peut-être d’autres plateformes) livre parfois des vidéos encodées en VP9 lorsque les utilisateurs téléchargent leur contenu. Lorsque ces fichiers sont téléchargés sur Discourse, ils sont acceptés sans problème — l’extension .mp4 ne donne aucune indication sur le codec contenu à l’intérieur. Sur les navigateurs de bureau et Android, les vidéos se lisent correctement, donc le problème passe inaperçu. Sur Safari iOS, la vidéo affiche une vignette et un bouton de lecture, mais un appui dessus ne produit qu’un indicateur en rotation. Les utilisateurs supposent généralement qu’il s’agit d’un problème réseau et passent à autre chose sans le signaler.

Pourquoi c’est difficile à détecter

  • L’extension du fichier (.mp4) est identique à celle d’un fichier H.264 fonctionnel
  • Les navigateurs de bureau prennent en charge VP9, donc les administrateurs testant sur bureau ne remarquent aucun problème
  • Les utilisateurs iOS ne signalent souvent pas les échecs individuels de médias, surtout lorsque d’autres contenus dans le même message sont visibles et lisibles
  • Il n’y a aucun avertissement ou erreur visible pour l’administrateur

Résolution suggérée

Lors du téléchargement d’une vidéo, Discourse pourrait inspecter le codec vidéo (ffprobe est déjà disponible dans le conteneur Docker) et soit :

  1. Rejeter le téléchargement avec un message clair expliquant que VP9 n’est pas pris en charge sur iOS, en demandant à l’utilisateur de réencoder en H.264, ou
  2. Transcoder automatiquement la vidéo en H.264 lors du téléchargement (comme le font certaines plateformes pour normaliser les uploads)

L’option 1 est moins complexe et constituerait déjà une amélioration significative. L’option 2 serait idéale pour une expérience utilisateur fluide.

Environnement

  • Discourse auto-hébergé dans Docker, stockage local (pas de S3)
  • Version de Discourse : 2026.4.0-latest
  • Proxy inverse Apache devant le nginx de Discourse

Contournement

Pour les administrateurs confrontés à ce problème, la correction implique :

  1. Identifier les fichiers VP9 avec ffprobe
  2. Réencoder en H.264 avec ffmpeg -c:v libx264 -profile:v main -level 3.1 -r 30 -movflags +faststart
  3. Mettre à jour les champs sha1, url, filesize dans la table uploads
  4. Mettre à jour les tokens d’URL courte upload:// dans le markdown brut des messages concernés
  5. Rebake les messages affectés

Il s’agit d’un processus manuel non trivial que la plupart des administrateurs de forum ne sont pas en mesure d’effectuer.

1 « J'aime »
2

Pour la transcodification automatique, consultez Discourse Video Stream :movie_camera:.

La transcodification locale automatique fonctionne, mais la principale difficulté réside dans sa mise en œuvre de manière sûre pour la plupart des configurations.

2 « J'aime »
3

Merci pour l’orientation vers le plugin Video Stream, @Falco. Pour un petit forum d’amateurs comme le mien, ajouter une dépendance à un service tiers payant semble disproportionné par rapport au problème — même si je comprends l’attrait pour les sites à fort trafic avec une utilisation intensive de la vidéo.

Votre remarque sur la transcodification locale est intéressante. J’ai exécuté manuellement ffmpeg sur les 9 fichiers concernés sur mon VPS pendant le processus de correction, et le serveur l’a géré sans problème. Je comprends les préoccupations liées à une exécution synchrone lors du téléchargement : les pics de charge CPU, les délais d’attente et la pression sur le disque sont des risques réels. Mais une approche basée sur un travail asynchrone en arrière-plan ne résoudrait-elle pas la plupart de ces problèmes ? Le téléchargement se termine normalement, et la transcodification est effectuée dans un travail mis en file d’attente par la suite — similaire à la manière dont Discourse gère déjà la création de miniatures d’images. La vidéo ne serait simplement pas lisible sur iOS tant que le travail n’est pas terminé, ce qui semble être un compromis acceptable.

Même sans une transcodification complète, une option plus légère — détecter VP9 lors du téléchargement et soit le rejeter avec un message d’erreur clair, soit le signaler dans le panneau d’administration — irait déjà très loin pour les administrateurs en auto-hébergement qui n’ont peut-être pas les compétences techniques nécessaires pour diagnostiquer les échecs silencieux de lecture sur iOS.

1 « J'aime »
4

La vidéo est un peu plus compliquée, car il existe tant de façons pour un utilisateur de télécharger malicieusement quelque chose pour monopoliser le CPU, en particulier dans les nombreuses instances auto-hébergées avec 1 vCPU.

Je peux essayer d’explorer un plugin ici, afin qu’il devienne une option accessible à l’administrateur uniquement s’il est satisfait des compromis.

3 « J'aime »