video - 如何生成具有高性能(最少 I/O)的 "moov before mdat"MP4 视频文件？

Question

我正在设计一个服务器应用程序，该应用程序将实时 H.264 视频流存储为 MP4，供浏览器稍后使用。由于服务器需要处理尽可能多的并发流，我相信 I/O 将是自然的瓶颈，我希望将 I/O 保持在最低限度。我遇到了经典的 MP4 moov/mdat 排序问题:MP4 生成器更喜欢先写入 mdat 框(包含实际的媒体帧)，然后再写入 moov 框(包含文件偏移量和其他结构信息)，在它实际之后知道 mdat 文件的偏移量是多少。 MP4 消费者更喜欢渐进式流媒体的反面——首先读取 moov 框，这样 mdat 结构是已知的，视频可以快速开始播放而无需下载整个文件。

通常的解决方案是对 MP4 文件进行后处理，将 moov 框移动到 mdat 框之前，并相应地重写文件偏移量。但是，对于大容量应用程序，我想避免将传入的视频数据写入磁盘、将其全部读回并重新写入新安排的 I/O 损失。

想到了几种方法:

1. 像往常一样对 MP4 进行后处理，这会导致 I/O 损失并可能延迟视频的可用性。 (不好。)
2. 使用碎片化的 MP4 和适合内存的小片段大小。 (我认为这可能会对整个文件的可搜索性产生负面影响。)
3. 如果文件系统提供一个快速的“前置”选项来将新 block 添加到文件 block 链的开头，那就太棒了。 (我认为这还没有被发明出来。)
4. 将 MP4 生成为两个文件——一个“mdat”文件(包含实际媒体帧)和一个“moov”文件(包含 ftyp header 和 moov 数据)。如果将这两个文件连接起来，将生成一个有效的 moov-first MP4 文件。一个简单的网络服务器模块可以向用户呈现一个虚拟的 .mp4 文件，但在后台读取 .moov 和 .mdat 文件。

我现在倾向于#4。有没有更实用的方法来解决这个问题？

Answer 1

如果 moov 数据的大小是可估计的，则在文件开头预分配空间。其中一些可能会被浪费，但您不必重新计算任何偏移量，并且在某些情况下它会避免 I/O 成本。当 moov 数据大于您的估计时，请确保您有回退。