目前 h.264編解碼器的實現可以採用以下幾種方式
ø 採用奔騰 pentium 四代機實現 h.264 編譯碼最早就是在 pc 平台上實現
的 由於簡單易開發 基於該平台的研究得到最多 jvt 的 jm 參考**是就是基於 pc 平台的 此方案的優點是利用當前最新的 pc 資源 以及較強的軟體工具 intel 的 sse2 和 mmx 提供了較完整的多**指令集和流水線 其缺點是占用資源多 通用性不強 不過隨著計算機發展 速度越來越快 有它的成本優勢
ø 採用 asic 實現 美國 broadcom 公司發布了可對 h.264 編碼格式 hdtv 影像
進行解碼的 lsi bcm7411 2004 年 12 月國立台灣大學等發布能夠以 h.264方式對 hdtv 影像進行實時編碼的晶元 其他廠商 如科勝訊系統(conexantsystems) 意法半導體(st)和 sigma designs 等公司已經展開了激烈的競爭 在國內 芯華等企業也在進行 h.264 解碼晶元的研發 此 asic 的優點是方便整合 利於應用 開發周期短 但其缺點也很明顯 無法靈活公升級和應用修改 而且對特殊環境缺乏應變力
ø 採用多**數字訊號處理器 dsp digital signal processor 實現 equator公司的 bsp-15 philips 的 trimedia ti 的 dm642 都提供了極強大的多**流水線操作 而且往往具有強大的多**介面 開發包和必要資源也較多因此基於 dsp 平台的開發成為熱點 2004 年 ubvideo 公司和 ateme 公司陸續推出了基於 ti tms320c64*數字**平台的優化的 h.264 main profile編解碼器 加拿大公司 cradle 推出了 30 幀/秒的 h.264 編解碼器 該產品為全 cif 30fps h.264 標準下的首個商業應用 它是基於 ct3400 dsp 陣列晶元的
實現平台blackfin533
其優點是集合多**與普通 mcu 的優勢 較高的主頻 較低的** 尤其適用於功耗小 體積小 速度快的網路攝像機和無線手持裝置中 其缺點是具體開發的成本和週期可能較大 而且由於本身介面不夠強大以及支援不夠有力 開發難度和具體成本也高。
核心主要有以下特性:
blackfin dsp 體系結構在單週期內支援如下操作
ø 在兩個 mac 或兩個 alu 上執行一條單指令運算
ø 執行 2 x 32 位資料傳送(2 讀取或 1 讀 1 寫)
ø 執行兩指標更新
ø 執行硬體迴圈重新整理
bf533 ez-kit 是 adi 公司的評估板 它為專案演示 演算法** 原型製作和軟體優化提供了完整的平台 板子上的主要器件有 adsp-bf533 處理器 160針 bga 封裝 27 mhz 晶振輸入 2mb flash(512k 16 2chips) sdram 32mb16m 16bits 模 擬 音 頻 接 口 模 擬 視 頻 接 口 uart 擴 展 接 口
d s p 系統配置與移植ez-kit 板子有 usb 和 hppci 兩種**形式 由於 hppci 速度快 通常採用該形式 jm 的參考**是基於 pc 的 要移植到 dsp 平台上需要做系統配置和**
1. 資料的輸入輸出和配置檔案jm
參考**是以讀檔案的方式輸入影象資料 檔案格式為 yuv 4 2 0編碼完成後碼流輸出到二進位制檔案中去 編碼器可選項是通過檔案 encoder.cfg配置的 adi blackfin 支援標準的 io 庫 支援讀寫檔案的操作 但是通過**器從 pc 機上讀寫檔案速度比較慢 尤其 vlc 後的碼流輸出十分頻繁 那麼 dsp就會頻繁地在 supervisor 和 emulator 模式之間切換 執行效率比較低下 因此我們直接將原始影象資料填充到 sdram 中指定的位址 碼流通過 dma 方式輸出到sdram 中指定的位址空間 這其中必須實現影象的.yuv 檔案和 visualdsp++支援的.dat 檔案之間的相互轉換 編碼器的配置資訊在程式中設定 通過上述改動雖然沒有提高實際的編碼速度 但是明顯地提高了整個程式的執行時間。
2 cache的配置
為了充分發揮 cache 的作用 一方面應該恰當配置 cache 對映的儲存空間及其頁面屬性 另一方面是優化**增加 cache 的命中率 **的優化的手段有把處理同一資料的函式儲存在一起 合理組織資料結構 增加資料復用等
3 c語言的優化
巨集的使用 程式跳轉比較耗時 ，不是 dsp 所擅長的 。在 h.264 的**中有些函式很短， 執行單一的功能 ，被呼叫的次數很多 把這些函式改為巨集 ，節省了大量的程式跳轉時間 。
迴圈的優化 函式盡量展開 ，尤其是最核心的部分 ，對多層的迴圈 ，內部迴圈的資源一定要用足 同時迴圈體中的語句可以進行並行優化 這樣就降低了整個迴圈體總的執行指令數量 小的迴圈可以不要讓它迴圈 另外還可以合併某些迴圈合併的前提是具有相同的迴圈次數並且迴圈體內資料的運算結果不會因為合併而改變 它節省了每次迴圈建立的時間和迴圈內相同變數重複定址時間 提高了輔助暫存器的使用率
計算**化 可以盡可能把一些執行時計算的引數做成查詢的**常數數值 。從而將執行時的計算轉化為編譯時的計算 這不僅適用於一些比較規整的參數列對於一些並不規整的執行時計算 特別是比較耗時的計算 也要盡可能使其**化浮點數定點化 c 語言中既有整型數 又有浮點數 由於使用的定點 dsp 對浮點數的計算是非常耗時的 因此 在演算法允許的範圍內有必要把浮點運算改為定點運算。
減少判斷轉換
bf533 採用了 8 級流水線 頻繁的轉移指令會使流水線難以發揮作用 通過對程式流的分析 許多判斷轉移可以用簡單的條件組合來實現。
降低陣列的維數
在 c 語言程式中 對多維陣列的定址是非常耗時的 因此在設計中應當盡量降低陣列的維數簡單的資料結構 最好使用單層的資料結構 這樣可以降低定址開銷 又可以減少 bank 之間的衝突 避免使用巢狀的結構體 而採用單層的結構體 即使結構體比較大也沒有關係。
盡量靜態分配記憶體 指標不知道實際的位址在哪兒 多級指標更加令 dag 困惑最好採用靜態分配 將定址方式改為一維陣列 全拿出來分配好記憶體 並且利用一維定址是零開銷的這一特點 比如對 qcif 影象 dct 變換單元為 4x 4 子塊那麼最好是採用一行行的順序 一行用乙個指標來指 位址每兩行進行一次修改對 yuv 影象來說 一次可以取 32 位 把四個點取進來。
4 組合語言的運用
雖然經過編譯器選項的優化和 c **的優化, 我們仍然希望進一步提高**的執行效率 直接把關鍵模組改用匯程式設計序是最直接的辦法
用533存在的優缺點
h.264 演算法複雜 bf533 還存在片內記憶體較小和計算能力較差的缺點
h.264 還有問題亟待解決 其一是位元速率控制演算法目前 h.264 還沒有乙個令人滿意的位元速率控制演算法 這是因為 h.264 採用的 rd 模型和巨集塊級的位元速率控制演算法十分複雜 其二是抗誤碼的問題 在無線通道和internet 通道上如何保證可靠地傳輸資訊也是研究熱點 另外如何在目前的硬體平台上實現實時通訊也是乙個挑戰。
H 264效能優化
h.264 優化 2007 05 24 2 20 h.264的dsp實現流程分為三個階段 第乙個階段產生和評估c 第二個階段優化和評估c 第三個階段編寫和評估線性彙編。每個階段完成任務如下 第一階段 首先，產生c 並進行時間評估。一般情況下，這個階段的 效能很低。如果經過評估後，仍然滿足不了實時要求...
h 264 率失真優化
搜尋時，乙個不可避免的問題就是如何對mv進行比較，從而得到最優 對於同一壓縮演算法來說，位元速率越高表示影象質量越好 失真越小，但是位元速率越高要求更大的儲存空間，也會增加網路傳輸的壓力。因此在位元速率與失真中找出平衡點，使壓縮效果最優，這種方法叫做r d optimization 位元速率失真優化...
h 264 率失真優化
搜尋時，乙個不可避免的問題就是如何對mv進行比較，從而得到最優 對於同一壓縮演算法來說，位元速率越高表示影象質量越好 失真越小，但是位元速率越高要求更大的儲存空間，也會增加網路傳輸的壓力。因此在位元速率與失真中找出平衡點，使壓縮效果最優，這種方法叫做r d optimization 位元速率失真優化...