【问题标题】:Google Chrome audio seeking and bufferingGoogle Chrome 音频搜索和缓冲
【发布时间】:2015-12-04 03:33:24
【问题描述】:

当尝试播放 MP3 文件时,谷歌浏览器首先将音频文件从开始加载到搜索点,然后才从搜索点开始播放。如何告诉 Chrome 禁用缓冲无用的音频文件并立即从搜索点播放音频,而不是从头开始缓冲?

我在根 body 中有一个 audio 标记。除了id,没有任何属性——没有srctype等——完全为空的audio标签。

我有很多players(Angular 指令),它们使用这个audio 标签进行播放(因此,当我导航到另一个站点的页面时,音频不会停止)。

每个player 都有自己的搜索栏——我可以随时点击搜索栏开始播放音频。音频的播放会在所有最新的浏览器中立即开始......好吧,不是在 Chrome 中——Chrome 首先从开始到搜索点预加载丢失的音频块,然后才播放音频。

有一些我提出的请求的屏幕截图 - Chrome 和 FF(这里每个玩家都被设置为 currentTime 在搜索栏中从 25:01 分钟开始播放):

Chrome 首次 GET 请求(当audio 标签获得src 属性时):

Chrome 的第二个 GET 请求(当 audio 标签将 currentTime 设置为 25 分钟时):

Firefox 第一个 GET 标头(当 audio 标签获取 src 属性时):

Firefox 第二个 GET 请求(当 audio 标签将 currentTime 设置为 25 分钟时):

因此,当audio 获得src 时,它会发送第一个 GET 请求以加载一些元数据和其他信息。然后它发送第二个 GET 请求,因为音频 currentTime 发生变化。

默认情况下,Chrome 总是在第一个请求时发送 «Range: bytes=0-» 标头,没有什么可以改变它。 (FF 在第一个请求中发送 «Range: bytes=491520-»。)

那么,我做错了什么?也许我需要更多来自服务器响应的标头? :)

【问题讨论】:

    标签: javascript html google-chrome audio


    【解决方案1】:

    我认为这是 Chrome 的回归,据我们的团队今天/昨天在最新的 Chrome 稳定版本中可以看出,这已经被打破了。

    如果你看一下 SoundCloud,它今天也有这个问题。

    以前,如果您在音频文件中有 Xing 标头,它会修复它并正确搜索,但它停止工作。

    【讨论】:

    • 好吧,在 Chrome Canary 版本 47 中它的行为是一样的 :(
    猜你喜欢
    • 2011-06-01
    • 2017-09-28
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-09-07
    • 1970-01-01
    相关资源
    最近更新 更多