• 沒有找到結果。

Proposed Tightly-Coupled Video Encoder

4. 系統簡介及視訊壓縮器的設計

4.3. Proposed Tightly-Coupled Video Encoder

在本論文中我們決定用新一代的視訊壓縮標準 H.264 來驗證 Tightly-Coupled 架 構,但是現有的參考軟體(JM9.6 [30])的軟體架構並不符合我們需求,所以我們花了一 段時間來重新設計我們的壓縮器的資料結構,並盡量在記憶體的使用量和壓縮器的效

Select P

H

H-1

current MB

prediction MB residual

AC block

AC bock residual’

prediction MB

reconstruct MB

debocked MB top, left

top,left

Header VLC

Mux

top nnz, left nnz

H.264 I16MB

luma, chroma DC block

luma, chroma DC block L: 16x16x1 = 256

C: 2x8x8x1 = 128 Total: 384 (byte)

L: 16x16x2 = 512 C: 2x8x8x2 = 256 Total: 768 (byte)

L: 4x4x2 = 32 C: 2x2x2x2 = 16 Total: 48 (byte)

L: 16x4x4x2 = 512 C: 2x4x4x4x2 = 256 Total: 768 (byte)

L: 17x4x4x2 = 544 C: 2x2x2x2 + 2x4x4x4x2 = 272 Total: 816 (byte)

#b4x4 = 17+2x4 = 25

#b2x2 = 2*1 = 2

L: 16x16x1 = 256 C: 2x8x8x1 = 128 Total: 384 (byte) mb_type,

Select P

H

H-1

current MB

prediction MB residual

AC block

AC bock residual’

prediction MB

reconstruct MB

debocked MB top, left

top,left

Header VLC

Mux

top nnz, left nnz

H.264 I16MB

luma, chroma DC block

luma, chroma DC block L: 16x16x1 = 256

C: 2x8x8x1 = 128 Total: 384 (byte)

L: 16x16x2 = 512 C: 2x8x8x2 = 256 Total: 768 (byte)

L: 4x4x2 = 32 C: 2x2x2x2 = 16 Total: 48 (byte)

L: 16x4x4x2 = 512 C: 2x4x4x4x2 = 256 Total: 768 (byte)

L: 17x4x4x2 = 544 C: 2x2x2x2 + 2x4x4x4x2 = 272 Total: 816 (byte)

#b4x4 = 17+2x4 = 25

#b2x2 = 2*1 = 2

L: 16x16x1 = 256 C: 2x8x8x1 = 128 Total: 384 (byte) mb_type,

Fig. 27 H.264 I16MB block diagram

考量在 Intra frame 的壓縮演算法時,每個畫面(frame, slice)會切割成若干個巨區塊 (macroblock)來壓縮,但是因為 Intra prediction、CAVLC 和 In-Loop Filter 這些壓縮模

31

組的關係,所以巨區塊與巨區塊間會有一定的相依關係。當上方的區塊或左邊的區塊 未完成之前,現有的區塊是無法做壓縮的,這對我們的架構設計會有相當大的影響。

我們的設計是以巨區塊做為工作分配的基本單位,參考過去實驗室的經驗[31],有下 列幾點考量:

„ ARM 與 DSP 的執行速度

依照 ARM 與 DSP 資料處理速度的特性,我們知道 DSP 執行的速度會比 ARM 快,

所以我們不會將 ARM 與 DSP 做一比一的分配,而是根據核心現有的執行能力自 動分配工作區塊的個數。

„ 兩個核心之間溝通時間的花費

因為兩個核心是合作完成同一件工作,所以兩個核心了解彼此的資訊,比起用單 一核心來完成工作,溝通的花費是額外的。我們並不想要核心每做完一個巨區塊 就溝通一次,因為這樣的花費(overhead)會成為整個壓縮器系統瓶頸。

„ 巨區塊間的相依性

考量巨區塊間的相依性和 ARM 及 DSP 的處理速度,如果依照原本影像壓縮的區 塊掃描方式(raster scan)做分配,DSP 會因為在等待 ARM 巨區塊的完成而處於沒 有工作可做的狀態,這樣會浪費許多 DSP 的效能,也會拖累整個系統的效能。

ARM

DSP D1 D2 D3

A1

D11 A4

enable A1 end of row

D1 D2 D3 D11

A1 A4 D12

A5

Dx

switch A5

D12 Dx

end of frame

ARM

DSP D1 D2 D3

A1

D11 A4

enable A1 end of row

D1 D2 D3 D11

A1 A4 D12

A5

Dx

D1 D2 D3 D11

A1 A4 D12

A5

Dx

switch A5

D12 Dx

end of frame

Fig. 28 Proposed tightly-coupled video encoding process

我們論文實驗的區塊分配方法如上圖所示,因為 DSP 的執行速度比較快,所以一 開始時我們先將上面一列的巨區塊(D1~D11)都分配給 DSP 處理,當 DSP 處理完後第 二個區塊(D2)後,第二列的第一個區塊(A1)所需要的資訊也都具備了,所以 ARM 可 以開始處理 A1,這個時候 DSP 也同時在處理 D3,也就達到平行處理的效果。當 DSP 處理完第一列後,DSP 會利用 mailbox 通知 ARM,這個時候 ARM 可能在處理 A4 這 個區塊,當 ARM 處理完 A4 時會做一個交換(switch)的動作,即 ARM 會把這一列剩 下的工作交給 DSP,ARM 在繼續處理下一列的第一個巨區塊(A5),利用這樣的方法來 達到平行處理及動態分配的效果。

33

相關文件