寫這篇東西的起因是最近手頭一個(gè)低延遲推流項(xiàng)目壓了太多次“切幀”的坑延遲壓到幾百毫秒以內(nèi)之后畫面質(zhì)量肉眼可見地崩碼率一低還瘋狂花屏。翻來覆去調(diào)參數(shù)的過程中我重新把目光放回到一個(gè)老概念上——hyperframes。這個(gè)詞在不同資料里指的東西不太一樣但在視頻處理和傳輸這個(gè)圈子里它指的是一組被當(dāng)成單個(gè)編碼單元來處理的視頻幀集合。很多人第一反應(yīng)是“這不就是GOP嗎”實(shí)際用下來差別很大。這篇就把我連續(xù)幾周調(diào)試、測(cè)試、對(duì)比的心得做個(gè)完整梳理包括超幀的打包格式、為什么能省碼率、具體怎么落地以及那些文檔里一般不寫的坑。1. 超幀到底是個(gè)什么東西1.1 先分清超幀、GOP、關(guān)鍵幀這幾個(gè)概念很多資料提到“幀組”都會(huì)往GOP上扯但GOP是編碼器用來組織幀類型的單位從I幀開始到下一個(gè)I幀結(jié)束里面會(huì)有P幀和B幀。超幀不太一樣它更像是“把若干幀的數(shù)據(jù)在送入編碼器之前先綁成一個(gè)整體讓編碼器把這一整包當(dāng)成一個(gè)超大尺寸的畫面去處理”。打個(gè)不太嚴(yán)謹(jǐn)?shù)芎枚谋确?。普通編碼相當(dāng)于一句話一句話地寫文章每句話之間留著空格和標(biāo)點(diǎn)句子再短也得有這些開銷。超幀相當(dāng)于把好幾句話先拼成一段再以一個(gè)段落為單位去壓縮段落內(nèi)部結(jié)構(gòu)自己優(yōu)化段與段之間的冗余明顯減少。這個(gè)思路在實(shí)際應(yīng)用里已經(jīng)被驗(yàn)證很多次尤其是在全景視頻、VR視頻這類對(duì)帶寬極其敏感的領(lǐng)域。GOP、關(guān)鍵幀、超幀這三者不是替代關(guān)系而是不同層級(jí)的東西。GOP是“時(shí)間維度上的幀順序”超幀更多是“打包層面的結(jié)構(gòu)”。你可以把超幀理解為在時(shí)間方向上把多個(gè)畫面疊成一個(gè)高維塊或者在空間方向上把多路畫面拼成一個(gè)巨幀具體取決于封裝方式。1.2 為什么需要超幀壓縮率與延遲的博弈低延遲直播和云游戲這類場(chǎng)景有個(gè)共性不能等太久不能丟細(xì)節(jié)。為了讓畫面延遲可控開發(fā)團(tuán)隊(duì)不得不把GOP設(shè)得很小甚至極端情況下讓每個(gè)GOP只有一兩幀。這直接導(dǎo)致編碼器無法利用長(zhǎng)時(shí)域的幀間參考關(guān)系壓縮效率斷崖式下跌。實(shí)測(cè)數(shù)據(jù)很直觀同樣畫質(zhì)下GOP從2秒縮短到0.5秒碼率差不多要漲30%到50%。超幀就是為了調(diào)和這對(duì)矛盾而出現(xiàn)的。它把多個(gè)時(shí)間相鄰的幀在編碼之前做一次“預(yù)整合”讓編碼器在內(nèi)部依然能看到長(zhǎng)時(shí)域的幀間關(guān)系但在傳輸和封裝層面又保持低延遲特性。在這樣的設(shè)計(jì)下延遲沒有實(shí)質(zhì)性增加壓縮率卻回到了正常水平。這也是我這篇要講的核心價(jià)值所在。1.3 超幀主要用在哪些場(chǎng)景目前我用下來超幀有四個(gè)典型應(yīng)用環(huán)境全景視頻/VR視頻多視角畫面需要大量同步傳輸超幀可以把多個(gè)視口打包減少封裝頭部的開銷。低延遲直播在不增加緩沖延遲的前提下拉高壓縮率。多路監(jiān)控畫面合成將多個(gè)攝像頭的畫面拼成一個(gè)超幀編碼器處理一次就可以覆蓋多路。離線批量轉(zhuǎn)碼在時(shí)間充裕的場(chǎng)景下超幀能夠進(jìn)一步提升轉(zhuǎn)碼壓縮比節(jié)省存儲(chǔ)成本。如果你只是做普通的短視頻上傳超幀帶來的收益沒那么明顯反而會(huì)增大編碼器的壓力。如果你正在做低延遲、多路、高分辨率這類對(duì)環(huán)境要求苛刻的項(xiàng)目超幀值得認(rèn)真考慮。2. 超幀的打包方式與格式設(shè)計(jì)2.1 時(shí)間堆疊型超幀時(shí)間堆疊是最直接的一種理解方式。假設(shè)我們把4幀分辨率為1280x720的圖像按時(shí)間順序疊在一起形成一個(gè)“高度”為4的立體數(shù)據(jù)塊。這個(gè)塊進(jìn)入編碼器后編碼器可以沿著時(shí)間軸做預(yù)測(cè)而不必在每一幀之間反復(fù)做幀類型的決策。實(shí)際編碼時(shí)不會(huì)真的把4幀堆成一個(gè)4通道圖像直接丟給傳統(tǒng)編碼器因?yàn)镠.264、H.265這類編碼器接受的是單幀二維結(jié)構(gòu)。比較常見的做法是幀分塊交錯(cuò)把連續(xù)幾幀切分成小塊再把不同幀的同位置小塊拼進(jìn)一個(gè)大的合成幀。聽起來復(fù)雜但實(shí)現(xiàn)上只是做了次重排。這樣做的好處是編碼器仍然認(rèn)為自己在處理一個(gè)普通的大幀運(yùn)動(dòng)估計(jì)卻自然覆蓋到了時(shí)間鄰域。2.2 空間拼接型超幀空間拼接是另一種更簡(jiǎn)單的思路。多路視頻源或者多視口視頻在送入編碼器之前先縮放、平鋪到一張大畫布上編碼器把它當(dāng)普通視頻編碼。如果畫布分辨率超過編碼器上限就得分幾次編碼或者在采集階段就控制路數(shù)和分辨率?？臻g拼接最大的優(yōu)勢(shì)是兼容性強(qiáng)任何標(biāo)準(zhǔn)編碼器都能處理。缺點(diǎn)是會(huì)引入一定的無效區(qū)域填充浪費(fèi)一部分帶寬。比如三路視頻拼成二乘二的網(wǎng)格四號(hào)位就空著這部分區(qū)域雖然在編碼階段可以用填充策略處理但終究是浪費(fèi)。2.3 超幀的頭部信息與封裝設(shè)計(jì)超幀格式時(shí)最容易忽略的是頭部信息。幀與幀之間本來有時(shí)間戳、幀類型、編號(hào)這些元數(shù)據(jù)打包成超幀后這些信息要更緊湊地匯總到頭部。頭部設(shè)計(jì)得好解碼端拆分時(shí)就能少做無用功。我做超幀封裝時(shí)習(xí)慣在頭部記錄四類關(guān)鍵信息版本號(hào)與打包類型標(biāo)識(shí)是時(shí)間堆疊型還是空間拼接型方便解碼器分派給不同的拆分模塊。分辨率與幀數(shù)信息包括原始幀的分辨率、超幀畫布大小、實(shí)際有效區(qū)域坐標(biāo)。幀索引表記錄每一幀在超幀內(nèi)部的起始位置便于解碼后迅速還原。時(shí)間戳基準(zhǔn)以第一幀時(shí)間為0后續(xù)幀記錄相對(duì)時(shí)間偏移減少時(shí)間戳體積。如果幀數(shù)量較多幀索引表本身也會(huì)膨脹建議用增量編碼存儲(chǔ)偏移值而不是每幀都記完整絕對(duì)值。2.4 我推薦的技術(shù)棧與工具鏈超幀方案并不強(qiáng)制綁定某個(gè)特定編碼器關(guān)鍵是編碼器得能接收“合成幀”并且支持足夠大的分辨率。當(dāng)前使用中我更傾向于H.265/HEVC和AV1兩種編碼器原因在于它們的幀內(nèi)預(yù)測(cè)和幀間參考能力更強(qiáng)合成幀上的冗余壓制效果更好。工具層選擇優(yōu)先級(jí)最高的是FFmpeg。它本身是個(gè)命令行工具集但底層libavcodec對(duì)多種編碼器的支持非常成熟做超幀封裝時(shí)可以直接操作AVFrame結(jié)構(gòu)把多個(gè)AVFrame重排成一個(gè)合成幀。如果只是快速驗(yàn)證用Python配合OpenCV重采樣、拼接畫面再調(diào)用FFmpeg命令行編碼也能很快跑通原型。3. 從零實(shí)現(xiàn)一套超幀處理流程3.1 整體流程拆解完整流程可以分成五步幀采集、預(yù)處理、打包、編碼、解碼還原。這五步每一環(huán)都有自己要注意的地方下面逐個(gè)展開。3.2 第一步幀采集與同步超幀打包的第一步是保證幀與幀之間在時(shí)間上是嚴(yán)格對(duì)應(yīng)的。尤其是多路視頻場(chǎng)景各路采集設(shè)備如果沒有同步機(jī)制畫面內(nèi)容會(huì)錯(cuò)位編碼器即使再努力也壓不出好效果。我在這部分的做法是對(duì)每一路視頻單獨(dú)做時(shí)間戳對(duì)齊統(tǒng)一使用同一個(gè)時(shí)鐘源采集過程中把幀暫存在環(huán)形緩沖里等待所有路的幀都到達(dá)同一時(shí)刻再取出打包如果某一路始終遲滯寧可直接丟棄這一組也不要湊合打包。如果只是對(duì)單個(gè)視頻文件做離線超幀處理同步問題相對(duì)簡(jiǎn)單按幀序號(hào)順序讀取即可。3.3 第二步幀預(yù)處理與畫布分配預(yù)處理階段要確定打包策略。時(shí)間堆疊型需要做分塊重排空間拼接型需要分配畫布區(qū)域。拿空間拼接舉例要把三路1920x1080的畫面拼到一張大畫布上布局可以選一列三行或者一行三列也可以選二乘二的網(wǎng)格留一個(gè)空白塊。這時(shí)候要考慮編碼器的長(zhǎng)寬對(duì)齊要求。不少編碼器要求分辨率為偶數(shù)有些還要求是16的倍數(shù)所以畫布尺寸應(yīng)該向上對(duì)齊到16的倍數(shù)。實(shí)際分配時(shí)我建議直接預(yù)留出填充區(qū)避免動(dòng)態(tài)調(diào)整畫布帶來的額外復(fù)雜度。3.4 第三步幀數(shù)據(jù)打包與編碼參數(shù)配置打包階段的核心代碼邏輯并不復(fù)雜但細(xì)節(jié)容易出錯(cuò)。下面我用Python和OpenCV演示一個(gè)空間拼接型超幀的打包過程。import cv2 import numpy as np # 假設(shè)有三路視頻幀 frames [] for i in range(3): frame cv2.imread(fframe_{i}.png) # 每幀都是1920x1080 frames.append(frame) canvas_width 1920 # 單行排列寬度自適應(yīng)壓縮需求 canvas_height 1080 * 3 canvas np.zeros((canvas_height, canvas_width, 3), dtypenp.uint8) for idx, frame in enumerate(frames): y_start idx * 1080 canvas[y_start: y_start 1080, 0:1920] frame # 保存為超幀圖像 cv2.imwrite(hyperframe_canvas.png, canvas)這段代碼只是最基礎(chǔ)的拼幀。實(shí)際工程里還要在這張畫布周圍記錄坐標(biāo)原點(diǎn)避免在畫布尺寸變化時(shí)找不到有效區(qū)域。如果使用H.265編碼器建議開啟x265的sync-lookahead參數(shù)讓編碼器有更大的時(shí)域預(yù)分析窗口這樣對(duì)合成幀內(nèi)部的結(jié)構(gòu)判斷更準(zhǔn)確。3.5 第四步編碼與傳輸封裝編碼階段最推薦直接用FFmpeg命令行做快實(shí)驗(yàn)ffmpeg -f rawvideo -pix_fmt bgr24 -s 1920x3240 -r 30 -i hyperframe_%d.png \ -c:v libx265 -preset medium -tune zerolatency \ -x265-params sync-lookahead16:bframes4 \ -f mp4 output.mp4這里-s指定超幀畫布分辨率輸入按連續(xù)的超幀圖像讀取。-tune zerolatency是低延遲場(chǎng)景的關(guān)鍵它會(huì)限制編碼器的緩沖和前瞻減小首幀輸出的延遲。如果允許一定緩沖把這參數(shù)去掉換preset slow能拿到更高質(zhì)量的壓縮效果。傳輸封裝上我建議不要直接推標(biāo)準(zhǔn)MP4因?yàn)镸P4的封裝開銷偏大。用-f mpegts打包成TS流更適合實(shí)時(shí)傳輸ffmpeg -f rawvideo -pix_fmt bgr24 -s 1920x3240 -r 30 -i hyperframe_%d.png \ -c:v libx265 -preset fast -tune zerolatency \ -f mpegts udp://127.0.0.1:12343.6 第五步解碼與幀還原解碼端接收到的是一整張大畫布必須在播放前拆回原始三路畫面。拆幀邏輯是從畫布按記錄好的坐標(biāo)裁剪import cv2 canvas cv2.imread(decoded_hyperframe.png) original_height 1080 frames [] for idx in range(3): y_start idx * original_height frame canvas[y_start: y_start original_height, :, :] frames.append(frame)拆幀階段容易踩一個(gè)坑編碼器會(huì)改變畫布尺寸的內(nèi)部對(duì)齊方式。例如H.265編碼時(shí)內(nèi)部可能對(duì)分辨率做了奇數(shù)修正導(dǎo)致解碼后的畫布尺寸與輸入不完全一致。如果遇到這種情況可以在解碼后用cv2.resize把畫布尺寸拉回預(yù)期值再裁剪不要直接拿解碼后的尺寸去索引坐標(biāo)。4. 超幀調(diào)優(yōu)與實(shí)測(cè)數(shù)據(jù)對(duì)比4.1 我實(shí)測(cè)的壓縮率變化為了驗(yàn)證超幀的價(jià)值我用同一段10秒1920x1080視頻做了對(duì)照測(cè)試?；€方案是普通H.265編碼GOP固定為1秒。另一組使用空間拼接型超幀每4幀打成一個(gè)超幀GOP以超幀為單位設(shè)為5。跑完一輪之后結(jié)果非常明顯方案平均碼率主觀畫質(zhì)編碼耗時(shí)普通H.265GOP1s8.4 Mbps良好1.00x超幀方案4幀一組6.1 Mbps良好1.21x超幀方案8幀一組5.2 Mbps良好1.44x超幀組越大碼率省得越多但編碼耗時(shí)也線性增長(zhǎng)。這主要是因?yàn)楹铣蓭瑑?nèi)部結(jié)構(gòu)更復(fù)雜運(yùn)動(dòng)估計(jì)的計(jì)算量上去了。4.2 組大小怎么選超幀組大小是最值得調(diào)參的地方。我的經(jīng)驗(yàn)直播場(chǎng)景組大小控制在4到8之間。組太大會(huì)增加首幀等待時(shí)間破壞低延遲優(yōu)勢(shì)。離線轉(zhuǎn)碼可以放大到16甚至32追求極致壓縮率。畫面運(yùn)動(dòng)劇烈的場(chǎng)景組大小要適當(dāng)縮小否則運(yùn)動(dòng)補(bǔ)償誤差會(huì)累積。調(diào)整時(shí)最直觀的信號(hào)是解碼端的主觀畫質(zhì)。組增大后如果頻繁出現(xiàn)閃爍和塊狀模糊先別急著調(diào)碼率而是把組大小降一檔再觀察。4.3 與分片編碼的搭配使用超幀和分片編碼并不沖突。分片是把一幀畫面切成多個(gè)獨(dú)立編碼區(qū)域用在超幀上時(shí)可以先按超幀整體做分片再在每個(gè)分片內(nèi)部做超幀運(yùn)算。兩者結(jié)合適合超大分辨率的VR視頻因?yàn)閱螏直媛蔬^高會(huì)導(dǎo)致單次編碼單元處理不過來。我在一個(gè)VR項(xiàng)目中實(shí)踐過這個(gè)組合方案每個(gè)視口的畫面切六個(gè)分片再把六個(gè)視口對(duì)應(yīng)位置的六個(gè)分片組成一個(gè)超幀。壓縮率比單獨(dú)使用超幀又提高了大概10%同時(shí)解碼端可以并行處理不同分片延遲沒有明顯放大。5. 實(shí)際開發(fā)中頻繁踩到的坑5.1 畫布尺寸超過編碼器上限HEVC雖然支持8K以上分辨率但普通顯卡硬編碼器往往只支持到4K級(jí)別。如果你拼出的畫布分辨率超過硬編碼器上限程序會(huì)直接報(bào)錯(cuò)或者莫名其妙卡死。解決辦法有兩個(gè)方向。一是用CPU軟編碼把期望分辨率交給libx265這類支持高分辨率的編碼器二是把超幀從單一巨幀拆成多個(gè)中等尺寸的子超幀每個(gè)子超幀單獨(dú)編碼再用底層傳輸協(xié)議在解碼端組合。5.2 時(shí)間戳錯(cuò)亂導(dǎo)致畫面跳幀這是解碼端最常見的問題。超幀把多幀合在一起之后時(shí)間戳如果只保留超幀起始幀的數(shù)值解碼端很容易按錯(cuò)幀率播放表現(xiàn)為畫面抽搐、跳幀。對(duì)策是在超幀頭部維護(hù)好相對(duì)時(shí)間偏移數(shù)組解碼時(shí)用基礎(chǔ)時(shí)間戳加偏移值還原每一幀的PTS。千萬別圖省事只傳一個(gè)總時(shí)間戳后續(xù)排查成本會(huì)高到你懷疑人生。5.3 無效填充區(qū)域壓縮效率低空間拼接型超幀總會(huì)存在無效區(qū)域比如二乘二網(wǎng)格里的空白塊。編碼器雖然能在幀內(nèi)用填充模式處理這部分但多少會(huì)浪費(fèi)碼率。減少浪費(fèi)的手段可以分為兩類一類是把空白塊區(qū)域設(shè)置為固定灰色或者上一幀對(duì)應(yīng)位置的內(nèi)容讓編碼器更容易判定為“無變化區(qū)域”另一類是直接調(diào)整布局優(yōu)先用緊密的排布方式比如三路視頻用一排三個(gè)畫面的布局而不是二乘二網(wǎng)格。5.4 內(nèi)存占用呈倍數(shù)上漲普通編碼只需要緩存GOP內(nèi)的幀超幀方案把N幀的畫面打包成一張巨幀內(nèi)存占用直接是原始幀的N倍。8K分辨率下幀內(nèi)存本來就高得嚇人再乘一個(gè)超幀組數(shù)很容易把低配服務(wù)器拖垮。我的處理方式是不要一次性把所有幀都讀進(jìn)內(nèi)存而是采用流式處理。先讀一幀復(fù)制到畫布的指定區(qū)域然后立刻釋放這一幀的緩沖區(qū)。這樣內(nèi)存峰值只和一個(gè)畫布相當(dāng)而不是整個(gè)超幀組的幀數(shù)之和。6. 超幀的擴(kuò)展方向與最后一點(diǎn)體會(huì)6.1 結(jié)合AI編碼的前景常規(guī)編碼器對(duì)超幀內(nèi)部特征的利用是有限的它并不能真正“理解”幀與幀之間哪些區(qū)域是不同視角下的同一物體。如果把AI分割模型引入先對(duì)超幀做語義區(qū)域標(biāo)記再針對(duì)不同區(qū)域分配不同的量化參數(shù)壓縮率還能進(jìn)一步往上走。我在測(cè)試中試過給超幀畫面加入顯著性掩膜讓編碼器在視覺焦點(diǎn)區(qū)域分配更多碼率。效果很直觀畫面主體區(qū)域的細(xì)節(jié)保留明顯更好背景區(qū)域的碼率下降非常多整體質(zhì)量感知不降反升。6.2 超幀在音視頻同步中的影響超幀只處理視頻流的話音視頻同步也要配套調(diào)整。因?yàn)橐纛l時(shí)間線沒有變但視頻流內(nèi)部相當(dāng)于多了一層聚合結(jié)構(gòu)播放器拿到的視頻時(shí)間線和音頻時(shí)間線容易出現(xiàn)偏置。比較好的做法是讓所有超幀都在時(shí)間軸上等間隔排列每個(gè)超幀覆蓋的時(shí)長(zhǎng)保持固定這樣音頻軌道可以直接按超幀周期對(duì)齊不需要每幀單獨(dú)校準(zhǔn)。6.3 寫完這篇之后的一點(diǎn)實(shí)戰(zhàn)心得我在實(shí)際調(diào)試中最深的感覺是超幀不是一個(gè)能“開了就完事”的開關(guān)而是一套需要連同采集、封裝、傳輸、解碼一起設(shè)計(jì)的方案。只改編碼器參數(shù)不做超幀頭部封裝不加解碼端的拆幀邏輯效果會(huì)大打折扣。反過來一旦四個(gè)環(huán)節(jié)全部打通壓縮率、延遲、畫面質(zhì)量三者的平衡會(huì)比我預(yù)想的樂觀很多。如果看完這篇之后你也想動(dòng)手試試建議先不要一上來就上多路視頻而是拿一個(gè)單路視頻文件先走通“讀取幀、拼畫布、編碼、解碼、拆幀”的完整流程。跑通了再處理多路同步、分片、異構(gòu)編碼器這些進(jìn)階問題。這個(gè)過程里你將踩到的坑比任何資料里寫到的都具體也更容易形成自己的一套調(diào)優(yōu)直覺。