1

有没有人能做到这一点？我的代码如下所示：

    <video loop autoplay id="bgvid">
        <source src="/video/blueParticles.webm" type="video/webm">
    </video>

当我使用 Chrome 浏览时，它工作正常。当我使用 cefclient.exe 它工作正常。但是嵌入 ChromiumWebBrowser控件并将其指向此网页不允许它循环。它只播放一次。

4

1 回答 1

3

这个问题有点老了，但它仍然出现在谷歌搜索中，所以我想我会给它一个答案。请温柔一点，我不是专业的程序员，所以希望我的答案能被那些代码不像 XKCD 卡通的人详细说明或澄清。

首先，查看这个为我指明正确方向的答案HTML 视频不会循环播放- 要点是，如果您在 CEF 应用程序中重载 GetResponseHeaders，则必须非常小心地构建令人信服的假响应标题或视频不会循环，从链接的问题和我自己的测试看来，CEF 中的循环视频需要状态响应 206（部分数据）而不是 200（OK）。

就我而言，我使用 CefShemeHandler 将视频链接重定向到与 CEF 应用程序一起打包的本地视频文件。因此，我必须使用 GetResponseHeaders 构建自己的通用响应，以响应 200 OK 的状态（从问题中不清楚这是否是 OP 的确切情况，但即使这不是我的解决方案也应该有效）。一切正常，除了循环。当我意识到我需要回复 206 时，这也意味着我需要添加一些额外的标题。

很明显，找出 chromium 在成功响应标头的轮流中期望什么的最简单方法是简单地将其加载到 Chrome 中（注意 OP 声明该页面在 chrome 中作为普通网页运行良好），打开控制台，单击“网络”，然后单击视频文件的名称，然后单击“标题”。现在您可以准确地看到循环成功工作时使用了哪些响应和请求标头。

这里最重要的是，您会看到 Chrome 在每个循环中都会启动带有完整标头的请求/响应，即使它是从缓存中提取的！（您会在网络视图上看到除了第一个循环之外的每个循环都显示“来自缓存”）。这意味着，您的 GetResponseHeaders 重载不仅必须提供在第一个循环中有意义的信息，而且还必须提供在每个循环中都有意义的信息。

也许对 http 有更好理解的人可以准确地告诉我们标头的哪些部分是绝对重要的，但我不确定，我只是欺骗了我在响应标头下看到的所有内容。就我而言，它看起来像这样——

  Accept-Ranges:bytes
Content-Length:4470009
Content-Range:bytes 0-4470008/4470009
Content-Type: video/webm .webm
Date:Thu, 23 Jun 2016 04:12:41 GMT
Etag:"****************"
Last-Modified:Fri, 06 May 2016 06:04:57 GMT

我认为对同一文件的所有请求的 Etag 和 Last-Modified 日期必须相同，但我没有对此进行广泛测试。总的来说，一些测试让我相信重要的部分是 Content-Range 和 Content-Length。为了获得总字节数，我只计算了文件中的字节数，将其用于 Content-Length 并使用“bytes 0-(contentLength -1)/(contentLength)”作为范围似乎很简单。但是，这不起作用！

回到 Chrome，我注意到在初始请求之后，正如我在上面粘贴的那样，响应和请求开始看起来有点不同。在 Request 标头下，Range 第一次表示“bytes=0-”，之后每次（循环）都表示“bytes=442-”。如您所料，在 Response 标头下，循环中的 Content Range 看起来也不同，它表示“字节 442-4470008/4470009”，内容长度为 4469567，比总长度少 442 个字节。

因此，我只是解析了请求标头上的 Range 字符串以找到起点，因此在第一个循环的情况下为 0，在我的示例中的循环的情况下为 442，并使用它来修改我的响应标头。Content-Range 变为“bytes (startingPoint)-(contentLength -1)/(contentLength)”，Content-Length 变为 contentLength - startingPoint。之后，它循环正常——就像一个魅力，来自本地文件，没有间隙！

于 2016-06-23T14:38:30.143 回答