别让延迟毁了你的长尾："dref MP4 "缓存介绍

本文来自DEMUXED，演讲者是Boy van Dijk，是来自Unified Streaming的流解决方案工程师，介绍了一种用于大规模的、动态打包的、按需交付远程存储内容的优化MP4。

优化MP4主要由实时打包和远程储存组合而来。在这种场景下，在S3上有远程的储存空间，实时打包器和客户之间有CDN来获得受欢迎的内容。

远程储存空间的流行有很多原因，相对便宜，有很高的吞吐量，并且有无限大的存储空间。但是一个缺点就是延迟，和一套本地SSD相比，一旦延迟开始累加，就会开始影响开机延迟。

接着展示了解决方案：在MP4内存储其索引。这个索引告诉我们所有媒体数据位于文件的哪里，对于progressive MP4，索引位于Moov，对于fragmented MP4，索引位于Mfra或Sidx。它们一般位于文件的开头或者结尾。对于分散的资源，ftyp可以用来查询轨迹，moov可以获取轨迹的元数据，sidx或mfra可以读取索引，moof和mdat可以获取分块的元数据和内容。当我们想要运行大规模的部署时，我们更可能希望实时打包器是“无状态的“，这意味着每个请求需要的是完全一样的信息，这将影响我们的长尾内容。长尾内容占视频内容的80%，却只获得了20%的请求。

下面要介绍的就是优化这些长尾内容的交付。解决方案是智能缓存，它在远程储存空间和实时打包器之间。为什么智能？是因为使用dref MP4格式。dref代表数据参考（data reference），也是MP4中的一个盒子。dref MP4指向源文件中的媒体数据，并包含源文件的元数据，这意味着它是轻量级的，且易于缓存。它像是实时打包器和远程资源的中间人。值得注意的是一个dref MP4文件非常小，如果你看一个几个G的电影，dref MP4可能只有几十M。另一个要强调的是dref MP4并不是捆绑于某个特定的缓存方案，你可以根据需求使用最合适的缓存方案。

接着展示了一组平均请求时间对比，无缓存的MPD/Init/Media ：1160ms/184ms/240ms，dref MP4缓存的MPD/Init/Media：16ms/13ms/160ms。此外还能够增加10%到20%的吞吐量。这就是dref MP4的全部缓存设置，它能够降低长尾内容启动延时，提升整体效率。最后介绍了三个应用场景：碎片化的MP4即时转换为渐进式的MP4；即时内容合并；定时元数据的即时交织。

以下为演讲者的介绍：

如今，在大规模的按需视频流中，许多设置都依赖于一个及时打包器来提供远程存储的MP4内容。不幸的是，这种存储后端的延迟可能是不理想的，及时打包器需要向源内容发出相对较多的请求来动态打包。这将影响打包器的整体性能，以及客户在请求一个还没有缓存在CDN上的流（即长尾内容）时的启动延迟。

在我的演讲中，我将提出如何通过使用一种新颖但符合规范的方法来打包MP4，从而最大限度地减少对远程存储后端的请求数量。从本质上讲，这是关于生成一个额外的MP4，作为打包者和源内容之间的中介。这个MP4不包含媒体数据，只是使用MP4的 "dref "框引用源内容。这个'dref MP4'确实包含的是原始轨道的索引信息（样本表），存储在'moov'框中。这是一个及时包装机需要处理每一个传入的请求的小而重要的信息位。

通过省略原始媒体数据，dref MP4变得非常小，可以很容易地缓存在一个反向代理缓存中，它位于及时打包器和远程存储后端之间。也可以将其存储在打包机本身的本地。无论是哪种方式，这种方法都将确保及时打包器能够更快地访问它需要经常访问的信息。

这种方法的影响是相当大的。在我对Unified Origin、Unified Streaming的及时打包器的测试中，一个MPD（DASH客户端清单）的生成速度快了70倍（因为它包含了一个流中所有轨道的时间线，一个打包器a需要读取每个轨道的索引信息）。包装一个媒体段时的收益要小得多，但仍然相当显著，提高了1.5倍。同时，打包器的总体吞吐量也提高了约10-20%。

在我的演讲中，我将通过对Unified Origin向存储后端提出的相对较多的请求的细枝末节进行解释，解释这些请求各自的用途，让听众更透彻地了解一般的及时打包机的内部运作，以及具体的Unified Origin，同时也向他们介绍dref MP4的概念，根据我迄今为止的经验，这将是一个大多数人从未听说过的格式。

有了这种独特的技术洞察力、实际收益和对一种新型MP4的介绍，我认为这个讲座将特别服务于Demuxed的观众。我也希望你能做到。

最后附上演讲视频：