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

通常的解决方案是对MP4文件进行后处理,以便在mdat框之前移动moov框,并相应地重写文件偏移量.但是,对于大批量应用程序,我希望避免将传入的视频数据写入磁盘,将其全部读回来并以新的排列再次写入的I / O代价.

我想到了几种方法：

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

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

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