量化视频封装的成本
不必要的封裝信息占用了可觀的空間，如果能優(yōu)化這些封裝信息，就能進一步壓縮視頻，提升用戶的觀看體驗。本文來自Mux科技博客，LiveVideoStack對原文進行了摘譯。
文 / MatthewSzatmary
譯 / John
原文：
https://mux.com/blog/quantifying-packaging-overhead-2/
Mux可使您就像調(diào)用單個API一樣輕松在您的應(yīng)用或網(wǎng)站上添加視頻，實現(xiàn)這種簡易操作需要多項可分析視頻內(nèi)容并將其轉(zhuǎn)換為具有出色播放兼容性的媒體文件或數(shù)據(jù)流的處理步驟，這些步驟一般都十分繁瑣且龐大，我們將其按一定順序組成的集合稱為媒體處理流程。
?
處理流程主要是對每個音頻或視頻幀執(zhí)行的一系列數(shù)據(jù)分析或轉(zhuǎn)換。不同階段對應(yīng)不同的幀處理步驟，某一階段步驟結(jié)束之后下一階段步驟被執(zhí)行操作，多步驟所組成的簡化處理流程如下圖所示：
這些步驟中的每一個都值得深度發(fā)掘，但今天我們主要關(guān)注處理流程中經(jīng)常被忽視的一項——封裝。
?
封裝器的主要工作是獲取音頻和視頻編碼器的輸出并插入如果按照正確速率播放媒體所需的時間戳與信令等信息，同時還要確保音頻與視頻的同步性。最終得到被封裝在“容器”中的文件或流并允許播放器成功打開與訪問數(shù)據(jù)，如mp4或HLS格式文件。
?
幾年前，Apple在HLS中添加了對分片mp4文件的支持，但并非所有設(shè)備都能獲得這一新特性。因此，大多數(shù)流仍然使用較舊的傳輸流（通常稱為TS）格式。TS似乎是一種令人費解的格式，但對于廣播或有線電視領(lǐng)域的從業(yè)者來說這種格式無處不在。而無處不在也意味著硬件解碼器普遍對TS有良好的兼容性與支持，如果讓我推測，這也就是為什么Apple在第一代iPhone中普遍選擇TS而非HLS，以及為什么TS在今天仍然非常普遍。
?
TS有一些不同尋常的特性。由于其本質(zhì)上是為以太網(wǎng)之前的世界構(gòu)建，包括丟失、亂序數(shù)據(jù)封裝檢測以及遠程時間同步等數(shù)字無線廣播必需的功能在互聯(lián)網(wǎng)上僅需借助TCP與每個設(shè)備中的高精度時鐘之間的協(xié)作即可處理；除此之外，TS還使用188字節(jié)的固定封裝大小，每個封裝包以同步字節(jié)開始，以便于識別初始封裝。（這種設(shè)計如果用于在隨機位置加入多條播放的數(shù)據(jù)流，即可獲得良好效果，例如切換電視頻道時；但就像HLS的情況一樣，這對于通過HTTP拉取數(shù)據(jù)流并以文件形式保存視頻的互聯(lián)網(wǎng)視頻傳輸來說并非必需。而不使用這些功能的缺陷就是存儲空間被白白占用。對于具有高碼率的文件而言這不是問題，但對處于低帶寬環(huán)境中的服務(wù)來說，卻意味著高昂的成本。
?
每個188字節(jié)的TS包具有4字節(jié)的標頭（header）。該標頭包含同步字節(jié)、一部分標志位、封裝的ID（或具有唯一標識的音頻或視頻流 PID）以及連續(xù)性計數(shù)器（用于識別丟失或無序的包）。然后每個幀都有一個前置的Packetised基本流（PES）標頭。PES標頭最少為14個字節(jié)（如果幀解碼時間與呈現(xiàn)時間不匹配，則為19個字節(jié)，即B幀），并會對幀時間戳進行編碼等。因此，第一個數(shù)據(jù)包最多可用170個字節(jié)，而后續(xù)數(shù)據(jù)封裝包有184個字節(jié)可用。如果幀少于170個字節(jié)，則必須對其進行填充以使用完整數(shù)據(jù)包。如果幀是171字節(jié)，則需要第二個數(shù)據(jù)封裝包，因此需要376個字節(jié)（188x2）來傳輸171個字節(jié)的有效負載，這會將所需帶寬增加一倍以上。實際上，170字節(jié)以下的幀并不常見。但是，在1Mbps以下的比特率下，10％或更多的（Overhead）開銷并不罕見。
一個現(xiàn)實世界的例子
?
我們拍攝了一段測試視頻，使用以下命令通過FFmpeg將其編碼為HLS：
最終組合流大小為58196152字節(jié)，封裝開銷（overhead）為6.24％。考慮到2.13％（184/188）是理論上的最小值且折扣PES標題和填充，實際表現(xiàn)并沒有那么糟糕。
但我們能做得更好嗎？如果可以，我們希望節(jié)省的碼率可用于降低緩沖以改善視頻質(zhì)量繼而改善用戶體驗。但任改善實踐的第一步是確定如何衡量封裝開銷。已注冊的Apple開發(fā)人員可以訪問HTTP Live Streaming Tools等工具，這些工具存在兩個問題：第一是僅支持MacOS，第二是最新版本似乎不再顯示封裝開銷。為了解決這個問題，我們開源了我們的muxincstreamvalidator工具（https://github.com/muxinc/hlstools）。盡管在編寫初期，此工具僅報告封裝開銷，但其后續(xù)版本中可能會擴展更多功能。以上是用于衡量FFmpeg封裝開銷的工具。
為減少封裝開銷，我們可以利用編碼媒體碼流的一些屬性。大多數(shù)音頻編解碼器使用固定的采樣率和per-frame的采樣數(shù)進行編碼。AAC音頻則固定每幀使用1024個樣本。因此，在48000Khz時，每幀持續(xù)21?毫秒。因為幀持續(xù)時間可以由解碼器確定而其中不包含來自PES幀頭的時間戳，所以我們可以為每個PES標頭打包多于一個的音頻幀，從而減少PES開銷與最小化幀的最終TS分組所需的填充。但是，這里的視頻幀中并沒有可導(dǎo)出的時間戳，因此打包不起作用。MPEG視頻編解碼器確實包含用于識別每個幀的第一個字節(jié)，被稱為起始碼的特定比特序列。因此，解碼器不需要容器發(fā)送信號以通知每幀開始時流中的確切位置。當有一個小于184字節(jié)的最終有效載荷需要填充時，我們可以截斷那些額外的字節(jié)，采用零填充策略并將字節(jié)前進到下一幀。不幸的是，對于170字節(jié)以下的視頻幀，我們?nèi)匀粺o法做到這一點。
Mux的代碼轉(zhuǎn)換器使用但不限于使用這些技術(shù)以將開銷降至最低。我們將相同的 tears_of_steel_720p.mp4?視頻攝取到Mux的muxincstreamvalidator工具中并測量其開銷。
傳輸流包含4個PID，其中PID 0始終是程序關(guān)聯(lián)表（PAT），其編碼節(jié)目映射表（PMT）的PID在這種情況下為4096；PMT對音頻（257）和視頻（256）流的PID進行編碼，由于不包含媒體只包含元數(shù)據(jù)，PAT和PMT的開銷為100％。最終流為55330092字節(jié)，開銷為3.32％。理論最小值更接近2.12％。
為了確保這是一個同類比較，我們使用FFmpeg重新混合Mux編碼流并測量結(jié)果。
FFmpeg包含一個額外的“服務(wù)”PID（17），除了額外1713244字節(jié)的開銷，其他看上去差別不大類似。
?
我們嘗試了一項實驗，通過增加既定百分比的碼率生成相似且效率較低但視頻質(zhì)量得到明顯改善的封裝文件，最終結(jié)果的VMAF評分低于3分，我們可以認為這改善了視覺質(zhì)量。因此，通過節(jié)省一部分處理來改善網(wǎng)絡(luò)環(huán)境較差的網(wǎng)絡(luò)邊緣地區(qū)用戶的產(chǎn)品使用體驗似乎是一項不錯的選擇。
LiveVideoStack 招募
?LiveVideoStack正在招募編輯/記者/運營，與全球頂尖多媒及技術(shù)專家和LiveVideoStack年輕的伙伴一起，推動多媒體技術(shù)生態(tài)發(fā)展。了解崗位信息請在BOSS直聘上搜索“LiveVideoStack”，或通過微信“Tony_Bao_”與主編包研交流。同時，我們也歡迎通過業(yè)余時間向LiveVideoStack貢獻內(nèi)容。LiveVideoStackCon2019北京正在招募講師，點擊【閱讀原文】了解詳細信息。
總結(jié)
- 上一篇： UCloud裴志伟：最小价值模型，技术迭
- 下一篇： 性能可期——Netflix与Intel优