如何避免在同一页面中重复重新加载 HTML 视频？
在同一页面中使用同一视频两次似乎会强制不必要的媒体重新加载。
比较加载视频和加载图像：
<img src="image.png"/>
<img src="image.png"/>
<video src="video.webm"></video>
<video src="video.webm"></video>
根据 Firefox 5 Web 控制台，这将加载图像一次，但加载视频两次。
我从 http://www.w3.org/TR/ 了解到html5/video.html#dom-media-mediagroup 规范的作者期望在这两种情况下进行一次重新加载（“引用同一媒体资源的多个媒体元素将共享单个网络请求”），但这并没有发生大部头书。
我尝试使用服务器缓存参数（我使用的是普通的 web.py），但无济于事，我怀疑这是在错误的树上吠叫。有什么我应该特别注意的吗？ HTML 元元素？
请注意，这与同一视频具有多个源的常见问题相反。在这里，我关心的是具有相同源的多个视频元素并排播放（例如在不同的时间点）。
Using the same video twice in the same page seems to force an unnecessary media reload.
Compare loading a video to loading an image:
<img src="image.png"/>
<img src="image.png"/>
<video src="video.webm"></video>
<video src="video.webm"></video>
According to the Firefox 5 web console, this loads the image once, but the video twice.
I understand from http://www.w3.org/TR/html5/video.html#dom-media-mediagroup that the spec's authors expected a single reload in both cases ("Multiple media elements referencing the same media resource will share a single network request"), but that is not happening to me.
I have tried to play around with server cache parameters (I'm using vanilla web.py), to no avail, and I suspect that's barking at the wrong tree. Is there anything specific I should be looking at? HTML meta elements?
Note that this is the opposite of common issues with having multiple sources for the same video. Here I am concerned with having multiple video elements with the same source playing side by side (e.g. at different points in time).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我认为人们误解了这里的规范。
如果您查看规范中的示例，它们会专门讨论包含多个轨道的单个资源（文件）。这两个视频元素包含对同一文件的引用，但该文件中的轨道不同。然后通过媒体组同步播放这两个曲目。
如果您有两个视频标签引用同一轨道的同一文件，我不希望它们默认同步播放。我可以想象，通过在同一个媒体组中指定它们，这可能会实现这一点，因此允许两个元素使用单个请求流的单个连接。
如果两个视频不同步播放，则期望浏览器通过单个请求集加载两个视频是不合理的。请注意，这是一个请求集，视频可能会向服务器生成许多请求，因为视频或媒体会话（认为停止、暂停和重新启动）可能比服务器或客户端愿意保持打开的单个连接长得多。
想象一下如果这两个元素有不同的控件。您暂停第一个视频并继续播放第二个视频。 30 分钟过去了，你重新开始第一个视频。浏览器根本不会缓存来自服务器的可能超过一百兆字节的内容，以使其能够在不向服务器发出新请求的情况下播放第一个视频。
如果您期望使用 HTTP 通过单个连接发送两个离散的流内容，那么我认为这是不可能的（嗯，目前已实现）。这就是多路复用，最后我检查了一下，HTTP 服务器不支持多路复用。请注意，这与连续提供多条内容的保持活动连接不同，多路复用描述的是并行提供多条内容。实现此目的的通常方法是简单地打开两个套接字，这对于客户端和服务器来说处理起来比尝试解复用单个流要简单得多。
I think people are misreading the spec here.
If you look at the example in the spec, they specifically talk about a single resource (file) that contains multiple tracks. The two video elements contain a reference to the same file, but different tracks within that file. The two tracks are then played back in sync by means of a media group.
If you have two video tags that reference the same file with the same track, I would not expect them to play in sync by default. I could imagine that by specifying them in the same media group this might achieve that, and therefore allow both elements to use a single connection with a single stream of requests.
If the two videos are not going to be playing in sync, it is unreasonable to expect the browser to load the two videos across a single request set. Note that this is a request set, a video may generate many requests to a server as a video or media session (think stop, pause and restart) may be significantly longer than a server or client is willing to hold open a single connection.
Imagine if the two elements had different controls. You pause the first video and leave the second video playing. 30 minutes go by, and you restart the first video. The browser is simply not going to have cached what might amount to over a hundred megabytes of content from the server to allow it to play the first video without making a new request to the server.
If you expect two discrete pieces of streaming content to be sent over a single connection using HTTP, then I don't believe that is possible (well, currently implemented). That would be multiplexing, and last I checked, HTTP servers don't have any support for multiplexing. Note that this is different from a keep alive connection where multiple pieces of content are served serially, what multiplexing is describing is multiple pieces of content being served in parallel. The usual way to achieve this is simply to have two sockets open, which is a lot simpler for both client and server to deal with than trying to demux a single stream.
如果您检查下载视频的大小，他们是否都下载了完整视频？
在我的测试中，大多数浏览器会下载一小块（足以显示拇指），然后在需要时下载完整视频 - 所以我想知道您是否将其算作两次完整下载，而实际上它只是一个完整下载和一个部分的。
我在 6 月份在 Bruce Lawson 的帮助下做了一些测试，我们发现某些浏览器执行的负载甚至比我上面描述的两个浏览器还要多。
HTML 5 视频输入现实生活（测试）
If you check the size of the downloaded video, are they both downloading the full video?
In my tests, most browsers download a small chunk (enough to display the thumb) and then the full video when needed - so I'm wondering if you are counting that as two full downloads, when it is actually only one full download and one partial.
I did some tests in June with the help of Bruce Lawson and we discovered that some browsers perform even more loads than the two I've described above.
HTML 5 Video In Real Life (Tests)
如果您使用 Html 5，那么最好使用 Canvas。它将加载视频一次。
If you are using Html 5, then better you can go with Canvas. It will Load the video once.
这项工作：
This work:
您当然可以将视频放入缩略图中，并在有人单击它们时加载它们，如果您找不到其他内容，这可能会有所帮助。
You could of course put the videos in thumbnails and have them load when someone clicks on them, it might help if you can't find something else.
听起来这是您正在使用的浏览器中的一个错误，因为它显然不遵守 W3C HTML 5 规范。我建议您为该浏览器的开发人员提交错误报告并进行测试，以了解此行为与其他浏览器的比较。
Sounds like this is a bug in the browser you're using, since it's apparently not adhering to the W3C HTML 5 specification. I would recommend you file a bug report for that browser's devs and test to see how this behavior compares with other browsers.
我认为这是因为您没有在服务器中启用 webm 或 mp4 资源缓存，可以检查您的请求标头以查看
cache-control是否存在。I think it's because you not enabled webm or mp4 resource caching in your server, can check your request header to see if the
cache-controlexist.