点播场景Mp4文件头size分析以及各式对比

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

MP4封装中的moov信息

moov是metadata container,存放着视频的信息,mp4的结构如下:
点播场景Mp4文件头size分析以及各式对比

我们重点关注,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分钟

len
fps
帧率
sr
采样率
moov
Byte
vTrack
Byte
aTrack
Byte
vStssByte vCtts
Byte
vStsc
Byte
vStsz
Byte
vStcoByte aStts
Byte
aStsc
Byte
aStsz
Byte
aStco
Byte
3600 60 44100 6364304 4251445 2112645 3716 1533144 1241200 864028 608888 815352 67780 620180 608884
3600 60 44100 4193393 2951690 1241489 3744 X 1462996 864024 620188 272 328 620248 620192
3600 25 44100 2303285 722950 1580121 1832 X 388 360148 360084 272 599068 620248 360084
3600 25 12000 1005173 666510 338449 1832 X 134944 360148 168848 272 28 168852 168848
1800 60 44100 3183328 2125817 1057297 1888 765280 621688 432028 304464 408416 33868 310104 304460
1800 60 44100 2097745 1476126 621405 1916 X 731356 432032 310084 272 400 310200 310084
1800 25 44100 1153045 362110 790721 976 X 400 180152 180084 272 299716 310200 180084
1800 25 12000 503585 333642 169729 976 X 67288 180152 84488 272 28 84492 84488

从上表中可以看出,总体来说视频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文件仍旧作为整体存在


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

视频格式 传输类型 文件类型 秒开 支持性 优势 劣势
mp4 一般http 单一 短视频可以 广泛支持 几乎是通用格式 长视频会造成文件头过大
hls http 分片 可以 广泛支持 码率自适应 长视频会造成ts文件过多
flv 一般http 单一 可以 flash 格式简单,加载速度快 多端兼容复杂,拖拽不够准确
dash http 分片 可以 H5支持,后续可能有更多支持 码率自适应,中立标准 国内使用不广泛,cdn支持度还不够
上一篇:强大!Nginx 配置在线一键生成“神器”


下一篇:IMM支持视频截帧和生成雪碧图功能