web-dev-qa-db-fra.com

La demande d'élément vidéo HTML5 reste en attente pour toujours (sur Chrome)

J'ai un problème étrange dans Chrome.

Chaque fois que je charge un <video> élément, chrome démarrera deux requêtes HTTP.

La première restera en attente pour toujours (je suppose que c'est la demande "métadonnées", "contenu partiel". Mais le fait est qu'elle reste en attente)

Le second dans le même fichier est correct et continue et se ferme une fois le chargement terminé.

Le problème ici est que la première demande reste en attente jusqu'à ce que je ferme la page du navigateur. Donc, à un moment donné, si je charge plusieurs vidéos, Chrome va casser et arrêter de télécharger quoi que ce soit, car chaque demande disponible est occupée par ces demandes en attente.

J'ai créé un cas de test réduit ici: http://jsbin.com/ixifiq/

J'ai vérifié pour reproduire le problème, et cela se produit sur les deux fronts Video.js et MediaElements.js . Ouvrez votre onglet réseau lors du chargement de la page, vous verrez la première demande en attente. Appuyez ensuite sur lecture sur la vidéo et vous verrez la deuxième demande fonctionner, mais la première restera en attente pour toujours.

Quelqu'un connaît-il un correctif à ce bogue?

html5google-chromehtml5-videomediaelement.jsvideo.js
41
Simon Boudrias

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é attribué. J'espère donc que ce sera corrigé dans un avenir proche.

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

14
Simon Boudrias

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

Cela peut être un Chrome et vous pouvez le résoudre sans aucun mannequin ?time-suffix astuce, juste aidant Chrome libérant les sockets plus rapidement :

J'ai eu le même bug sur une présentation HTML RevealJs, avec plus de 20 vidéos (une par diapositive, lue automatiquement sur le focus de la diapositive). En tant qu'effet secondaire, ce problème de socket non publié a également affecté d'autres médias chargés par ajax-lazy 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 résolu le problème en suivant les étapes suivantes:

1- Définissez l'attribut video preload sur none:

<video preload="none">
    <source src="video.webM" type="video/webM">
</video>

2 - Utilisez un gestionnaire d'é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();
            });
    });
}
21
Ronan

Je ne sais pas s'il sera fonctionnel en ce moment, mais je me souviens 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'ajouter.

Avec cela, il y a au moins quelques mois, j'ai pu lire plusieurs fois la même vidéo sans Chrome en attendant pour toujours la réponse.

J'espère que cela aide.

9
Unapedra

Ce bogue existe toujours. J'utilise un lecteur vidéo HTML5 sur une application d'une seule page. Après avoir chargé environ 7 joueurs avec une pré-mise en mémoire tampon, j'ai atteint la limite et plus aucune vidéo ne se charge. 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);
}

référence: Javascript: Annuler/Arrêter les demandes d'images

8
Ecropolis

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

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

Le bug prétend être corrigé, mais je devais toujours le faire sur Chrome 42. Au moins, je pouvais toujours définir preload = "auto".

6
sidonaldson

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 demandes 206 identiques sont apparues dans les outils de développement, puis, après avoir changé de vidéo plusieurs fois, Chrome annulerait la première demande, désactiverait la lecture progressive et attendrait que cette deuxième demande soit terminée) .

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

1
Seth