梅元喬 姜忠鼎

1(復旦大學上海市數(shù)據(jù)科學重點實驗室 上海 201203)2(復旦大學軟件學院 上海 201203)

0 引 言

虛擬現(xiàn)實被稱為“下一代通用計算平臺”，它使用計算機創(chuàng)建出逼真的三維立體虛擬場景，用戶可以與虛擬環(huán)境進行交互，從而得到強烈的沉浸感。現(xiàn)有的虛擬現(xiàn)實呈現(xiàn)設備主要包括頭戴式顯示設備和多投影顯示設備。頭戴式顯示設備在用戶左右眼前的屏幕中顯示帶有視差的立體圖像，并根據(jù)用戶的頭部運動實時呈現(xiàn)相應視角的畫面內(nèi)容。頭戴式顯示設備的缺點在于只能單個用戶佩戴，難以多人參與，并且一般為單機驅(qū)動，容易出現(xiàn)性能瓶頸。多投影顯示設備使用LCD拼接屏和投影機陣列構建大尺寸的顯示屏幕，可通過集群驅(qū)動解決單機性能有限的問題，具有視角廣、分辨率高、支持多人參與的優(yōu)點。

全景視頻觀看是虛擬現(xiàn)實的重要應用場景，其將全空間的三維場景映射到二維空間中，用戶無需搭建三維場景即可體驗身臨其境的沉浸感。目前超高清全景視頻拍攝及生成技術快速發(fā)展，Insta360最新VR相機Titan已支持11K 2D及10K 3D全景視頻的拍攝。超高分辨率也對視頻編碼和傳輸技術提出了挑戰(zhàn)，傳統(tǒng)的編碼方式已不再能滿足VR全景視頻超高分辨率的需求。大部分VR顯示設備的呈現(xiàn)區(qū)域有限，因此全景視頻中大量內(nèi)容無需顯示，針對這一特點，研究者使用分塊編碼[1-3]和FOV傳輸[4-6]的策略節(jié)約視頻解碼和網(wǎng)絡傳輸?shù)拈_銷，從而實現(xiàn)超高分辨率全景視頻的流暢播放。

新一代的視頻編碼標準HEVC提供了tile機制，允許將視頻按照橫向和縱向劃分成多塊，每個分塊可獨立解碼。Misra等[2]從并行化和MTU兩個方面詳細討論了如何利用HEVC中的分塊機制提高解碼和傳輸效率。應用實例方面，許多研究者基于HEVC的分塊機制實現(xiàn)了全景視頻的分塊編碼和傳輸系統(tǒng)。Skupin等[3]實現(xiàn)了面向VR頭盔的全景視頻的視口自適應編解碼策略，為視口區(qū)域提供高分辨率碼流，非視口區(qū)域則提供低分辨率的碼流。Zare等[4]使用分塊的策略優(yōu)化全景視頻的傳輸效率，為每個視頻準備兩個不同碼率的版本，播放時用戶FOV范圍內(nèi)的圖像以高碼率傳輸，F(xiàn)OV外的圖像則以低碼率傳輸。Corbillon等[5]擴展了上述方法，設計了一種視口自適應的全景視頻流式傳輸系統(tǒng)，每個視頻的多個版本不僅碼率不同，還在不同區(qū)域的質(zhì)量上存在差異，視頻的部分區(qū)域質(zhì)量高于該視頻的其他區(qū)域，客戶端播放時選擇碼率合適且能為其視口區(qū)域提供全質(zhì)量呈現(xiàn)的視頻版本。

但是現(xiàn)有的研究還存在一些問題。視頻每幀內(nèi)容從解碼到顯示需要一段時間，很可能解碼和顯示時的可見分塊列表不相同，導致某些需要呈現(xiàn)的分塊尚無內(nèi)容。為此許多研究者對視角運動軌跡進行預測，以提高分塊可見性檢測的準確率，如Fan等[7]利用頭部運動信息和視頻內(nèi)容構建神經(jīng)網(wǎng)絡進行預測。然而可見分塊預測的準確率無法達到100%。針對該問題，現(xiàn)有的方案[3-5]基本都采用低分辨率圖像的方案處理。頭戴式顯示設備中僅單人觀看視頻，視線集中于視口中央?yún)^(qū)域，但是多投影顯示設備支持多人參與，因此屏幕邊緣區(qū)域呈現(xiàn)內(nèi)容不清晰將嚴重影響用戶體驗。

HEVC對視頻幀隨機訪問的支持較弱，視頻跳轉(zhuǎn)到某個需要補償?shù)姆顷P鍵幀分塊時需要較長的解碼時間。此外，多投影顯示通過集群驅(qū)動以及拼接融合技術可達到很高的分辨率，而HEVC視頻的分辨率上限只有8K。針對這些問題，已有的研究實現(xiàn)了一種基于JPEG圖像序列的視頻幀切分編碼格式[11]，每幀均可獨立解碼，以一定的壓縮率為代價，降低了分塊視頻的隨機訪問延遲，從而縮短分塊預測錯誤時補償解碼的等待時間。此外JPEG分塊編碼不存在分辨率上限，可以滿足多投影顯示的需求。然而視頻播放過程中需要補償解碼的分塊數(shù)量過多時，依然會造成播放卡頓。

基于上述討論，本文實現(xiàn)了一種面向多投影顯示的全景視頻分塊編碼方法，減少單機的性能開銷。實驗結果表明，該分塊編碼格式可以有效地提升多投影顯示設備中高分辨率全景視頻播放的流暢度。

1 基于JPEG圖像序列的全景視頻分塊編碼

全景視頻有許多不同的映射方式[9-10]，目前最主流的是等量矩形投影(Equirectangular Projection，ERP)，也被稱為經(jīng)緯圖。本文的分塊編碼方法針對ERP全景視頻。

傳統(tǒng)的視頻編碼方式每幀以整幅圖片為單位進行編碼，但是對于全景視頻而言，由于顯示設備的呈現(xiàn)范圍有限，每幀圖像中大量區(qū)域無需顯示，卻依然占用了解碼和渲染的計算資源，導致播放性能降低。將視頻每幀的圖像數(shù)據(jù)分塊編碼，播放時僅解碼和渲染可見分塊是解決該問題的基本思想。如視頻共有N個分塊，所有分塊交集為空，并集為視頻全部內(nèi)容，第i個分塊包含的數(shù)據(jù)量為Si，則視頻每幀所需處理的總數(shù)據(jù)量T如下：

(1)

(2)

1.1 立體全景視頻分塊編碼

本文的全景視頻分塊編碼方法提供了對左右立體、上下立體和左右分離三種立體格式的支持，編碼時左右眼畫面均采用完全相同的分塊方式。對左右立體和上下立體而言，每個分塊由其左右眼的畫面按照左右或上下排列的方式拼合而成，每個分塊的畫面依次存儲。對左右分離格式而言，左眼和右眼的每個分塊單獨編碼，存儲時首先依次寫入左眼所有分塊，然后依次寫入右眼所有分塊，如圖1所示。

圖1 左右分離立體全景視頻分塊編碼示意圖

立體顯示方面常見的技術包括被動立體和主動立體。被動立體的多投影顯示系統(tǒng)中，單機僅需解碼和渲染單眼畫面，而左右分離的全景視頻僅需讀取和解碼單眼的分塊數(shù)據(jù)，可以顯著提升多投影顯示系統(tǒng)的播放效率。對于主動立體的多投影顯示系統(tǒng)，則可使用左右立體或上下立體減少需要解碼的分塊數(shù)量。

1.2 雙分辨率視頻流動態(tài)適配

全景視頻觀看視角旋轉(zhuǎn)時，可見分塊列表實時變化。雖然JPEG圖像序列降低了分塊視頻的隨機訪問延遲，但是當需要補償解碼的分塊數(shù)量過多時，依然會造成播放卡頓。因此本文的分塊編碼格式添加了雙分辨率流適配機制：每幀數(shù)據(jù)除了包含所有分塊的原分辨率圖像，還包含一幅未分塊的低分辨率圖像，存儲于每幀分塊數(shù)據(jù)的末尾，如圖2所示。

圖2 雙分辨率視頻流示意圖

播放器解碼預測可見的分塊圖像以及該幅低分辨率圖像。主線程每幀渲染之前獲取需要補償解碼的分塊列表，然后使用預測算法計算補償解碼的總時間，如預測時間小于一定閾值則進行補償解碼，否則在未解碼的區(qū)域呈現(xiàn)低分辨率圖像，避免當前幀卡頓。該機制可以在不明顯降低視頻播放流暢度的同時，為用戶盡可能提供高分辨率的視頻內(nèi)容。

1.3 非均勻分塊編碼

一般而言，較小的分塊可以減少視口相同時所需解碼和渲染的數(shù)據(jù)量，但是分塊數(shù)量過多也會造成額外的指令開銷。本文的分塊編碼格式在已有的均勻分塊基礎上，添加了非均勻分塊的支持。在某些實際應用場景下，如視頻極點附近存在重要內(nèi)容，或者多投影顯示的屏幕參數(shù)與視頻邊界不匹配時，非均勻分塊可以帶來更好的性能。而在其他情況下，非均勻分塊與均勻分塊的播放性能接近。

本文的分塊編碼方法支持橫向和縱向的非均勻劃分。如視頻總分辨率為W×H，橫向按照(x1,x2,…,xm)的比例劃分成M塊，縱向按照(y1,y2,…,yn)的比例劃分成N塊，bpp為每個像素所占的字節(jié)數(shù)，則第i行第j列的分塊包含的數(shù)據(jù)量Si,j如下：

(3)

(4)

Si,j=Wj×Hi×bpp

(5)

2 分塊參數(shù)確定流程

經(jīng)本文研究，多投影顯示系統(tǒng)中全景視頻分塊編碼的參數(shù)需綜合考慮以下因素確定：單機視口范圍、屏幕尺寸、視頻內(nèi)容、解碼和渲染指令本身的開銷。下面給出分塊參數(shù)確定的整體流程：

(1) 根據(jù)解碼和渲染指令本身的開銷確定分塊總數(shù)的上限；

(2) 根據(jù)單機視口范圍確定視頻水平方向的劃分數(shù)量和均勻度；

(3) 根據(jù)視頻內(nèi)容預測用戶的觀看興趣點；

(4) 根據(jù)觀看興趣點和屏幕尺寸確定垂直方向的劃分數(shù)量和均勻度。

整個流程中，步驟(1)與硬件有關，需要通過測試進行估算。集群系統(tǒng)中每個節(jié)點的視口范圍一般較為接近，因此水平方向可均勻劃分。所以實際應用過程中應著重考慮步驟(3)和步驟(4) 確定分塊參數(shù)。本節(jié)將通過兩個實例具體說明。

實例1：全景視頻在興趣點集中于極點附近，如某些標志性高大建筑。由于ERP的像素分布是不均勻的，將其映射到球幕空間時，極點附近的像素密度遠高于赤道附近，因此視角旋轉(zhuǎn)到極點附近時會覆蓋更多的分塊。如圖3所示，一個8K(7 680×3 840)的全景視頻采用4×3的均勻分塊，每個分塊大小為1 920×1 280，RGB格式大約占7.5 MB的空間。對于同樣大小的FOV，極點附近覆蓋了4個視頻分塊，需處理7.5×4=30 MB的數(shù)據(jù)，而赤道附近只覆蓋了2個視頻分塊，需處理7.5×2=15 MB的數(shù)據(jù)，因此可能出現(xiàn)赤道附近視頻流暢播放，而極點附近視頻掉幀的現(xiàn)象。

(a) 視角位于赤道附近 (b) 視角位于極點附近圖3 均勻分塊策略下相同大小的FOV 在不同視角下覆蓋的視頻分塊

對此我們可以調(diào)整豎直方向的分塊均勻度，以減少極點附近的解碼開銷。如圖4所示，該8K的全景視頻橫向依然均勻分四塊，縱向則按照1∶2∶1的比例分為三塊，因此第1、3行的分塊大小為1 920×960，RGB格式大約占6 MB的空間，第2行的分塊大小為1 920×1 920，RGB格式大約占12 MB的空間。此時極點附近覆蓋4個視頻分塊，需處理6×4=24 MB的數(shù)據(jù)，而赤道附近占2個分塊，需處理12×2=24 MB的數(shù)據(jù)?？梢钥吹酵瑯邮?列3行的分塊，此時極點和赤道附近所需處理的數(shù)據(jù)量相同。

(a) 視角位于赤道附近 (b) 視角位于極點附近圖4 非均勻分塊策略下相同大小的FOV 在不同視角下覆蓋的視頻分塊

實例2：全景視頻的興趣點集中于赤道附近，用戶觀看時視角主要在水平方向旋轉(zhuǎn)。此時可使用縱向非均勻分塊使屏幕顯示區(qū)域與屏幕所覆蓋的分塊區(qū)域盡可能吻合。圖5(a)中一個8K的全景視頻采用4×3的均勻分塊策略，每個分塊大小為1 920×1 280，RGB格式大約占7.5 MB的空間。屏幕顯示區(qū)域覆蓋了2個分塊，需處理7.5×2=15 MB的數(shù)據(jù)。而圖5(b)中，該視頻按照縱向1.5∶1∶1.5的比例分塊即可使得赤道區(qū)域的分塊在縱向上覆蓋整個屏幕。此時，赤道附近的分塊大小為1 920×960，RGB格式大約占6 MB的空間，需要處理的總數(shù)據(jù)量為6×2=12 MB<15 MB。

(a) 4×3均勻分塊 (b) 4×3非均勻分塊圖5 針對屏幕尺寸的非均勻分塊優(yōu)化

3 分塊全景視頻轉(zhuǎn)碼生成工具

針對上述全景視頻分塊編碼格式，本文實現(xiàn)了相應的視頻轉(zhuǎn)碼生成工具。對于點播全景視頻，我們實現(xiàn)了離線轉(zhuǎn)碼工具，預先將其轉(zhuǎn)碼成分塊全景視頻格式的文件；而對于直播視頻，我們實現(xiàn)了實時轉(zhuǎn)碼組件，將網(wǎng)絡直播流實時轉(zhuǎn)碼為分塊全景視頻格式的內(nèi)存數(shù)據(jù)流。本文使用FFmpeg+JPEG-Turbo對進行視頻轉(zhuǎn)碼：首先使用FFmpeg解碼出RGB視頻幀，然后根據(jù)配置將該視頻幀劃分成多個分塊，接下來使用JPEG-Turbo對每個視頻幀分塊進行壓縮，最后組成一幀分塊編碼格式的視頻數(shù)據(jù)。該轉(zhuǎn)碼工具的整體框架如圖6所示。

圖6 分塊全景視頻轉(zhuǎn)碼生成工具框架圖

離線轉(zhuǎn)碼方面，本文實現(xiàn)了一套可視化轉(zhuǎn)碼工具，用戶輸入原視頻路徑、分塊全景視頻輸出路徑、立體格式、分辨率、壓縮質(zhì)量、編號區(qū)間以及分塊配置等信息，將原視頻轉(zhuǎn)碼為自定義分塊視頻文件格式，如圖7所示。該自定義視頻文件由Header和Payload兩部分組成：Header部分包含視頻的基本信息(分辨率、幀率、時長)、分塊配置信息以及視頻跳轉(zhuǎn)表，其中跳轉(zhuǎn)表的每個表項存儲了某一幀號視頻數(shù)據(jù)在整個文件中的偏移量，視頻跳轉(zhuǎn)時檢索該表即可；Payload部分則依次存儲了視頻每一幀每個分塊的數(shù)據(jù)。

圖7 自定義分塊視頻文件格式示意圖

實時轉(zhuǎn)碼組件可將直播視頻流根據(jù)分塊配置實時轉(zhuǎn)碼為分塊全景視頻內(nèi)存流。實時轉(zhuǎn)碼對性能有很高的要求，如視頻的幀率是30 fps，那么平均每幀的轉(zhuǎn)碼時間就不能高于33 ms，因此我們需要對轉(zhuǎn)碼效率進行優(yōu)化。實時轉(zhuǎn)碼由直播流解碼和分塊圖像壓縮兩個步驟組成。直播流解碼由FFmpeg完成，一般使用解碼流水線進行優(yōu)化，該技術已經(jīng)較為成熟。分塊圖像壓縮方面，本文使用并發(fā)壓縮技術優(yōu)化轉(zhuǎn)碼性能。

本文使用線程池進行分塊圖像的并發(fā)壓縮。最常用的線程池數(shù)據(jù)結構基于生產(chǎn)者消費者模式設計，如圖8所示。線程池維護一個任務隊列，存儲需要執(zhí)行的任務列表，并對外提供添加任務的接口。線程池初始化時創(chuàng)建若干線程，每個線程從任務列表中獲取任務并執(zhí)行。這種方案實現(xiàn)簡單，邏輯清晰，但是用在超高清視頻幀的并發(fā)壓縮上卻存在內(nèi)存占用過高的問題。本系統(tǒng)中，任務列表中的每個任務存儲了未壓縮的RGB格式數(shù)據(jù)，由于全景視頻的分辨率很高，RGB格式數(shù)據(jù)占用的空間很大，如一個8K×4K的視頻，每幀數(shù)據(jù)需要占用大約100 MB的空間，如果任務列表容量為8，CPU邏輯核心數(shù)為12，那么在轉(zhuǎn)碼過程中該線程池最高可能占用(8+12)×100 MB=2 GB的內(nèi)存空間，而整個流媒體服務器的FFmpeg解碼、網(wǎng)絡傳輸模塊都需要使用大量內(nèi)存。系統(tǒng)運行時，內(nèi)存空間較少的機器將使用虛擬內(nèi)存機制將部分內(nèi)存轉(zhuǎn)移到磁盤，從而導致整個系統(tǒng)性能下降。

圖8 基于生產(chǎn)者消費者模式的線程池

針對這一問題，本文采用了另一種內(nèi)存池的設計方式：內(nèi)存池不再維護一個任務列表，而是直接管理線程，如圖9所示。線程池維護一個線程隊列，初始化時創(chuàng)建與CPU邏輯核心數(shù)相同的線程到線程隊列中。當需要壓縮一個視頻幀時，從線程隊列中取出一個線程，將該視頻幀的壓縮計算設置為其當前任務；每個線程完成其壓縮任務后，將自己重新添加到線程隊列中。這種策略雖然設計上較為復雜，但是其內(nèi)存占用不會超過(12+1)×100 MB=1 300 MB，相比于前一個方案顯著優(yōu)化了內(nèi)存使用。

圖9 內(nèi)存優(yōu)化的線程池

4 實 驗

4.1 實驗環(huán)境

本文搭建了多投影顯示系統(tǒng)對該全景視頻分塊編碼格式進行實驗。實驗使用的多投影顯示系統(tǒng)采用被動立體技術，使用兩臺計算機分別負責左右眼的畫面渲染，操作系統(tǒng)和硬件配置如表1所示。每臺計算機連接3臺投影機，使用多投影校正技術拼接融合出完整連續(xù)的畫面，投影到一個高2.6米、半徑4米的120°柱面屏幕上。用戶站在該柱面屏幕前，佩戴偏振立體眼鏡觀看超高清的全景視頻。

表1 多投影顯示系統(tǒng)顯示節(jié)點的操作系統(tǒng)和硬件配置表

本文使用Insta 360 Pro全景相機搭建全景視頻直播流實驗環(huán)境。該相機支持4K@30 fps的全景視頻直播流拍攝，局域網(wǎng)內(nèi)可通過RTMP協(xié)議獲取直播流數(shù)據(jù)。直播流實驗使用的網(wǎng)絡硬件設備為千兆以太網(wǎng)。

4.2 實驗結果與分析

對該分塊編碼全景視頻的整體播放效果進行實驗，圖10展示了該多投影顯示系統(tǒng)中使用被動立體技術播放8K 3D全景視頻的效果圖。

圖10 8K 3D全景視頻播放效果圖

表2給出了該多投影顯示系統(tǒng)中不同分辨率分塊編碼全景視頻的播放幀率，所有視頻均為4×4均勻分塊。實驗結果表明點播視頻從6K到12K均可流暢播放，直播方面則可流暢播放Insta 360 Pro相機實時拍攝的4K@30 fps全景視頻。

表2 不同分辨率分塊全景視頻播放幀率統(tǒng)計表

下面對本文分塊編碼方法的各個技術細節(jié)進行實驗。首先對分塊的隨機訪問效率進行實驗，使用FFmpeg進行HEVC視頻的解碼，除了軟解碼，F(xiàn)Fmpeg還支持CUVID硬解碼，因此我們比較HEVC軟解碼、HEVC硬解碼和本文JPEG圖像序列解碼三種情況下視頻分塊隨機訪問的開銷。

測試視頻的總分辨率為7 680×3 840@29.97 fps，4×4均勻分塊，每個分塊大小為1 920×960，HEVC視頻的關鍵幀間隔為1秒。我們在0～4秒之間隨機采樣100次，記錄三種情況下從開始跳轉(zhuǎn)到解碼出相應視頻幀的時長，實驗結果如圖11所示?？梢钥吹?，JPEG圖像序列方案的隨機訪問解碼時長遠低于HEVC軟解碼，并且比HEVC硬解碼要穩(wěn)定許多。因此JPEG圖像序列的編碼方式可以有效降低隨機訪問的延遲，縮短分塊預測錯誤時補償解碼的等待時間，從而在不明顯影響播放流暢度的前提下，給用戶呈現(xiàn)高清晰度的視頻畫面。

圖11 不同解碼方式隨機訪問開銷折線圖

分塊策略方面，我們測試使用分塊編碼與否對視頻播放性能的影響。使用離線轉(zhuǎn)碼工具生成4K(3 840×1 920)、6K(5 760×2 880)、8K(7 680×3 840)、10K(9 600×4 800)、12K(11 520×5 760)五種不同分辨率的分塊編碼全景視頻，幀率均為29.97 fps，每種視頻包含未分塊和4×4均勻分塊兩個副本。虛擬相機的視口大小根據(jù)柱面屏幕參數(shù)計算得到。圖12展示了不同視頻分辨率下，使用分塊編碼與否對視頻播放幀率的影響?？梢钥吹?，視頻分辨率不超過8K時，不論是否使用分塊編碼，視頻均可按照視頻本身的幀率(29.97 fps)播放；而當視頻分辨率達到10K及12K時，非分塊的視頻播放幀率明顯下降，而4×4均勻分塊的視頻仍然可以流暢播放。因此分塊編碼可以顯著提高超高清(10K及以上)全景視頻的播放性能。

圖12 不同分辨率及分塊編碼啟用與否條件下 視頻播放幀率折線圖

分塊均勻性方面，第2節(jié)討論了兩種非均勻分塊帶來更佳播放性能的實例，這里分別進行測試。首先測試全景視頻在興趣點集中于極點附近的情況。我們將一部8K(7 680×3 840)@ 29.97 fps的全景視頻轉(zhuǎn)碼為均勻4×3和非均勻4×3兩種分塊編碼全景視頻，其中非均勻分塊的縱向比例為1∶2∶1，如圖13所示。該視頻的興趣點為埃菲爾鐵塔塔尖，主要位于北極點附近。分塊全景視頻的分辨率和幀率與原視頻相同，虛擬相機的視口大小根據(jù)柱面屏幕參數(shù)計算得到。

(a) 4×3均勻分塊 (b) 4×3非均勻分塊圖13 均勻分塊與非均勻分塊示意圖1

圖14展示了兩種均勻性配置下，觀察視角為赤道附近和極點附近解碼100幀的總時間，歐拉角分別為(0,0,0)和(180,0,0)?？梢钥吹?，非均勻分塊在極點附近的解碼時間低于均勻分塊策略。此外非均勻分塊極點和赤道附近的解碼時間相差較小，而均勻分塊策略則相差較大。因此非均勻分塊優(yōu)化了視角位于極點附近的播放性能，使得極點與赤道附近的解碼時間變得均勻。

圖14 兩種分塊均勻性配置下不同視角解碼時間柱狀圖

另一實例中，全景視頻的興趣點集中于赤道附近，用戶觀看時視角主要在水平方向旋轉(zhuǎn)，此時可根據(jù)屏幕尺寸定制分塊參數(shù)。我們將8K(7 680×3 840)@ 29.97 fps的全景視頻轉(zhuǎn)碼為均勻4×3和非均勻4×3兩種分塊編碼全景視頻，其中非均勻分塊的縱向比例為1.5∶1∶1.5，如圖15所示。分塊全景視頻的分辨率和幀率與原視頻相同。視口大小由屏幕尺寸計算得到，視口的朝向為全景視頻球幕空間的正中央赤道區(qū)域。表3展示了屏幕尺寸一定時，這兩種分塊均勻度配置條件下解碼100幀的總時間?？梢钥吹?，縱向1.5∶1∶1.5非均勻分塊策略的解碼時間低于均勻分塊。因此針對屏幕尺寸定制非均勻分塊配置可以在不增加分塊數(shù)量的條件下優(yōu)化播放性能。

(a) 4×3均勻分塊 (b) 4×3非均勻分塊圖15 均勻分塊與非均勻分塊示意圖2

表3 屏幕尺寸相同時兩種分塊均勻性配置下解碼時間表

分塊配置4×3均勻分塊4×3非均勻分塊解碼時間/s2.031.61

最后我們測試第3節(jié)介紹的并發(fā)壓縮機制對實時轉(zhuǎn)碼性能的影響。我們使用一臺Intel(R) Core(TM) i7-8700K CPU @ 3.70 GHz，6核12線程的機器作為硬件設備。非并發(fā)模式下創(chuàng)建單個線程串行壓縮，并發(fā)模式下則創(chuàng)建12個并發(fā)的壓縮線程。圖16展示了不同直播流分辨率下使用并發(fā)壓縮與否對轉(zhuǎn)碼時長的影響，縱軸為服務器轉(zhuǎn)碼100幀視頻數(shù)據(jù)的總時間，其中3 840×3 840分辨率的直播流幀率為24 fps，其余為30 fps。與解碼視頻文件不同的是，直播流按照其幀率生成視頻幀，因此轉(zhuǎn)碼速度不會超過直播流的幀率。可以看到，分辨率較低時并發(fā)與串行壓縮的效率差別不大，分辨率較高時并發(fā)壓縮顯著提高了實時轉(zhuǎn)碼的效率。

圖16 不同分辨率下并發(fā)壓縮與串行壓縮轉(zhuǎn)碼時長折線圖

5 結 語

本文針對多投影顯示設備的特點，設計并實現(xiàn)了一種面向多投影顯示的全景視頻分塊編碼方法，減少單機的性能開銷。該方法以已有的JPEG分塊編碼研究[11]為基礎，添加對立體全景視頻分塊編碼的支持，實現(xiàn)雙分辨率視頻流動態(tài)適配機制，保證視角變化時視頻的流暢播放；添加非均勻分塊編碼的支持以針對實際需求定制分塊參數(shù)，優(yōu)化播放性能。最后，本文使用FFmpeg和JPEG-Turbo開源庫實現(xiàn)了該分塊全景視頻的轉(zhuǎn)碼生成工具，支持離線轉(zhuǎn)碼和實時轉(zhuǎn)碼兩種方式，分別用于點播視頻和直播視頻。實驗結果表明，該分塊編碼策略可以有效地提升多投影顯示設備中高分辨率全景視頻播放的流暢度。未來將繼續(xù)優(yōu)化該分塊全景視頻轉(zhuǎn)碼、傳輸、解碼和渲染等各個模塊的性能，以支持更高分辨率全景視頻的流暢播放。