视频格式对比&mp4的moov信息分析

MP4封装中的moov信息

moov是metadata container，存放着视频的信息，mp4的结构如下：

我们重点关注，track中的stbl信息，track可以有多个，一般是一路流一个，比如包含声音和图像，那就是两个track。
在stbl中，我们主要关注几个stss，stts，ctts，stsc，stsz，stco

• stss，同步sample表，标识了媒体流中的关键帧，提供随机访问点，如果都是关键帧，则该项不存在
• stts，sample时长信息，提供时间和sample的映射关系，音频track中该项和同步参数有关，async=1是该项很小
• ctts，时间合成偏移表，如果解码顺序和显示顺序一致，则不会出现该项，不一致时会出现，一般来说B帧会影响该表，没有B帧时该表不存在。
• stsc，sample to chunk，为了优化数据访问，多个sample会封装到一个chunk中，该项标识了封装信息，一般和时长有关，可能可以通过参数指定优化该项大小，暂时还不确定。
• stsz，sample的大小表，和时长以及帧率有关，如果指定了默认的sample size，该项会不存在，暂时未找到如何指定
• stco，chunk偏移量表，一般和时长以及帧率有关。

下面列举了一个视频再不同时长以及不同帧率下的moov大小信息，经过测试，发现和分辨率影响不大，部分使用了async=1，bf=0，原始视频为4.74G，150分钟，测试视频是从中截取的两段，分别为60分钟和30分钟

从上表中可以看出，总体来说视频track的大小和帧的总数有关，音频和视频长度有关系，其他相关信息暂不明确。而且stco的影响因素还不太清楚，导致该项会出现较大差别，音频stco在fps=25时增大了，在不同sample_rate的情况下也会不同。

点播场景视频封装格式对比

主要对比一下几种封装格式（非编码格式），主要针对点播场景，不考虑直播场景，因为直播最主要的是时延问题。

• mp4，一套用于音频、视频信息的压缩编码标准，由ISO和MPEG制定。广泛支持
• flv，Adobe提出的一种流媒体格式，需要flash支持，ios不支持，http-flv支持http传输
• hls，Apple提出的流媒体协议，http传输，支持动态自适应，广泛支持
• dash，MPEG提出的，http传输，动态自适应，国外支持的较多。国内还在推广阶段，有的cdn已经支持dash，而且dash各大公司均有参与，比较中立。
  

mp4

• 单一文件，将音视频流封装到一个文件中，方便管理和下载
• 基本上是通用标准，几乎被所有的设备、服务端、cdn等支持
• 拖动方便，只需要服务器支持range
• 文件头（moov）信息随着视频长度的增加而增加，而播放器会先处理完头信息才会播放，短视频影响不大，长视频会导致开始播放前等待时间过长，影响秒开
• 考虑到会下载文件头，比较适合短视频处理场景
• 关于fmp4，不需要moov进行初始化，所以moov会比较小，metadata信息在每一段的moof中，有些播放器可以播放，但是有一些需要加载完全部fmp4才可以播放。可以作为hls和dash的分片。
  

flv

• 封装格式简单，单一文件，不需要大的文件头
• 加载速度极快，方便秒开
• pc端支持度较高，app端支持不足，h5可以用js软解
  

hls

• 动态自适应
• 对视频切片，可以秒开
• 拖动相应快
• ts文件过多会造成服务器文件碎片化，难于管理
• m3u8文件需要不断变更（直播，点播影响不大）
• http请求，广泛支持
  

dash

• 动态自适应
• 对视频切片，可以秒开
• 拖动相应快
• 基于模板情况下mpd可以不更新，直接缓存。
• 国外主流视频站点都支持，国内还在推广中，bilibili支持
• 国外主流cdn支持，国内阿里云cdn和网宿支持等都支持
  

mp4虚拟hls技术

• 将mp4文件映射为一个个小的ts文件，基于hls播放时，动态将ts文件记录的range从mp4中取出，拼装成真正的ts返回播放，优点是不需要下载文件头，实现秒开，同时mp4文件仍旧作为整体存在

下面就一些方面对比这几种格式：