【问题标题】:How should frames be packed in a live WebM stream?应该如何将帧打包到实时 WebM 流中?
【发布时间】:2015-11-29 16:22:54
【问题描述】:

我正在通过 libvpx 使用 VP9 对实时流进行编码,并希望将其流式传输到 HTML5 播放器。我已经阅读了Matroska specificationW3C WebM Byte Stream Format 并检查了几个由libvpx 的vpxenc 工具生成的WebM 文件。一切看起来都不错,但是我找不到任何关于如何将编码的视频帧打包到 W3C 规范中描述的媒体段内的严格规则或指南。

据我了解,我必须发出包含内部带有块元素的集群的媒体片段。据我了解,我可以为从编码器获得的每一帧使用一个简单的块元素,因为它有一个时间戳。但是如何组织集群呢?对我来说,使用单个简单的块条目为每个帧发出一个集群以减少缓冲和延迟是有意义的。这种方法被认为是正常的还是这样做有什么缺点,我应该缓冲一段时间,然后发出一个包含多个简单块元素的集群,覆盖缓冲的时间段?

更新

所以我实现了所描述的方法(通过单个简单的块条目发出集群)并且视频似乎滞后很多,所以大概这不是要走的路。

【问题讨论】:

    标签: webm live-video vp9


    【解决方案1】:

    我认为答案取决于您要寻找的延迟类型。您描述的方法将起作用,但会引入延迟。这通常不是直播的问题,因为直播的目标不是低延迟,而只是直接传输。 (事实上​​,在某些情况下,延迟是想要的,即使它仍然是直播。)

    如果低延迟是目标,您应该研究诸如 RTP 之类的东西。并不是说使用 webm 容器不可能,只是这不是容器的目标,所以你会发现大多数工具以不关心低延迟的方式实现 webm,因为你不会使用它为了这个目的;你会改用 RTP。

    (如果相反,延迟是指它卡顿,请务必提及,因为这表明正在发生一些不同的事情。)

    【讨论】:

    • 如前所述,目标是流式传输到原生 HTML5 视频元素,因此 RTP 不是一个选项。是的,我的意思是滞后,在我看来,即使我正确标记了包含关键帧的块,视频在 vlc、ffplay 和浏览器中缓冲了很长时间(可能他们期望一个具有多个帧的集群?)。
    【解决方案2】:

    所以我终于设法多路复用 ar 工作直播。

    似乎我描述的初始方法(具有单个SimpleBlock 的单个集群)实际上是这样工作的,但它有几个缺点:

    关键帧应该放在簇的开头

    • 如果实时流使用 curl 或其他方式存储在本地文件中,它会破坏可能的搜索。据我了解,集群应该由完整的 GOP 组成。

    我最初的假设之一是集群不能有“未知”大小,但实际上 Chrome、VLC 和 ffplay 似乎对此感到满意,因此无需缓冲完整的 GOP 来确定大小和集群可以即时发射。

    另一个重要方面是SimpleBlock 元素中的时间戳是有符号的 16 位整数,因此您基本上可以将集群时间码的偏移量编码到 32767。因此,如果您使用 1 个滴答为 1 毫秒的默认时间刻度,这意味着集群不能超过 32 秒。如果 GOP 规模很大,则在决定是否发出新集群时也必须考虑此标准。

    最后,here 是一个直播链接(“Big Buck Bunny”预告片,但采用直播格式),该链接似乎适用于所有玩家,并根据上述说明生成。

    希望这些信息对任何人都有帮助。

    【讨论】:

    • 我一直在尝试流式传输通过 mediarecorder 录制的 webm 视频,并在另一端使用媒体流进行流式传输。工作正常,但当一些从流中间加入时它不起作用。请问你有同样的例子吗
    • @TarunRawat 您是否尝试过在新客户加入时强制关键帧?你用的是封闭的gop还是无限的?
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2016-07-17
    • 2017-03-26
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-02-04
    • 1970-01-01
    相关资源
    最近更新 更多