點播場景Mp4檔案頭size分析以及各式對比視訊格式對比&mp4的moov資訊分析

視訊格式對比&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分鐘

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

從上表中可以看出，總體來說視訊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檔案仍舊作為整體存在

下面就一些方面對比這幾種格式：

視訊格式	傳輸類型	檔案類型	秒開	支援性	優勢	劣勢
	一般http	單一	短視訊可以	廣泛支援	幾乎是通用格式	長視訊會造成檔案頭過大
	http	分片	可以		碼率自适應	長視訊會造成ts檔案過多
				flash	格式簡單，加載速度快	多端相容複雜，拖拽不夠準确
				H5支援，後續可能有更多支援	碼率自适應，中立标準	國内使用不廣泛，cdn支援度還不夠