Html HTML5 视频元素请求永远挂起（在 chrome 上）
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/16137381/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
HTML5 video element request stay pending forever (on chrome)
提问by Simon Boudrias
I have a weird issue in Chrome.
我在 Chrome 中有一个奇怪的问题。
Each time I load a <video>element, chrome will start two HTTP request.
每次加载一个<video>元素，chrome 都会发起两个 HTTP 请求。
The first one will stay pending forever (I guess this is the "meta-data", "partial content" request. But the point is that it stay pending)
第一个将永远挂起（我想这是“元数据”，“部分内容”请求。但关键是它保持挂起）
The second one to the same file is ok and goes on and close after the loading is over.
同一个文件的第二个是可以的，加载结束后继续并关闭。
The problem here is that the first request stay pending until I close the browser page. So at some point, if I load multiple video, Chrome will break and stop downloading anything because every available request is occupied by these pending requests.
这里的问题是第一个请求保持挂起，直到我关闭浏览器页面。因此，在某些时候，如果我加载多个视频，Chrome 将中断并停止下载任何内容，因为每个可用请求都被这些待处理的请求占用。
I created a reduced test case here: http://jsbin.com/ixifiq/3
我在这里创建了一个简化的测试用例：http: //jsbin.com/ixifiq/3
I've check to reproduce the issue, and it is happening on both Video.jsand MediaElements.jsfrontpages. Open your network tab when loading the page, you'll see the first pending request. Then press play on the video, and you'll see the second request working, but the first one will stay pending forever.
我已经检查以重现该问题，它发生在Video.js和MediaElements.js首页上。加载页面时打开您的网络选项卡，您将看到第一个待处理的请求。然后按下视频上的播放，您将看到第二个请求有效，但第一个请求将永远处于待处理状态。
Does anyone knows a fix to this bug?
有没有人知道修复这个错误？
采纳答案by Simon Boudrias
Apparently that's a bug from Chrome. And there's nothing to do about it ATM.
显然这是 Chrome 的一个错误。与 ATM 无关。
I reported the issue a while ago on the Chromium project and it's been assigned. So hopefully it'll be fixed in near future.
不久前我在 Chromium 项目上报告了这个问题，并且已经分配了它。所以希望它会在不久的将来得到修复。
Bug report: https://code.google.com/p/chromium/issues/detail?id=234779
错误报告：https: //code.google.com/p/chromium/issues/detail?id =234779
回答by Ronan
(This bug still exists in Chrome 38.0.2125.111, OS X 10.10)
（此错误在 Chrome 38.0.2125.111、OS X 10.10 中仍然存在）
This may be a Chrome bug & you may solve it without any dummy ?time-suffixtrick, just helping Chrome releasing sockets faster:
这可能是 Chrome 的错误，您可以在没有任何虚拟?time-suffix技巧的情况下解决它，只是帮助 Chrome 更快地释放套接字：
I had the same bug on a RevealJs HTML presentation, with 20+ videos (one per slide, autoplayed on slide focus). As a side effect, this unreleased socket problem also affected other ajax-lazy-loaded medias following immediately the first pending/blocked video, in the same HTML DOM.
我在 RevealJs HTML 演示文稿中遇到了同样的错误，有 20 多个视频（每张幻灯片一个，在幻灯片焦点上自动播放）。作为一个副作用，这个未发布的套接字问题还影响了同一个 HTML DOM 中第一个挂起/阻止视频之后的其他 ajax 延迟加载媒体。
Following Walter's answer (see bug report), I fixed the issue following the next steps:
按照 Walter 的回答（请参阅错误报告），我按照以下步骤修复了该问题：
1- Set video preloadattribute to none:
1-将视频preload属性设置为none：
<video preload="none">
<source src="video.webM" type="video/webM">
</video>
2 - Use a canplaythroughevent handler to play and/or pause the video once it is loaded & ready. This helps Chrome releasing the socket used to load that video :
2 -canplaythrough加载并准备好后，使用事件处理程序播放和/或暂停视频。这有助于 Chrome 释放用于加载该视频的套接字：
function loadVideos(){
$("video").each(function(index){
$(this).get(0).load();
$(this).get(0).addEventListener("canplaythrough", function(){
this.play();
this.pause();
});
});
}
回答by Unapedra
I don't know if it will be functional right now, but I remember solving this issue by adding a parameter to the video URL, just like "video.mp4?t=2123". Of course, everytime you load the video, the parameter should be different. I'd use
我不知道它现在是否会起作用，但我记得通过向视频 URL 添加一个参数来解决这个问题，就像“video.mp4?t=2123”一样。当然，每次加载视频时，参数应该不同。我会用
var parameter = new Date().getMilliseconds();
to get it, and add it.
得到它，并添加它。
With this, at least a few months ago, I was able to play the same video multiple times without Chrome waiting forever the response.
有了这个，至少在几个月前，我可以多次播放相同的视频，而 Chrome 无需永远等待响应。
Hope it helps.
希望能帮助到你。
回答by Ecropolis
This bug still exists. I'm using an HTML5 video player on a single page application. After loading about 7 players with pre-buffering, I hit the limit and no more videos load. I found another answer having to do with images and I was surprised to find that this answer solves this problem.
这个bug依然存在。我在单页应用程序上使用 HTML5 视频播放器。在使用预缓冲加载大约 7 个播放器后，我达到了限制并且不再加载视频。我发现另一个与图像有关的答案，我惊讶地发现这个答案解决了这个问题。
if(window.stop !== undefined) {
window.stop();
} else if(document.execCommand !== undefined) {
document.execCommand("Stop", false);
}
reference: Javascript: Cancel/Stop Image Requests
回答by sidonaldson
I found this issue when using html5 video inside dynamic content such as carousels, to release the blocked sockets you have to unload the video source:
我在动态内容（例如轮播）中使用 html5 视频时发现了这个问题，要释放您必须卸载视频源的阻塞套接字：
var video = $('#video');
video[0].pause();
video.prop('src','');
video.find('source').remove();
video.remove();
The bug claims to be fixed but I still had to do this on Chrome 42. At least I could still set preload="auto".
该错误声称已修复，但我仍然必须在 Chrome 42 上执行此操作。至少我仍然可以设置 preload="auto"。
回答by Seth
We had the same symptoms, but the problem was that we were calling load()on the same video twice in succession: same video control, same video source (MP4). Two identical 206 requests showed up in the dev tools, and then, after switching video a few times, Chrome would cancel the first request, turn off progressive playback, and wait for that second request to complete.
我们有相同的症状，但问题是我们load()连续两次调用相同的视频：相同的视频控件，相同的视频源 (MP4)。两个相同的 206 请求出现在开发工具中，然后，在切换视频几次后，Chrome 会取消第一个请求，关闭渐进式播放，并等待第二个请求完成。
Also note that if you're using an MP4 source and it isn't formatted for progressive playback (meaning the MOOV atom is at the beginning of the file), then you will have 1-2 additional requests for the file, which makes it even more confusing.
另请注意，如果您使用的是 MP4 源并且它没有被格式化为渐进式播放（意味着 MOOV 原子位于文件的开头），那么您将有 1-2 个额外的文件请求，这使得它更令人困惑。
