如何生成具有高性能（最小I / O）的“ mdat之前的Moov” 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. 如果文件系统提供了一个快速的“ prepend”选项将新的块添加到文件块链的开头，那将是很棒的。（我认为这还没有被发明。）
4. 将MP4生成为两个文件-一个“ mdat”文件（包含实际媒体帧）和一个“ moov”文件（包含ftyp标头和moov数据）。如果将这两个文件连接起来，将产生有效的moov-first MP4文件。一个简单的Web服务器模块可以向用户显示一个虚拟的.mp4文件，但在后台读取.moov和.mdat文件。

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

Answer 1

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