La demande d’élément vidéo HTML5 est en attente pour toujours (sur chrome)

(Ce bogue existe toujours dans Chrome 38.0.2125.111, OS X 10.10)

Cela peut être un bug de Chrome et vous pouvez le résoudre sans aucune astuce ?time-suffix Suffixe ?time-suffix , juste pour aider Chrome à libérer les sockets plus rapidement :

J’ai eu le même bug sur une présentation HTML de RevealJs, avec plus de 20 vidéos (une par diapositive, mise en lecture automatique sur le focus). Comme effet secondaire, ce problème de socket non publié a également affecté d’autres médias chargés par ajax-lazy immédiatement après la première vidéo en attente / bloquée, dans le même DOM HTML.

Suite à la réponse de Walter (voir rapport de bogue ), j’ai corrigé le problème en suivant les étapes suivantes:

1- Définissez l’atsortingbut de preload vidéo sur none :

2 – Utilisez un canplaythrough événements canplaythrough pour lire et / ou mettre en pause la vidéo une fois qu’elle est chargée et prête. Cela aide Chrome à libérer le socket utilisé pour charger cette vidéo:

 function loadVideos(){ $("video").each(function(index){ $(this).get(0).load(); $(this).get(0).addEventListener("canplaythrough", function(){ this.play(); this.pause(); }); }); } 

Apparemment, c’est un bug de Chrome. Et il n’y a rien à faire à ce sujet ATM.

J’ai signalé le problème il y a quelque temps sur le projet Chromium et il a été atsortingbué. Donc, j’espère que ce sera réglé dans un avenir proche.

Rapport de bogue: https://code.google.com/p/chromium/issues/detail?id=234779

Je ne sais pas s’il sera fonctionnel pour le moment, mais je me souviens d’avoir résolu ce problème en ajoutant un paramètre à l’URL de la vidéo, tout comme “video.mp4? T = 2123”. Bien sûr, chaque fois que vous chargez la vidéo, le paramètre doit être différent. J’utiliserais

 var parameter = new Date().getMilliseconds(); 

pour l’obtenir et l’append.

Avec cela, il y a au moins quelques mois, j’ai pu lire la même vidéo plusieurs fois sans que Chrome n’attende toujours la réponse.

J’espère que cela aide.

Ce bug existe toujours. J’utilise un lecteur vidéo HTML5 sur une seule application. Après avoir chargé environ 7 joueurs avec une pré-mise en mémoire tampon, j’ai atteint la limite et plus de vidéos ne sont chargées. J’ai trouvé une autre réponse concernant les images et j’ai été surpris de constater que cette réponse résout ce problème.

 if(window.stop !== undefined) { window.stop(); } else if(document.execCommand !== undefined) { document.execCommand("Stop", false); } 

reference: Javascript: Annuler / Stop Image Requests

J’ai trouvé ce problème lors de l’utilisation de la vidéo html5 dans un contenu dynamic tel que des carrousels, pour libérer les sockets bloqués dont vous devez décharger la source vidéo:

 var video = $('#video'); video[0].pause(); video.prop('src',''); video.find('source').remove(); video.remove(); 

Le bogue prétend être corrigé, mais je devais quand même le faire sur Chrome 42. Au moins, je pourrais toujours définir preload = “auto”.

Nous avons eu les mêmes symptômes, mais le problème était que nous appelions load() sur la même vidéo deux fois de suite: même contrôle vidéo, même source vidéo (MP4). Deux 206 demandes identiques apparaissaient dans les outils de développement, puis, après avoir changé de vidéo plusieurs fois, Chrome annulait la première demande, désactivait la lecture progressive et attendait la fin de la seconde requête.

Notez également que si vous utilisez une source MP4 et qu’elle n’est pas formatée pour la lecture progressive (ce qui signifie que l’atome MOOV est au début du fichier), vous aurez alors 1-2 demandes supplémentaires pour le fichier, ce qui le rend encore plus déroutant.