Problème de lecture de vidéos sur Safari iOS et macOS

Salut à tous,

Nous rencontrons un problème sur 3.6.0.beta3-latest où les utilisateurs d’iPhone et de Safari sur macOS voient une roue tournante infinie lorsqu’ils tentent de lire une vidéo .mp4 (H.264) téléchargée. Ces mêmes vidéos fonctionnaient correctement jusqu’à récemment (je ne suis pas sûr de la dernière version de Discourse qui fonctionnait).

Il semble que Safari effectue une requête GET pour récupérer les premiers octets (Range: bytes=0-1) de la vidéo (par exemple, /uploads/default/original/1X/44395933ccadf546b1b1ce65b742e24f900b33fa.mp4), qui renvoie un code 200 mais échoue pour des raisons qui ne sont pas affichées dans la console JavaScript ou l’inspecteur réseau (juste surligné en rouge, sans messages d’erreur). Si la même URL est collée directement dans le navigateur, ils parviennent à télécharger la vidéo complète et à la lire.

Firefox et Chrome sur macOS n’ont aucun problème à lire les vidéos. Les navigateurs sur Android ne semblent pas non plus avoir de problèmes.

Les vidéos sont petites (dans la gamme de 10 Mo). Nous n’utilisons pas S3 pour les téléchargements.

Quelqu’un d’autre peut-il confirmer, ou confirmer qu’il n’a pas de problèmes avec les iPhones/Safari pour lire des vidéos ? Et y a-t-il d’autres diagnostics que je peux effectuer pour éclaircir le problème ?

1 « J'aime »

Je rencontre un problème similaire avec mon forum, mais tester les mêmes fichiers ici semble fonctionner correctement. Seuls les utilisateurs d’iOS/Safari sont affectés. Certaines vidéos dans le conteneur WEBM fonctionnent, mais la plupart des mp4, mov, etc., ne fonctionnent pas.

2 « J'aime »

Bonjour, j’ai rencontré des problèmes récemment et j’ai commenté un fil de discussion initié par @tsk qui a été retiré. Je partais du principe que le problème venait des vidéos encodées en mp4/av1 car les vidéos webm/vp9 fonctionnaient sur notre forum, mais il semble que le problème soit plus large pour les utilisateurs de Safari.

Juste pour le plaisir, j’ai vérifié que j’étais sur la dernière version, bien que je n’aie rien vu dans les commits qui indiquerait que cela affecte les utilisateurs d’Apple.

image

Ma configuration utilise le stockage local pour les téléchargements. La plupart des fils de discussion sont verrouillés derrière un niveau de confiance, mais nous testons dans une catégorie publique ici :

Pouvez-vous partager un lien vers ladite vidéo, ou la télécharger ici ?

1 « J'aime »

@Les79 J’ai mis cette vidéo en ligne sur les deux forums à titre d’essai.

Pouvez-vous confirmer que la vidéo du fil de discussion pixelspace safari ne fonctionne pas pour vous, mais que celle d’ici fonctionne ?

1 « J'aime »

Oui, la vidéo publiée ici fonctionne sur Safari sur mon iPhone 13 et mon MacBook Pro M3. Elle ne fonctionne pas sur le forum PixelSpace.

2 « J'aime »

Cette vidéo est en H.264 au format MP4, elle devrait se lire sur tous les navigateurs qui exécutent Discourse. Étant donné qu’elle fonctionne ici et pas sur votre instance, je suspecte qu’il y a un problème de configuration de votre côté.

Exécutez-vous un proxy inverse supplémentaire par-dessus Discourse ? J’ai vu des en-têtes sur cette instance qui n’existent pas sur les installations standard, je suis donc curieux de savoir ce qui a été fait là-bas.

1 « J'aime »

Je vois la même chose.

J’utilise ce conteneur comme proxy inverse

J’avais envisagé que cela puisse en être en partie responsable, mais la configuration n’a pas changé et il s’agit d’un nouveau problème depuis la version 3.6.0-beta2 d’après ce que j’ai pu constater. J’ai commencé à recevoir des plaintes d’utilisateurs d’Apple après la reconstruction. Similaire à @mandyk, je ne me souviens pas de la version précédente.

image

Y a-t-il un paramètre particulier dans Discourse que je devrais évaluer ?

1 « J'aime »

Ce n’est pas Discourse, mais le proxy.

Malheureusement, nous ne pouvons pas couvrir de manière réaliste toutes les possibilités infinies de configurations lorsque les gens ajoutent des éléments par-dessus Discourse, c’est pourquoi nous livrons avec une configuration connue et fonctionnelle lors de l’installation standard qui est livrée avec un proxy inverse configuré pour Discourse.

Il pourrait manquer une seule section de configuration nginx, mais vous devrez rechercher cela.

1 « J'aime »

Je confirme également que la vidéo publiée dans ce fil de discussion fonctionne correctement dans Safari.

Je ne suis pas sûr que ce soit pertinent, mais une différence que je peux constater est que la vidéo dans ce fil de discussion est servie depuis S3. Lorsque Safari effectue la première requête range, S3 répond avec HTTP 206, ce qui semble correct. L’instance Pixelspace et mon instance n’utilisent pas S3, et il semble que Discourse réponde avec HTTP 200 (ce qui ne semble pas correct, car la requête inclut un en-tête Range: bytes=0-1).

J’ai mis en ligne la même vidéo sur mon instance de test à l’adresse

https://discourse-on-a-pi5.falco.dev/t/test-safari-bug/25?u=falco

Confirmé que la vidéo sur discourse-on-a-pi5.falco.dev ne fonctionne pas pour moi sur Safari. Encore une fois, je constate que la requête vidéo renvoie 200 au lieu de 206.

Modification : De plus, il semble que la réponse tente de renvoyer la vidéo entière alors que Range: bytes=0-1 était spécifié. Je soupçonne que les requêtes de plage sont ignorées, et Safari semble y être sensible.

Modification supplémentaire : Cela signifie probablement que la recherche efficace sur les vidéos plus volumineuses est également rompue pour les navigateurs autres que Safari, car ils doivent télécharger la vidéo entière avant de pouvoir rechercher.

3 « J'aime »

La lecture ne fonctionne pas sur Safari pour moi

Et cela fonctionne sur Test Safari Bug - Discourse, n’est-ce pas ?

Oui, celui-ci fonctionne ! Et je vois HTTP 206 là-bas.

1 « J'aime »

On dirait une régression dans notre configuration nginx par défaut alors, merci pour le rapport @mandyk

1 « J'aime »

Merci à @Adubs d’avoir posté une contre-reproduction à comparer ! Et à l’équipe Discourse pour un outil génial.

5 « J'aime »

Alors, juste pour rire, j’ai copié mon app.yml dans app2.yml, j’ai changé l’URL et quelques répertoires, et nous avons maintenant testfor.pixelspace.xyz qui exécute la branche stable.

https://testfor.pixelspace.xyz/t/safari-playback-test/8

Mes utilisateurs confirment que cela fonctionne ici via le même proxy.

edit : Je vois maintenant qu’il y a une confirmation du problème. Mes excuses de ne pas avoir pensé à essayer cela plus tôt. Merci pour votre perspicacité @mandyk

Je n’aurais pas trouvé cela par moi-même.

3 « J'aime »