【问题标题】:How can HTML5 video's byte-range requests (pseudo-streaming) work?HTML5 视频的字节范围请求(伪流)如何工作?
【发布时间】:2013-08-13 06:08:35
【问题描述】:

如果您为托管在接受范围请求的服务器上的视频播放 HTML5 视频,那么当您尝试寻找视频的非缓冲部分时,您会从网络流量中注意到浏览器发出字节范围请求。我假设浏览器通过提前知道总视频大小并假设比特率恒定来计算字节(如果您在进度条中单击一半,那么它将在中途点请求字节)。但特别是如果视频是可变比特率的,它请求的字节似乎不太可能真正对应于用户点击的时间点,并且字节很可能落在帧的中间。

一旦开始获取某个任意字节,浏览器如何知道下一帧的开头是什么?

【问题讨论】:

  • 我已经尝试回答下面的问题..看看它是否有帮助。

标签: video video-streaming html5-video video-processing


【解决方案1】:

我假设您的视频位于 Mp4 容器中。 mp4 文件格式包含“盒子”的层次结构。其中之一是 Time-To-Sample (stts) 框。此框包含每一帧的时间(以紧凑的方式)。从这里您可以使用 Sample-to-Chunk (stsc) 原子找到包含帧的“块”。最后,块偏移原子 (stco) 为您提供文件中的字节偏移量。

电影的总时长存储在 Movie header atom (mvhd) 中。当您移动拖拽手柄时,会根据影片的时长和您松开拖拽手柄的位置来估算时间,根据之前下载的文件头进行计算,并发出请求。

编辑: 如果不是 mp4,其他容器也有类似的机制。编解码器无关紧要。

【讨论】:

  • 这个答案对我来说最有说服力,但我并不完全相信这确实是浏览器的做法。我完全同意可以这样做。澄清一下,我发现这个博客很有帮助:thompsonng.blogspot.com/2010/11/mp4-file-format.html 如果你说的是正确的,那么即使在可变比特率的超大视频中寻找,也应该完全准确?另外,您是否有任何参考资料证明浏览器正在使用 moov atom(stts、stsc、stco 数据)进行搜索?
  • 个人喜欢直接上源码。即 ISC/IEC 14496-12。或较旧的“QuickTime 文件格式”文档。是的,我确信这就是浏览器对 mp4 的处理方式,因为这是在 mp4 中查找的唯一方法。
  • 您不能遍历 mdat,因为音频和视频块是交错的,没有指示一个块何时停止而另一个块何时开始。唯一的文档将是浏览器源代码。请注意,每个浏览器都可能使用某种媒体抽象。所以浏览器将简单地调用 seekToTime() 并且媒体层将确定需要发送哪些 HTTP 请求。
【解决方案2】:

许多视频/媒体类型(例如 MPEG)都以固定相同的数据包编码。

MPEG 最初是在 188 字节数据包上设计的(最初选择为 ATM 传输层的 8 个信元,但现在已经过时了)。因此,如果您寻求 188 字节大小的倍数,播放器将在找到帧开始时读取有效数据包并恢复同步。

当浏览器/播放器到达可以独立于任何其他帧解码的 I 帧(或关键帧)时,可以显示实际图片。 P 帧和 B 帧是插值,所以如果你寻找它们,你还不能构建图片。

见:

【讨论】:

  • h.264 怎么样?另外,我不清楚这如何适合框架。如果请求从帧的中间获取数据包怎么办?它如何知道帧边界在哪里以便它可以正确地继续播放?
  • 帧被标记,以便您可以在数据包流中寻找并恢复同步。播放器通常会阅读并跳过,直到找到“完整图片”帧开始。如果您想研究数据包大小,请自行 Google H.264..
  • 不正确。只有 HTTP Live Streaming 使用传输流。使用 HLS,时间定位由清单 (m3u8) 文件确定,并下载整个段。没有字节范围。
  • 问题是,在获取任意字节后如何知道下一帧的开始。我的回答回答了这个问题。当然,浏览器最好在几秒钟内请求一个位置并让服务器解决它。但这不是问题所要问的。
  • 为什么投反对票?技术上正确,回答了有关字节偏移 -> 帧的问题,并提供了规范的链接。
猜你喜欢
  • 1970-01-01
  • 2017-05-22
  • 2013-03-27
  • 1970-01-01
  • 1970-01-01
  • 2021-07-07
  • 1970-01-01
  • 2016-09-29
  • 1970-01-01
相关资源
最近更新 更多