一種按行交錯(cuò)劃分任務(wù)和數(shù)據(jù)的多核并行視頻解碼方法
【技術(shù)領(lǐng)域】
[0001] 本發(fā)明涉及視頻編碼技術(shù)領(lǐng)域，特別涉及運(yùn)用多核數(shù)字信號(hào)處理器DSP芯片完成 高清視頻編解碼及傳輸?shù)亩嗪瞬⑿幸曨l解碼方法以及多核并行時(shí)負(fù)荷分?jǐn)偂?zhí)行等待和阻 塞以及高速緩存的優(yōu)化措施。
【背景技術(shù)】
[0002] 上世紀(jì) 80 年代 3C (Computers, Communications, Consumer Electronics)的相互 滲透與融合催生了多媒體技術(shù)并且推動(dòng)多媒體技術(shù)飛速發(fā)展與普及。視頻編碼是多媒體技 術(shù)中的關(guān)鍵技術(shù)。近年傳輸視頻清晰度不斷提升，同時(shí)視頻編碼標(biāo)準(zhǔn)頻繁更新?lián)Q代，還不 斷涌現(xiàn)新內(nèi)容。2002年CIFH. 263在會(huì)議電視設(shè)備中尚占據(jù)主流。2005年就出現(xiàn)了 720P H. 264。到2009年1080P會(huì)議電視設(shè)備已為市場(chǎng)主推產(chǎn)品。這個(gè)時(shí)刻離1080P隨Sony PS2 游戲機(jī)和藍(lán)光產(chǎn)品上市的時(shí)刻并不遙遠(yuǎn)。存儲(chǔ)介質(zhì)和雙向?qū)崟r(shí)網(wǎng)絡(luò)傳輸兩類應(yīng)用對(duì)視頻編 碼提出的壓縮比和實(shí)時(shí)性要求相差甚遠(yuǎn)，僅單純實(shí)時(shí)解碼和實(shí)時(shí)編解碼就相差2倍以上運(yùn) 算量。這么短時(shí)間一下邁上這么高臺(tái)階，完全得益于處理器芯片技術(shù)的飛躍！目前實(shí)時(shí)傳 輸雙向的三路1080P060HZ H. 264達(dá)到Sony PS3高清晰度的會(huì)議電視終端上市后，接下來 的內(nèi)容自然是4K、8K超高清視頻和最新視頻編碼標(biāo)準(zhǔn)HEVC/H. 265。
[0003] 一路 1080P@30Hz 視頻的圖像數(shù)據(jù)量達(dá)到 746, 496, 000bit/s。以 ITU-RBT. 1120 格 式傳輸時(shí)速率達(dá)1. 485Gbit/s。壓縮為1~8Mbit/s的H. 264碼流，編碼、解碼各需要2片、1 片32位定點(diǎn)處理能力96億次/秒的TI C6455@1.2GHz數(shù)字信號(hào)處理器DSP芯片。視頻編 碼技術(shù)對(duì)于處理器芯片性能要求不斷躍進(jìn)。Intel Pentium 404GHz處理器芯片上市失敗 后，傳統(tǒng)的提升處理器芯片性能的手段遇到阻滯，多核結(jié)構(gòu)包括同構(gòu)多核和異構(gòu)多核已經(jīng) 成為提升處理器芯片性能的最主要手段。在DSP芯片領(lǐng)域數(shù)麻省理工學(xué)院MIT教授Anant Agarwal創(chuàng)立的Tilera公司推出的64核心DSP芯片Tile64最引人注目。其中最顯著優(yōu)勢(shì) 為iMesh片內(nèi)核間高速互連網(wǎng)絡(luò)，呈8x8網(wǎng)格狀，網(wǎng)格節(jié)點(diǎn)為64個(gè)相同的64位定點(diǎn)處理器 核心，包含5套獨(dú)立物理線路，包交換，支持?jǐn)?shù)據(jù)包組播和廣播。TI公司則在C6455芯片達(dá) 到傳統(tǒng)單核心DSP性能頂峰后推出3核心TCI6487/6488和6核心TCI6486芯片，片內(nèi)分別 包含3個(gè)、6個(gè)C6455核心，雖然沒有Tile64那么引人注目，但是牢牢占據(jù)高端DSP芯片市 場(chǎng)。TI最新最強(qiáng)的DSP為C6678,包含8個(gè)浮點(diǎn)處理器核心以及TeraNet片內(nèi)高速互連網(wǎng) 絡(luò)。
[0004] 在硅片上復(fù)制η份處理器核心簡(jiǎn)單易行。難度和關(guān)鍵在于如何讓?duì)莻€(gè)核心在應(yīng) 用中表現(xiàn)出期待的η倍性能！除了依靠核間通信技術(shù)，最主要還是依賴軟件包括操作系統(tǒng) 0S和應(yīng)用軟件。現(xiàn)時(shí)DSP所用實(shí)時(shí)操作系統(tǒng)RT0S包括Linux嵌入式發(fā)行版本和TI DSP/ BIOS。版本號(hào)高于2. 6. 10的Linux支持對(duì)稱多處理器SMP，具有調(diào)度多核間負(fù)荷分布的能 力。鑒于目前計(jì)算機(jī)應(yīng)用領(lǐng)域內(nèi)標(biāo)量過程的單一任務(wù)在多處理上均衡的技術(shù)解決狀況，運(yùn) 用RT0S提供的多進(jìn)程和多線程設(shè)置多任務(wù)是RT0S有效均衡多核負(fù)荷的情景和前提條件。 也就是現(xiàn)有RT0S對(duì)標(biāo)量過程的單一任務(wù)運(yùn)行于多核的自動(dòng)調(diào)度負(fù)荷分布的作用很微弱。
[0005] 本發(fā)明涉及領(lǐng)域恰恰正是這種情況：一路高清視頻數(shù)據(jù)量巨大，編碼和解碼運(yùn)算 量巨大，雙向?qū)崟r(shí)網(wǎng)絡(luò)傳輸時(shí)更甚，需要拿出多個(gè)核心去應(yīng)付；視頻編碼和解碼都是順序執(zhí) 行的上下文的標(biāo)量過程，前一步未完就走不到后一步；在時(shí)間、空間上也存在很強(qiáng)的運(yùn)算與 數(shù)據(jù)的關(guān)聯(lián)與依賴。緣于視頻編碼本身就是計(jì)算時(shí)間、空間相關(guān)性以去除表達(dá)冗余減少數(shù) 據(jù)量。視頻編碼技術(shù)的壓縮比越高，時(shí)間、空間相關(guān)的范圍和程度也越大，相應(yīng)運(yùn)算量據(jù)增。 此時(shí)RT0S已無意義，唯有依靠應(yīng)用軟件。η個(gè)核心表現(xiàn)出η倍性能即要求并行加速比達(dá)到 η。在軟件上提高并行加速比的途徑、措施是調(diào)整負(fù)荷在多核的分布達(dá)到均衡、減少并行等 待和相互阻塞、優(yōu)化高速緩存。
[0006] 多核并行在視頻解碼上的難度大于編碼。因?yàn)榫幋a輸入為規(guī)整原始圖像數(shù)據(jù)，可 任意劃分、隨機(jī)存取，便于數(shù)據(jù)劃分；解碼輸入為壓縮碼流，不僅表達(dá)圖像內(nèi)容的效率非常 高，常常1個(gè)二進(jìn)制位就表達(dá)了一個(gè)圖像塊，而且一段碼流內(nèi)不可再劃分與定位，碼流劃分 單位與定位位置只能到包含任意整數(shù)個(gè)碼流基本單元的片slice -層，在實(shí)際網(wǎng)絡(luò)傳輸常 見碼流中片由數(shù)據(jù)包長(zhǎng)不超過網(wǎng)絡(luò)最大傳輸單元MTU的規(guī)則而定，位置不定，難以進(jìn)行數(shù) 據(jù)劃分。
[0007] 視頻解碼過程的劃分不宜多于3 (3個(gè)順接的子過程），而且分出的子過程運(yùn)算 量難以均等，更增大數(shù)據(jù)存儲(chǔ)量和吞吐量。解碼核心數(shù)大于3就必須考慮一幀圖像以內(nèi) 的任務(wù)劃分。相鄰圖像塊的空間依賴性使任務(wù)均衡劃分的難度徒然增大。迄今比較有效 的一幀圖像內(nèi)圖像塊并行的解碼方法為水邊線Waterfront并行解碼方法如圖1所示，同 時(shí)在垂直方向上展開多個(gè)行掃描處理，而非通常光柵掃描線處理。圖1中5x5的16x16 宏塊陣列的H. 264解碼于T1~T13時(shí)刻完成，其中T3~T11時(shí)刻可同時(shí)處理多個(gè)宏 塊。視頻編解碼的空間依賴性使這樣的處理形似空中俯瞰的地面與水面間分界線，因而 得名。詳情見于文獻(xiàn)一（Erik B. van der Tol, et al. Mapping of H. 264decoding on a multiprocessor architecture. Proceedings of SPIE Conference on Image and Video Commuincations, Vol. 5022, PP. 707 一 718, Jan. 2003)和是文獻(xiàn)二（Arnaldo Azevedo, et al.Parallel H. 264 Decoding on an Embedded Multicore Processor, http://ce. et. tudelft.nl/publicationfiles/1590 752 54090404. pdf)〇
[0008] 圖1所示二維水邊線Waterfront多核并行解碼方法在Tile64上的首次嘗試見于 文獻(xiàn)三（管輝.基于同構(gòu)多核處理器的H. 264并行解碼算法研究.哈爾濱工業(yè)大學(xué)碩士學(xué) 位論文.2009.下載于中國(guó)知網(wǎng)www. cnki. net),步驟簡(jiǎn)述如下:
[0009] (1)安排Tile64的1個(gè)核心#0處理一幀圖像碼流解析，5個(gè)核心#1~5處理一 幀圖像重建以及去方塊環(huán)路濾波。
[0010] (2)核心#0在共享內(nèi)存中為全部共享圖像數(shù)據(jù)、圖像重建隊(duì)列和去方塊濾波隊(duì)列 的結(jié)構(gòu)體變量開辟空間malloc，對(duì)這些隊(duì)列和處理狀態(tài)數(shù)組所帶的互斥鎖Mutex做初始 化，把位于左上頂點(diǎn)坐標(biāo)（〇,〇)的第一個(gè)宏塊排入圖像重建隊(duì)列。
[0011] (3)用雙緩沖區(qū)方法（也稱乒乓緩沖方法）使核心#0的碼流解析與核心#1~5 的圖像重建以及去方塊環(huán)路濾波并行執(zhí)行。即從核心#〇操作緩沖區(qū)#〇開始。核心#〇完 成后把緩沖區(qū)#0交給核心#1~5操作，接著操作緩沖區(qū)#1 ;緩沖區(qū)#0和#1的操作都完成 后，通過指針輪換交換緩沖區(qū)，核心#0操作緩沖區(qū)#0同時(shí)核心#1~5操作緩沖區(qū)#1 ;…。
[0012] (4)核心#1~5每個(gè)核心執(zhí)行以下步驟：
[0013] (41)循環(huán)讀先進(jìn)先出FIFO的隊(duì)列queue直到從中取出一個(gè)宏塊（mb_y, mb_x)為 止，每次循環(huán)先讀帶互斥鎖的圖像重建隊(duì)列，如果遇空再讀帶互斥鎖的去方塊環(huán)路濾波隊(duì) 列；
[0014] (42)宏塊（mb_y，mb_x)圖像重建或者去方塊環(huán)路濾波，完成后寫帶互斥鎖的宏塊 (mb_y，mb_x)的處理狀態(tài)為已完成圖像重建或者已完成去方塊環(huán)路濾波；
[0015] (43)讀帶互斥鎖的下一行相鄰的左下宏塊（mb_y+l，mb_x-l)和下方宏塊（mb_ y+l，mb_x)的處理狀態(tài)，判斷能否執(zhí)行圖像重建或者去方塊環(huán)路濾波；
[0016] (44)更新帶互斥鎖的圖像重建隊(duì)列和去方塊環(huán)路濾波隊(duì)列，把可處理的0/1/2個(gè) 宏塊排入隊(duì)列；
[0017] (45)處理完一幀圖像全部宏塊的圖像重建以及去方塊環(huán)路濾波，退出循環(huán)；否 貝1J，跳到（41)繼續(xù)循環(huán)執(zhí)行。
[0018] (5)核心#0碼流解析完成與核心#1~5的圖像重建以及去方塊環(huán)路濾波完成的 同步。
[0019] (6)跳到（4)繼續(xù)循環(huán)執(zhí)行下一幀圖像碼流的解碼，直到碼流終止。
[0020] 以上方法和程序的效果十分糟糕：對(duì)于Foreman序列CIF H. 264碼流，Tile64單 核運(yùn)行PC機(jī)算法驗(yàn)證模型的H. 264解碼軟件C代碼（未經(jīng)任何針對(duì)Tile64平臺(tái)的優(yōu)化）， 解碼平均幀頻20多ms/f ;分?jǐn)偟?個(gè)核后慢得非常多；最后完成代碼優(yōu)化工作，主要包括 32位單指令多數(shù)據(jù)操作SHffi、循環(huán)拆解、條件分支替代等措施，也僅達(dá)到23ms/f。也就是 說優(yōu)化后在6個(gè)核上跑，比未優(yōu)化在一個(gè)核上跑還慢。曾經(jīng)將解碼軟件的可執(zhí)行文件交給 Tilera公司分析，答復(fù)是片內(nèi)高速緩存cache緩存的數(shù)據(jù)絕大部分為非母核數(shù)據(jù)，數(shù)據(jù)存 取效率過低。
[0021] Tile64片內(nèi)高速緩存Cahce分散到64個(gè)核心內(nèi)部，每個(gè)核心配備全速的8K字節(jié) 一級(jí)數(shù)據(jù)緩存L1D和8K字節(jié)一級(jí)指令緩存L1P，還有半速的64K字節(jié)二級(jí)緩存L2Cache。L1D 和L2Cache只緩存由本核心開辟空間malloc的片外主內(nèi)存數(shù)據(jù)，稱為母核Cache-homing， 不緩存其它核心開辟空間的片外主內(nèi)存數(shù)據(jù)。當(dāng)核心A訪問非母核數(shù)據(jù)時(shí)，首先由該數(shù)據(jù) 的母核B緩存至L2Cache，再由核心A通過iMesh片內(nèi)核間高速互連網(wǎng)絡(luò)與核心B傳輸數(shù)據(jù) 包，實(shí)現(xiàn)自核心B的L2Cache讀入數(shù)據(jù)或者更新核心B的L2Cache內(nèi)數(shù)據(jù)。即使η次重復(fù)的 訪問也需要η次經(jīng)過iMesh網(wǎng)的數(shù)據(jù)包傳輸。所以訪問非母核數(shù)據(jù)比訪問母核數(shù)據(jù)效率 低得多。曾經(jīng)做過一試驗(yàn)，把H. 264解碼任務(wù)分成兩部分A和B。A為開辟空間malloc并碼 流解析