Three.js: Safari/Firefox DOM Exception 18 pour la texture vidéo en streaming

Le problème à l'envers fait-il partie du problème ?

La tête en bas ne fait pas partie du problème. C'était moi qui étais paresseux >_<

Je peux reproduire ici. Avez-vous essayé d'avoir une toile intermédiaire?

:+1:, entre-deux comme une toile 2d ?

Oui, utilisez une toile 2d comme texture et faites-y dessiner l'image de la vidéo.

Je vais le faire maintenant. https://dl.dropboxusercontent.com/u/1595444/shaka-player/shaka-canvas.html

On dirait que dans Safari, il n'y a pas de DOM Exception 18 lancé, mais l'image n'est pas transférée. Idem avec Firefox. Cela signifie-t-il que c'est une question d'implémentation de navigateur ?

Face au même problème. Safari lance l'exception Dom 18, Firefox ne charge pas l'image mais n'affiche également aucune erreur. @jonobr1 obtenez -vous des erreurs dans firefox ?

Aucune erreur dans Firefox, mais également aucune image. Je vais rapporter des bugs avec WebKit
et Mozilla respectivement et voyez si des informations supplémentaires apparaissent.

Je ne sais pas pour vous les gars mais je n'ai pas vu de démos de vidéo en streaming
téléchargé sur une texture WebGL. Peut-être y en a-t-il un avec YouTube comme source ?
Le jeu. 11 février 2016 à 23:11 Taha Sabih [email protected]
a écrit:

Face au même problème. Safari lance l'exception Dom 18, Firefox ne le fait pas
charge l'image mais ne montre également aucune erreur. @jonobr1
https://github.com/jonobr1 obtenez-vous des erreurs dans firefox ?

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/mrdoob/three.js/issues/8110#issuecomment-183208337 .

Le streaming vidéo en soi n'est pas un problème. Si vous créez un élément vidéo dans js et utilisez video.src pour définir la source de l'élément vidéo, la vidéo est diffusée correctement. Le streaming adaptatif avec Shaka est un problème. J'ai l'impression que le problème vient des implémentations CORS dans webkit et gecko, d'où l'exception DOM 18 dans Safari. L'exemple ci-dessous fonctionne parfaitement avec les mêmes sources vidéo de domaine sur tous les navigateurs.

            var video = document.createElement( 'video' );
            video.width = 640;
            video.height = 360;
            video.autoplay = true;
            video.loop = true;
            video.src = "<your mp4 source>";

           // adding the line below makes cross origin videos work, but just for chrome
           // video.crossOrigin = 'anonymous';

            var texture = new THREE.VideoTexture( video );
            texture.minFilter = THREE.LinearFilter;

            var material   = new THREE.MeshBasicMaterial( { map : texture } );

            mesh = new THREE.Mesh( geometry, material );

Juste pour clarifier, je ne pense pas que video.src = "<your mp4 source>"; soit en streaming. Je pense que c'est un téléchargement progressif . Mais oui je suis d'accord avec toi.

Les gars sont des gens qui ne font encore que travailler cela. Cela ne fera qu'empirer maintenant que les gens essaient de faire de la vidéo VR.

Heureusement, il y a un ticket ouvert, sinon si j'essayais de le communiquer, je serais fermé.

Pendant des années, Safari a eu des problèmes avec CORS. C'est un grave défaut et ils l'ont traité avec un mépris total. Le dessin sur toile 2D affecte également.

J'ai créé un ticket directement auprès d'Apple car un problème avec le kit Web persiste depuis juillet 2014 sans être attribué. La vidéo WebGL est fondamentalement inutile sur IOS et Safari jusque-là. Mais alors Iphone jouant la vidéo en ligne est également requis.

Je pense que le dépôt de doublons auprès d'Apple pourrait les aider à se dépêcher.

Veuillez les voir. J'ai presque fini d'obtenir les textures vidéo et la vidéo 360 fonctionnant entièrement sur Android, Chrome Dev vient de résoudre les problèmes de rendu sur lesquels je devais travailler sans relâche avec Chrome. Il y a maintenant des problèmes de performances de lecture vidéo avec Chrome.

Je suis maintenant sur ce bordel avec Safari !

Ceci est un radar du ticket Apple réel avec le problème mot pour mot

https://openradar.appspot.com/24641824

https://forums.developer.apple.com/message/113161#113161

Le problème réel du kit Web. Ils sont un travail.

https://bugs.webkit.org/show_bug.cgi?id=135379

Fondamentalement, cela n'a rien à voir avec three.js mais @mrdoob s'il vous plaît gardez cela ouvert, c'est important.

Vous devez faire des hacks de proxy inverse qui ne seront jamais mis à l'échelle comme avec le dessin 2D de la toile pour les instantanés. C'est documenté ici pour l'instant

https://flowplayer.electroteque.org/snapshot/fp6

location /video/ {
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-NginX-Proxy true;
        proxy_pass //videos.electroteque.org/;
        proxy_redirect off;
    }

Cela sera transmis à Cloudfront. Cela fonctionnera sur n'importe quelle vidéo, y compris HLS.

Il semble que ce soit plus un sabotage intentionnel qu'autre chose pour bloquer cela sur IOS. Firefox sur IOS ne prend pas non plus en charge CORS sans aucune raison. Il affiche ma fonction de secours de piratage de proxy CORS. Je pensais qu'au moins Firefox serait pleinement fonctionnel.

cela n'explique toujours pas pourquoi le bureau firefox ne dessinera pas d'images. Il envoie les en-têtes d'origine, et s'il est utilisé sans Shaka, il fonctionne très bien. Ce n'est que lorsque la source vidéo est référée à un blob (comme c'est le cas avec le streaming adaptatif) qu'elle ne parvient pas à dessiner l'image. Il ne signale également aucune erreur, ce qui est frustrant.

Dash fonctionne bien avec Dash.js et les textures vidéo. Mais je confirmerai sur Windows/OSX une fois que j'aurai fini de refactoriser leurs modifications.

Firefox OSX et Windows est entièrement fonctionnel. Avec Dash ou streaming html5 normal.

A part les suivants :

Je reçois ces journaux apparaissent à la fois sur OSX et Windows.

Error: WebGL: Disallowing antialiased backbuffers due to blacklisting.

J'exécute Firefox sur Windows 10 dans VMware. Pour cette raison, je pense que Firefox bloque Webgl. Il revenait au CanvasRenderer. J'ai dû activer spécifiquement webgl avec cette configuration.

webgl.force-enabled=true

Vous devez vérifier la prise en charge de WebGL et le recours à CanvasRenderer, mais je ne pense pas que ce soit votre problème.

WebGL et Canvas ont tous deux besoin du support CORS pour fonctionner, donc Firefox est exclu. C'est tous ces cognards webkit et Apple maintenant.

Pour info, voici à quoi ressemble mon tag vidéo généré.

Vous avez besoin de la propriété crossorigin qui est tout le problème avec Safari. Celui qui a dit que cela ne fonctionnait pas sur Firefox n'est pas correct.

Safari n'a pas réussi à l'implémenter depuis des années et c'est pourquoi WebGL ne fonctionne pas avec pour les vidéos inter-domaines qui nécessitent le piratage du proxy inverse.

La prise en charge d'IE pour CORS est également douteuse. IE11 n'a pas réussi à l'implémenter également. Le navigateur Edge est compatible avec CORS et Webgl.

<video crossorigin="anonymous" x-webkit-airplay="allow" preload="auto" webkit-playsinline="true" src="blob:http%3A//localhost%3A8000/8a0dd373-8cb1-4a1d-9ad2-60d0b8f001bf" width="1024" height="512"></video>

Hé @danrossi , j'adore l'enthousiasme ! Avez-vous un exemple en ligne de son fonctionnement dans dash.js ?

De plus, j'ai signalé des bogues avec Safari et Firefox. Vous pouvez voir les progrès sur les deux ici:

https://bugs.webkit.org/show_bug.cgi?id=154189

https://bugzilla.mozilla.org/show_bug.cgi?id=1248054

Essayez dash.js avec une balise vidéo comme celle-ci. Je confirmerai avec le piratage du proxy si Safari fonctionne avec Dash.

Je suggère d'amener Apple à s'impliquer dans les problèmes CORS en déclenchant des tickets en double sur le problème CORS avec eux comme je l'ai fait. Je veux dire que le ticket du kit Web est peut-être là depuis juillet 2014, mais quelque chose d'aussi paralysant que cela, ils auraient dû prendre des mesures.

Confirmer le piratage du proxy ne fait rien lors de l'utilisation de MediaSource sur Safari, cela convient aux fichiers mp4. Donc, même s'ils implémentent finalement CORS, cela sera toujours cassé.

J'y ai laissé un commentaire dans le numéro du kit Web, mais étant donné que le principal ticket CORS n'a pas été attribué depuis 2014, Safari et IOS sont pratiquement morts pour la VR.

Firefox me convient parfaitement sous Windows 10 et OSX. Firefox n'a pas de CORS sur IOS donc inutile là-bas. Je pourrais faire un ticket pour qu'ils le fassent, donc au moins quelque chose fonctionne sur IOS.

J'ai laissé un autre commentaire sur votre ticket webkit. Ils sont liés au problème principal de la SCRO et devraient probablement être fusionnés et traités en même temps.

Ce qui me rend vraiment fou, c'est que votre ticket est attribué, mais le ticket pour le problème CORS réel a été laissé haut et sec pendant 2 ans, rendant la VR sur Safari inutile.

Encore une fois, celui-ci n'a rien à voir avec three.js mais devrait être laissé ouvert pour ceux qui ne réalisent que Safari et IOS sont bourrés.

OK, après avoir fait quelques recherches sur les hacks vidéo en ligne pour Iphone que j'ai déjà ajoutés au ticket Apple, il semble que dessiner sur le canevas 2D est correct sans CORS. C'est en essayant d'obtenir un uri de données qu'il y a un problème, donc mon erreur. Il semble donc que lors de l'utilisation de WebGL, cela pose également un problème car Safari ne prend pas en charge CORS et doit plutôt recourir au moteur de rendu canvas.

Il ne fonctionnera pas ou ne fonctionnera pas bien sur IOS car il supprime des images et je pense qu'il a besoin d'une balise audio en cours d'exécution pour lire l'audio, de sorte que cela ne fonctionnera pas bien pour le tableau de bord mpeg.

voir http://stanko.github.io/html-canvas-video-player/

Juste pour garder les choses simples, j'ai mis à jour cet exemple webgl brut pour utiliser mp4 pour safari. J'ai également mis à jour ce ticket webkit. C'est à cause du manque de soutien CORS.

https://jsfiddle.net/7t77rz6L/11/

"SecurityError : DOM Exception 18 : une tentative a été effectuée pour contourner la politique de sécurité de l'agent utilisateur."

Merci d'avoir pris soin de signaler le problème. J'ai également vu cela en dehors de three.js, et c'est très ennuyeux .. !

Pomme ! Il a besoin d'une vague massive de tickets en double si possible. Je veux dire que Youtube est sûr d'eux avec le support WebGL mais Safari ne fonctionnera pas et ne fonctionnera pas dans leur lecteur 360 actuel, donc je ne sais pas pourquoi ils ne font rien à ce sujet. J'ai également confirmé que même avec le piratage proxy, Iphone ne jouera pas en ligne, donc les lunettes VR et VR sont complètement inutiles sur un Iphone. Cela nécessite un hack très risqué de lecture audio séparée et de mise à jour de l'heure de la vidéo pour obtenir une nouvelle image afin de ne pas réellement lire la vidéo. Cela ne fonctionnera pas avec le tableau de bord.

Et ce n'est pas un problème juridique, les droits de format étant le vrai problème non technique ? Donc, vous avez essayé les autres formats, je suppose? webm ogg apparemment, il y a aussi l'idée de Media Source Extensions MSE, il existe également différents paramètres de haut niveau pour MP4 H.264 qui ne fonctionnent pas sur du matériel bas de gamme (problèmes).
Je me souviens que les problèmes de compatibilité des formats vidéo étaient non techniques et plus liés aux licences et aux problèmes juridiques ou simplement à des problèmes de contrôle.
Quoi qu'il en soit tellement choquant donc +1. Je suppose que nous pouvons toujours boycotter, à la fin personne n'utilisera les trucs qui ne fonctionnent pas. J'utilise Android et Chrome exclusivement pour de nombreuses autres raisons, dont celle-ci.

Il s'agit d'un problème de kit Web avec un manque de fonctionnalité CORS. Ils l'ont laissé gaspiller pendant des années en pensant qu'ils pourraient s'en tirer. Ce n'est que maintenant que les personnes essayant d'utiliser Webgl ont un problème et s'en rendent compte. Un accident qui attend de se produire. La même chose en forçant Iphone à ne pas jouer en ligne. Les vidéos du même domaine ne sont pas une utilisation réelle.

Android Chrome a des problèmes de webgl qui s'affichent également sur canvas. Je viens de passer tout le mois à m'en occuper et j'ai finalement confirmé dans ce ticket que le dernier développeur fonctionne à nouveau. Au moins Android fonctionnera avec les lunettes VR et WebVR, pas Iphone.

Je vais réessayer avec un fichier de tableau de bord chargé en local et voir ce qui se passe.

Il y a une mise à jour de statut sur le ticket webkit. Je crois qu'ils ont dû réparer quelque chose d'autre pour travailler sur ce ticket, mais personne n'a toujours été affecté au ticket de bogue cors réel. Absolument tout compte sur eux pour le réparer et, espérons-le, obtenir une version à la fois dans IOS et dans Safari. Cela devrait être très embarrassant pour Apple. Ils ont laissé tomber cela pendant de nombreuses années sans raison.

@danrossi merci de nous tenir au courant ! ??

@danrossi travail incroyable! Merci pour toutes les mises à jour

??? Le développeur Webkit fonctionne maintenant ?

Je n'ai pas vu de mise à jour de statut disant le contraire mais du bruit de commits. Je vais confirmer.

c'est la dernière mise à jour. Qui sait si cela corrige également le manque de support CORS.

https://bugs.webkit.org/show_bug.cgi?id=125157#c29

Qui sait s'il arrivera un jour dans IOS. Les problèmes de lecture vidéo en ligne sur iPhone sont également préoccupants. Dois-je faire un autre bug ticket à Apple à ce sujet ?

Oh désolé je pensais que tu avais dit que ça fonctionnait hah. Très proche semble-t-il. J'ai un ticket radar pour Apple et ils n'ont jamais répondu. Cela nécessite la création de doublons s'ils doivent un jour prendre des mesures ou veiller à ce que la réalité virtuelle fonctionne sur leur plate-forme.

Je pense donc que la pression monte sur Apple. Ils ont fermé mon ticket en prétendant qu'il y avait un duplicata que vous ne pouvez ni voir ni commenter et cela ressemble à un ticket très tôt. Mais cela n'explique toujours pas la lecture vidéo en ligne sur Iphone pour WebGL. Il faut des tas de plaintes pour qu'ils prévoient que cela pourrait prendre des années.

Je suis retourné vérifier auprès des utilisateurs de Chrome et il semble que Chrome Dev Android soit toujours en panne pour rendre WebGL. Il existe un indicateur qui peut être activé pour l'afficher, mais cela entraînera de graves pertes d'images.

Le navigateur Android d'origine a des problèmes CORS comme Safari, donc inutiles. Firefox IOS ne prend pas non plus en charge CORS et va ajouter un ticket pour les amener à l'implémenter. Ces trucs CORS qui paralysent tout est tout simplement choquant.

Donc, si vous avez besoin d'un vecteur de support pour mobile avec toutes les fonctionnalités qui fonctionnent. Android Firefox tous les soirs car ils ont corrigé les bugs d'orientation et c'est tout. Très triste.

Si cela vous intéresse, j'ai officiellement créé un ticket ici afin qu'au moins Firefox sur IOS puisse faire fonctionner WebVR et oublier Safari. Je n'ai pas encore confirmé s'il peut lire la vidéo en ligne sur Iphone. Ils pourraient être plus rapides à agir sur le support CORS, mais ce n'est pas le cas.

https://bugzilla.mozilla.org/show_bug.cgi?id=1256083

La confirmation des mécanismes de désactivation d'Apple force également la vidéo dans un lecteur natif pour Firefox. Sabotage intentionnel d'après son apparence.

cela ne montre rien non plus sur canvas dans firefox sur mac (fonctionne avec chrome), pas un problème ios.

oh, ff commence à montrer l'image après environ 2:50

Ne vous méprenez pas ici. C'est un problème CORS qui a tout à voir avec IOS/Safari. Je ne sais rien de cet exemple de tableau de bord mais j'ai testé Dash avec des textures vidéo sur Firefox sur OSX et c'est bien.

Avec Dash sur Firefox, il semble y avoir un problème avec les segments que vous créez lorsque vous traitez les fichiers vidéo pour les rendre compatibles avec Dash. Ne pas segmenter les fichiers semble fonctionner sur Firefox (cela pourrait également expliquer pourquoi les dernières secondes d'une vidéo segmentée sont lues).

Le 13 mars 2016, à 21h51, danrossi [email protected] a écrit :

Ne vous méprenez pas ici. C'est un problème CORS qui a tout à voir avec IOS/Safari. Je ne sais rien de cet exemple de tableau de bord mais j'ai testé Dash avec des textures vidéo sur Firefox sur OSX et c'est bien.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub.

Ce sont mes fichiers emballés que j'ai bien testés avec three.js. J'ai utilisé bento4. l'intervalle d'images clés h264 est toujours (2,3,4) * fréquence d'images comme HLS. Pas de problème avec WebGL. Le problème CORS est vraiment un problème pour Webkit et Apple et Firefox sur IOS. Vous devez spécifier l'attribut "crossorigin".

https://videos.electroteque.org/dash/nodrm/bbb/bbb.mpd

Désolé d'apporter ça ici, mais les gens ont besoin de savoir.

Salut les gars, je viens de trouver quelque chose de vraiment faux et à l'envers et le même vieux pour mobile qui m'apporte un monde de douleur.

Samsung Gear essaie de lancer sa propre application avec un navigateur sur le S7. J'ai demandé à quelqu'un de tester WebGL / WebVR et lors de la mise en place des lunettes Gear, il lance sa propre application au lieu de Chrome. L'intérêt de WebVR est de lancer le canevas WebGL lorsque vous passez en plein écran dans les lunettes.

Donc, ce qui se passe, c'est qu'il semble que leur application idiote utilise le code de navigateur Android au lieu de Chrome et ne prend donc pas en charge les textures vidéo WebGL et la vidéo inter-domaines et même l'API WebVR.

Les applications sont des nouvelles si anciennes, s'attendant à ce que tout le contenu téléchargé soit lu. Il en va de même pour le téléchargement progressif de fichiers mp4, tout est désormais en streaming segmenté, de sorte que ce modèle est obsolète.

Je viens de comprendre que Chrome de production semble rendre les textures vidéo WebGL sur le S7, mais mon S3 est complètement cassé et j'essaie de le comprendre avec les développeurs Chrome depuis des mois.

Aucune idée de ce qui se passe même avec IOS. IOS est complètement inutile pour la réalité virtuelle en ce moment aussi. Webkit bourre toujours de support de sécurité inter-domaines qu'ils n'ont pas réussi à mettre en place pendant des années, rendant la réalité virtuelle inutile. D'où tout cela ci-dessus.

Pour info : ce commit https://github.com/mrdoob/three.js/commit/854ebf5bd6179a3046d4b901b12a9cbc99008c61 corrige le problème pour Firefox 👍

Salut selon cela furtivement car Apple a ignoré mes tickets de bogue et les a fermés, il semble qu'Apple l'ait corrigé mais a bifurqué le code, il semble dans Safari mais dans macOS. Un système d'exploitation et un navigateur que personne n'utilise encore.

S'ils ne le fusionnent pas dans le kit Web et ne fournissent pas de mises à jour corrigées aux navigateurs actuels, les utilisateurs devront attendre mais fourniront toujours un remplacement de proxy hérité.

Cela sera toujours interrompu pour Dash, bien que le piratage du proxy ne fonctionne pas, mais le confirmera à nouveau.

https://twitter.com/zenoc/status/742770789880111104

Salut les gars merci pour toutes les infos,

mais en fait, si quelqu'un pouvait expliquer en détail comment implémenter les "piratages de proxy inverse" répertoriés ici :
https://github.com/mrdoob/three.js/issues/8110#issuecomment -183570240

ce serait génial

merci
Saar

pour apache

 ProxyPass /video/ //videos.electroteque.org/
    ProxyPassReverse /video/ //videos.electroteque.org/

Pour nginx

location /video/ {
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-NginX-Proxy true;
    proxy_pass //videos.electroteque.org/;
    proxy_redirect off;
    }

D'après ce que je comprends, les navigateurs Webkit actuels ne verront jamais le changement. Ils l'auront prêt pour un mac et un système d'exploitation IOS que personne n'a même. Ils sont toujours en train de jouer avec CORS pour IOS à cause de "problèmes de framework" qui le retiennent.

Il faudra peut-être recourir à une solution Flash si Stage3D peut rendre le matériel accéléré mais qu'il n'aime pas autant qu'il le peut. Il dessine constamment des données bitmap.

Merci pour la réponse rapide

ok, donc pas de solution de contournement pour moi pour le moment, jusqu'à ce qu'Apple corrige cela.

Qu'en est-il d'attraper "DOM Exception 18" pour les options de secours ? Comment puis-je l'attraper?

J'ai essayé de le mettre sur l'appel render() d'un objet THREE.WebGLRenderer mais il n'est pas attrapé.

Vous faites la détection sur une vidéo temporaire. c'est à dire

testVideo.hasAttribute("crossOrigin")

Vous pouvez également simplement faire une détection de navigateur. Son Safari et IE 11.

Juste un avertissement sur ce problème fou. Je ne peux pas encore tester le mode VR sur IOS à moins de le déployer sur mon Ipad.

Les applications Cordova utilisent WebView. Il a des options pour jouer en ligne afin de contourner ce problème embêtant. Cela fonctionne autour de l'interaction de l'utilisateur. Celui-ci est le plus fou de tous et m'a rendu fou.

WebView semble contourner complètement CORS même s'il s'agit d'un fichier html local exécuté sur file://. WebGL fonctionne dans les applications Cordova sans avoir besoin de l'attribut crossorigin. C'est à la fois une nouvelle choquante et une bonne nouvelle. Il n'aura pas besoin du piratage du proxy mais Safari IOS/OSX le fera.

Je ne peux pas vérifier les commandes d'orientation pseudo VR, mais les commandes tactiles fonctionnent, tout comme l'ancien effet stéréo en carton. Je mettrai à jour ce ticket Webkit.

Les tests sur Android sont un problème à cause du bug de rendu Chrome que j'ai passé 3 mois à essayer de corriger et à abandonner par les utilisateurs de Chromium. C'est malheureusement complètement noir et, espérons-le, ce n'est pas un problème CORS qui n'affiche pas d'erreurs.

alors j'ai bien compris ? est-ce TOUJOURS le seul moyen d'utiliser les textures vidéo webgl avec webgl en implémentant ce hack proxy sur le serveur ?

Safari est complètement et totalement bolloxé, tout comme IOS. Si vous utilisez des applications basées sur Cordova WebView, vous pouvez jouer en ligne, jouer automatiquement et ne pas demander pourquoi, mais CORS n'est pas un problème. Ce serait pour mp4 / HLS sur IOS.

Mais comme je l'ai signalé et découvert. Ils étranglent les appareils plus anciens et les ralentissent pour forcer les gens à se mettre à niveau. L'Ipad 3 est inutile pour WebGL et restitue à 5 ips. Il doit s'agir d'un appareil plus récent.

Dans Safari sur OSX, mediasource est complètement et totalement bolloxé. le proxy CORS ne fonctionne pas là-bas. Il doit également s'agir d'un fichier mp4 ou d'un HLS natif. Avec HLS natif, vous fournissez une URL de proxy CORS.

Ces ratés chez Apple prévoient de publier des correctifs dans macOS, donc dans quelque chose que personne n'a encore.

Ils essaient de résoudre les problèmes de framework sous-jacents dans IOS. Je doute donc que CORS soit même corrigé dans la prochaine version d'IOS.

WebVR non plus, les deux sont une blague. Ils traitent WebVR comme une sorte de blague et ont des années de retard.

Eh bien, WebVR sur le bureau a besoin du SDK Windows, donc OSX n'est pas encore une option de toute façon, mais au moins l'API pourrait-elle être là pour les tests client ? Si Android a un affichage en carton par défaut, vous ne savez pas pourquoi IOS ne le peut pas et que WebVR est activé ?

Ils ont laissé ce problème CORS traîner pendant des années et c'est le produit de cela.

Cela semble vraiment fou.
(Désolé, je ne suis pas un développeur full stack)
Je veux juste être sûr : dans l'ensemble, si je n'ai pas accès au serveur, les textures vidéo sur webgl ne sont pas possibles sur ios ? AVEC le proxy hack ça marche sur ios mais PAS sur osx ?

Vous pouvez essayer un iframe. Je n'ai pas encore essayé. Le joueur devra être assis sur cloudfront avec les fichiers vidéo.

n'aide pas avec le code dynamique cependant. c'est-à-dire quelques pseudo-liens.

un lien vidéo est //videos.electroteque.org/360/video.mp4

La page iframe est //videos.electroteque.org/360/player.html

Apple ouvre la voie avec les normes, je crois. Où vous avez besoin de pages iframe de fichiers statiques pour vos lecteurs.

J'ai vu que Chrome pour iOS ajoutera la lecture en ligne :
https://bugs.chromium.org/p/chromium/issues/detail?id=395206
Le mardi 23 août 2016 à 5h18, danrossi [email protected] a écrit :

Vous pouvez essayer un iframe. Je n'ai pas encore essayé. Le joueur devra
être assis sur le cloud avec les fichiers vidéo.

n'aide pas avec le code dynamique cependant. c'est-à-dire quelques pseudo-liens.

un lien vidéo est //videos.electroteque.org/360/video.mp4

La page iframe est //videos.electroteque.org/360/player.html

Apple ouvre la voie avec les normes, je crois. Où vous avez besoin de statique
fichier des pages iframe pour vos lecteurs.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/mrdoob/three.js/issues/8110#issuecomment-241712327 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AANbgfcQaLhx_UmJHEmViJ76_Hi4uikSks5qiuUKgaJpZM4HYtu3
.

Oui! ??

Je viens de tester Chrome sur IOS. Je ne savais pas qu'ils en avaient un.

Il semble qu'il utilise également Webkit comme Firefox. Et souffre de problèmes CORS. Il est difficile de déboguer Chrome à distance sur IOS en raison des limitations évidentes d'Apple de leur côté et nous ne cessons de planter. Mais j'ai changé mon travail CORS autour de l'URL et j'obtiens un cadre noir. Je sais donc que CORS est paralysé sur Chrome, Firefox et Safari sur IOS. Avec l'URL de proxy CORS appropriée, cela "fonctionne"

la lecture en ligne n'est qu'une partie du problème et seulement un problème pour Iphone.

la lecture en ligne arrive sur iOS 10. La solution iframe fonctionne pour le problème CORS, mais vous perdez les événements devicemotion et orientationchange dans la fenêtre enfant

Ouais, n'avoir que la lecture en ligne n'est que la moitié du problème. Le problème CORS est bien plus important mais il n'arrivera pas sur IOS 10. Le problème CORS peut être complètement résolu pour Safari mais dans macOS.

Le contournement d'Iframe n'est pas une option nécessitant de s'asseoir sur le même domaine que le stockage en nuage, par exemple. Peut-être qu'il y a une sorte de hack DNS pour faire croire que cname sub.domain.com est domain.com mais aucune idée.

@thiagopnts Ces événements seraient-ils donc désactivés dans un lecteur intégré iframe même en plein écran ?

@danrossi d' après ce que nous avons testé, tous les événements attachés au window ne sont pas déclenchés à l'intérieur d'un iframe

Une belle pomme !

@thiagopnts Pouvez- vous donner un exemple d'iframe

@cheesyeyes ici : http://thiago.me/kaleidoscope/iframe.html
la page est sous les pages github, puis l'iframe et la vidéo sont chargées depuis google drive

oui ça marche sur Safari mais pas très pratique. un fichier html statique pour chaque vidéo sur le CDN ?

Les gars, ce problème doit-il être clos ?

Je pense qu'il n'y a rien que vous puissiez faire. Tout comme "l'ancien dispositif d'étranglement destiné à le rendre obsolète", comme nous venons de le découvrir avec le problème fps.

Quelque chose de vraiment bizarre a changé dans Safari sur Yosemite qui n'existait pas auparavant. Il a cassé la détection de fonctionnalités avec CORS dans beaucoup de choses que j'ai faites.

Juste un avertissement aux gens qui travaillent à quel point c'est vraiment cassé.

var testVideo = document.createElement("video");
 testVideo.crossOrigin = "anonymous";
console.log(testVideo.hasAttribute("crossOrigin"));

Dans IE11, il renvoie false comme prévu. Dans Safari c'est vrai mais le bug CORS est toujours visiblement là. La détection de fonctionnalité est là pour nécessiter évidemment le hack du proxy. La démence.

Donc, je ne peux pas m'empêcher de penser qu'un changement à moitié cuit a été poussé ?

Ce changement étrange avec le drapeau crossOrigin est dans Safari 10. Donc, une implémentation à moitié cuite. Safari 9 ne l'avait pas.

J'ai signalé quelques tickets de bogue webkit.

Ils sont allés saboter le piratage du proxy CORS sur une mise à jour IOS. macOS n'aurait pas non plus résolu le problème CORS dans Safari.

Je dois maintenant trouver comment contourner leur sabotage.

Sérieusement, ça me fait transpirer haha.

Tout le monde, faites votre part et convainquez les personnes que vous connaissez d'arrêter d'utiliser les appareils Apple. Faites-leur savoir qu'Apple est le nouveau IE5.

C'est bien triste de dire que CORS sur IOS est une restriction de framework, je pense qu'ils n'ont pas pris la peine de corriger dans IOS 10. En dehors de cela, tout ce qui utilise Webkit est un problème.

Apparemment, le problème CORS est résolu dans Safari sous macOS mais avec les toutes dernières mises à jour. La lecture vidéo en ligne fonctionne également sous IOS 10.

Voici deux tests pour le streaming mp4 et un autre pour HLS. Le HLS nécessite un travail supplémentaire en raison d'un bogue distinct avec FlipY qui pose toujours problème sur OSX Safari.

Le rendu HLS sur IOS 10 s'affiche mais présente des problèmes d'artefact de couleur. Les cadres cessent de fonctionner, mais je pense que c'est un problème avec l'émulateur et la chute des cadres. Je n'ai maintenant aucun appareil pouvant être mis à jour vers IOS 10 en raison de l'obsolescence et de la programmation lourde du côté d'Apple. Le HLS n'apparaît toujours pas sur IOS 9. Les deux nécessitent le proxy CORS pour mp4 et HLS.

http://dev.electroteque.org/webgl/threejscors.html
http://dev.electroteque.org/webgl/threejscors-hls.html

Maintenant coincé avec une situation dans laquelle la détection de fonctionnalité crossOrigin ne peut pas être utilisée car elle signale une prise en charge dans OSX 10.11 mais il n'y a rien de tel. essayer de détecter dans quel safari OSX est également utilisé. très mauvais.

C'est un peu absurde et cela retient vraiment iOS de tout développement WebVR basé sur la vidéo. J'essaie d'extraire une ressource interdomaine dans le cadre d'un projet en cours, et c'est la seule chose qui me retient maintenant. Fonctionne sur tous les Android et ordinateurs de bureau/ordinateurs portables, mais bien sûr, cela ne fonctionne pas sur iOS...

@theDrGray Vous pouvez essayer le hack iframe mais les iframes bloquent les apis d'orientation qui ont besoin d'un autre hack je crois ? Je vais enquêter sur une démo iframe bientôt.

Cela signifie que sur votre CDN, vous avez besoin de configurations de lecteur vidéo statiques par vidéo, ce qui est mauvais. Ce avec quoi je pourrais jouer, c'est

filename.html est analysé et le nom de fichier chargé est filename.mp4 , filename.webm, filename,m3u8 filename.mpd etc. Ensuite, un jeton privé peut être chargé sur celui-ci comme filename.html?t=token.

Si seulement une fonction Amazon Lamda pouvait fonctionner sur le même domaine que le nom des vidéos, les lecteurs pourraient être dynamiques ??

Si tout le reste échoue, vous avez besoin d'un proxy CORS et détecter cela est un problème maintenant. Ils l'ont saboté dans Safari 10. Safari 10 rapporte une prise en charge de "crossOrigin" mais ce n'est vraiment pas le cas dans IOS 10 et Yosemite. Vous devez faire une vérification secondaire pour OSX 10.12 haha

Voici à quoi ressemble la détection CORS dans mon projet de lecteur ES6

static supportsCORS() {
        let testVideo = document.createElement("video"),
            hasCORS = false;

        testVideo.crossOrigin = "anonymous";
        hasCORS = testVideo.hasAttribute("crossOrigin");
        testVideo = null;

        if (hasCORS) {

            if (WebVRUtils.isSafari) {

                if (WebVRUtils.isIpad) return false;
                return WebVRUtils.isNewSafari;
            }

            return true;
        }

        return false;

    }

    static get isSafari() {
        const userAgent = navigator.userAgent;
        return (/Safari/i).test(userAgent) && !(/Chrome/i).test(userAgent);
    }

    static get isIpad() {
        const userAgent = navigator.userAgent;
        return (/iP(hone|od|ad)/i).test(userAgent);
    }

    static get isNewSafari() {
        const version = /Mac OS X (10[\.\_\d]+)/.exec(navigator.userAgent)[1].split("_")[1];
        return +version >= 12;
    }

Mêmes problèmes ici... Fonctionne partout sauf iOS. Tellement bouleversant. Quel gros trou dans mon livrable. Cela fonctionne UNIQUEMENT (horrible fréquence d'images puis-je ajouter) lorsque le chemin source est relatif... Pas idéal pour le système de mise à l'échelle. Ugh.... Eh bien... Au moins je peux arrêter de me cogner la tête... C'est impossible... Pour l'instant... Maintenant pour construire autour de ça... Et les replis ux et la messagerie.

@danrossi Merci pour votre commentaire "Apparemment, le problème CORS est résolu dans Safari sous macOS mais les toutes dernières mises à jour", mais je n'ai pas pu trouver d'autres détails ailleurs que votre commentaire. Savez-vous avec quelle version de macOS et Safari cela fonctionne ? Serait-ce un "signe" qu'Apple propagera ce correctif sur iOS ?

On peut espérer...

Le 1er décembre 2016 à 15h50, "Kieran Farr" [email protected] a écrit :

@danrossi https://github.com/danrossi Merci pour votre commentaire
"Apparemment, le problème CORS est résolu dans Safari sous macOS mais la toute dernière
mises à jour", mais je n'ai pas pu trouver d'autres détails ailleurs
en plus de votre commentaire. Savez-vous quelle version de macOS et Safari cela
marche avec? Serait-ce un "signe" qu'Apple propagera ce correctif à
iOS ?

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/mrdoob/three.js/issues/8110#issuecomment-264290616 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ANKfT8A140W4hW0YMqq3L6AP_gljY4WUks5rDzMGgaJpZM4HYtu3
.

@kfarr quelle que soit la mise à jour récente pour macOS. Les versions précédentes d'OSX et de Safari ont toujours le problème. C'est comme ça qu'Apple roule. Ils obligent les utilisateurs à mettre à jour pour obtenir des correctifs.

Confirmé que cela fonctionne comme prévu (bug corrigé) lors du test par rapport à cette URL de test à l' aide de la dernière version de macOS Sierra 10.12.1 (16B2659) Safari 10.0.1 (12602.2.14.0.7).

Le bug n'est toujours PAS corrigé dans Mobile Safari sur iOS 10.2 Public Beta 3 (14C5077b). Une version bêta 4 plus récente est disponible, mais je ne l'ai pas encore installée ou testée.

Oui, c'est toujours un problème sur IOS. Si vous utilisez des applications basées sur WebView Cordova. Il n'y a pas du tout de problème CORS, c'est la partie la plus étrange.

Hhmmmmmm.... L'emballage Cordova le répare !?! Impair...

Le 1er décembre 2016 à 18h59, "danrossi" [email protected] a écrit :

Oui, c'est toujours un problème sur IOS. Si vous utilisez des applications basées sur WebView Cordova.
Il n'y a pas du tout de problème CORS, c'est la partie la plus étrange.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/mrdoob/three.js/issues/8110#issuecomment-264333449 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ANKfT40CQRZqWYEJWmojo_Omvl38WeUlks5rD19GgaJpZM4HYtu3
.

Yes contourne toute restriction CORS et n'a même pas besoin de l'attribut crossOrigin. Espérons qu'ils ne sabotent pas cela car c'est une option.

Une idée de ce qui cause ce comportement pour Cordova WebView ? J'ai essayé de lire cette source https://github.com/apache/cordova-ios/blob/master/CordovaLib/Classes/Private/Plugins/CDVUIWebViewEngine/CDVUIWebViewEngine.m et je ne peux rien repérer de lié.

@matti777 En ce qui me concerne, tant que cela fonctionne et j'espère qu'ils ne le découvriront pas et ne le saboteront pas exprès, qu'il en soit ainsi haha.

Je dois confirmer que c'est toujours le cas sur IOS10 mais désolé. Pour l'instant, je détecte Cordova et n'essaie pas d'utiliser des sources proxy CORS. Ma fonctionnalité bascule vers les sources proxy CORS en cas de besoin.

Eh bien, je voulais dire que si je savais ce que Cordova faisait différemment avec son UIWebView, je répliquerais ce code dans ma propre application native pour avoir le support CORS pour mes vidéos html5 que j'utilise également comme textures THREE.js.

Nous utilisons des vidéos hébergées sur Vimeo et tandis que les URL publiques du formulaire :

https://player.vimeo.com/external/...

..ne fonctionne pas, les vidéos fonctionnent avec les URL vers lesquelles elles sont redirigées :

https://fpdl.vimeocdn.com/..

Peut-être que leur vimeocdn.com a une fonction de proxy inverse installée alors? Je suppose que je devrais demander à Vimeo.

Je dois dire que je suis très ennuyé par cela. Merci Steeve.

• M

Je vais essayer la solution IFRAME. Je ne sais pas trop comment faire cependant. Je crée l'élément vidéo / le canevas à partir du code (et je ne les ajoute jamais au DOM, bien sûr), alors je me demandais si quelque chose comme :

self.iframe = document.createElement("IFRAME");
self.iframe.setAttribute("src", 'https://player.vimeo.com/');
self.iframe.appendChild(self.video);

.. est assez.

Donc, euh, après avoir abandonné les textures vidéo iOS, je me suis tourné vers Android, juste pour remarquer un comportement similaire via THREE.js; ma vidéo CORS est lue (j'entends l'audio) mais la vidéo ne s'affiche pas - tout ce que j'obtiens est un écran noir. J'ai essayé cela avec THREE.js r79 et r84, tout à l'heure. La chose étrange ici est que http://krpano.com/ios/bugs/ios8-webgl-video-cors/ fonctionne très bien sur Android ?

C'est le code que j'utilise sur Android - enfin toutes les plates-formes, d'ailleurs - (s'exécutant dans une application native dans une vue Web, avec l'accélération matérielle activée et WebChromeClient installé) :

http://pastebin.com/Y1D3beti

La seule différence avec le travail WebGL brut de krpano.com est qu'ils téléchargent la texture directement à partir de l'élément vidéo à la place via un canevas - est-ce mon problème? J'aurais vraiment besoin d'effectuer un rendu via canvas pour ajouter des éléments sur et autour de l'image vidéo.

• Matti

La seule différence avec le travail WebGL brut de krpano.com est qu'ils téléchargent la texture directement à partir de l'élément vidéo à la place via un canevas - est-ce mon problème?

Peut-être? As-tu essayé de passer la vidéo directement ?

Ce ticket concerne les problèmes CORS avec Safari. Safari 10 dans macOS est complètement corrigé, même pour Dash.

IOS 10 est toujours un problème avec COR et nécessite des proxys CORS. Ou utilisez les applications Cordova Webview qui n'utilisent pas du tout les restrictions CORS.

Le navigateur de stock Android ne prend pas en charge CORS et même le proxy CORS ne fonctionne pas.

Chrome et Firefox uniquement sur Android.

Ce problème particulier n'a rien à voir avec three.js, j'en ai peur. Je n'utiliserais même pas de dessin sur toile qui laisserait tomber trop d'images.

@danrossi pouvons-nous voir ce que vous construisez ? Cela semble assez impressionnant !

Le jeu. 26 janvier 2017, 08h41, danrossi [email protected] a écrit :

Ce ticket concerne les problèmes CORS avec Safari. Safari 10 sous macOS est
complètement corrigé même pour Dash.

IOS 10 est toujours un problème avec COR et nécessite des proxys CORS.

Le navigateur de stock Android ne prend pas en charge CORS et même le proxy CORS le fait
ne fonctionne pas.

Chrome et Firefox uniquement sur Android.

Ce problème particulier n'a rien à voir avec three.js, j'en ai peur. je
n'utiliserait même pas de dessin sur toile qui laisserait tomber trop d'images.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/mrdoob/three.js/issues/8110#issuecomment-275438671 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AANbgazonmTe-yGDfgToCRVhTy_qyp_Eks5rWMy1gaJpZM4HYtu3
.

>

http://jonobr1.com/

@danrossi Safari est complètement corrigé pour vous ? Utilisez-vous le piratage proxy pour lancer Safari maintenant ? Je reçois toujours SecurityError (DOM Exception 18): The operation is insecure. sur https://krpano.com/ios/bugs/ios8-webgl-video-cors/ avec Safari 10.0.3 sur El Capitan.

@timothyallan J'ai eu trop d'autres projets sur lesquels me concentrer car je développe de nombreuses fonctionnalités de lecteur vidéo différentes. Pour autant que je sache, ils l'ont corrigé dans macOS Safari, tous les autres Safari sont des vapourware en ce qui les concerne. Je n'ai vu aucune mise à jour pour les anciens systèmes d'exploitation, même les mises à jour de sécurité.

IOS 10 est le briseur d'affaire ici et toujours le problème. J'ai dû expliquer aux gens tout le temps pourquoi cela ne fonctionnait pas et comment l'éviter.

Apple s'attend à ce que les gens mettent à jour vers de nouveaux systèmes d'exploitation et c'est définitif, je crois.

Le problème webgl avec Dash dans Safari, je vois des gouttes et des gouttes de mises à jour de statut sur ce ticket, mais dans mon test, je pense que cela fonctionnait également sous macOS.

Juste une mise à jour ici. Ces cognards ont fourni quelques incitations bien que très silencieuses tout de même.

Le correctif cors est dans la version bêta d'IOS11. IOS10 ne l'obtiendra pas.

https://bugs.webkit.org/show_bug.cgi?id=135379#c92

Nouvelle mise à jour. IOS 11 bêta sur les appareils signalés pour lesquels CORS est corrigé. Nécessite maintenant un tout nouvel appareil prenant en charge IOS 11.

Ne vous embêtez même pas avec le simulateur, il est cassé et n'a pas le correctif CORS.

https://bugs.webkit.org/show_bug.cgi?id=135379#c108

Yay!!

Le 11 août 2017 à 02h53, "danrossi" [email protected] a écrit :

Nouvelle mise à jour. IOS 11 bêta sur les appareils signalés pour lesquels CORS est corrigé. Maintenant
nécessitent un tout nouvel appareil prenant en charge IOS 11.

https://bugs.webkit.org/show_bug.cgi?id=135379#c108

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/mrdoob/three.js/issues/8110#issuecomment-321742658 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ANKfT5TG41uHQV8U_FrF8LaJ0EMKKIy_ks5sW_pjgaJpZM4HYtu3
.

La confirmation de CORS est corrigée dans IOS 11.1. Je viens enfin d'avoir le budget pour acheter un périphérique matériel à tester. Cela a pris si longtemps.

Il n'y a pas besoin de proxy CORS avec 11.1. Je ne pense pas que la prise en charge des attributs CORS puisse être correctement testée avec Safari. Doit faire des vérifications de version client.

Il y a cependant des problèmes majeurs de régression HLS/webgl à résoudre maintenant.

Super. Merci!

Le 5 novembre 2017 à 01h36, "danrossi" [email protected] a écrit :

La confirmation de CORS est corrigée dans IOS 11.1. Je viens enfin d'avoir le budget pour obtenir
un périphérique matériel pour les tests. Cela a pris si longtemps.

Il n'y a pas besoin de proxy CORS avec 11.1. Je ne pense pas que l'attribut CORS
le support peut être correctement testé avec Safari. Avoir à faire la version client
chèques.

Il y a cependant des problèmes majeurs de régression HLS/webgl à résoudre maintenant.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/mrdoob/three.js/issues/8110#issuecomment-341952485 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ANKfT52MncuxghqJmPes4iFoO1a_K_Gfks5szVd1gaJpZM4HYtu3
.