基于DSP系統開發的視頻編解碼系統，國內幾乎都是走的移植，優化的路線，并且移植的代碼，都是開源的。畢竟花費大量的人力，物力去開發一套自己的代碼，并不見得比一些成熟的開源代碼效率更高，健壯性更好。更何況開發速度對于一個產品的發展而言，更是重要。

目前對于H.264而言，移植的代碼主要有JM,x264和T264。移植的時候，就需要對各個代碼進行測試，以確定要移植的代碼。相對而言，JM的移植更容易，但效率比較差，如果基于科學研究，移植JM的比較多，多見于各高校的研究人員。對企業而言，考慮到實時性的要求，移植以X264和T264居多。

將視頻編解碼移植到DSP的時候，考慮到DSP系統資源的寶貴，主要考慮的因素是系統空間，包括程序空間和數據空間，所以需要對原始的C代碼，進行評估，這就需要對于所移植的代碼有一個比較詳細的了解。代碼空間一般可以通過map文件進行估算。數據空間的估計，需要計算程序中內存的使用情況，除了malloc申請的空間，還包括靜態數組，主要是H.264標準中的各種表格數組以及一些全局變量等等。

準備好了這些，就可以開始移植了，移植，也是一個考驗你的過程。

做好了移植的準備工作，就進入了開發過程的第一個重要階段---移植。

??? 移植開發的時候，最好準備兩個版本，一個純C代碼，在VC下編譯,運行,另一個是VDSP下的版本(ccs同理），VC版本主要是驗證代碼運行是否正確，VDSP版本就是移植以后的版本，兩個版本同步更新，即盡量保持兩個版本的一致性，但能夠同時在VC和VDSP下運行。在移植過程中，一般會遇到的問題如下：

? 1.頭文件的不同，一般問題都是linux下的頭文件，在VDSP中沒有存在。最典型的就是inttypes.h 和 stdint.h，這種頭的作用主要是定義了8字符，16字符，32字符，64字符的數據類型，移植的時候，可以自己建一個頭文件或者直接在其他的頭文件中把這些數據類型的定義加進去，這樣的話，就不會出現問題。其他的類似，要么找相應的頭文件替換，要么干脆自己定義。

? 2.Int64_t和Uint64_t 的問題, 在第一步中,其實也存在這個問題, 不過我最初是用long和Unsigned long 來代替，不過這樣的話，編譯是可以通過，但仔細分析，其實是有問題的。一般來講，64位數的用途有兩個，第一種是這個數字可能比較大，當累積到一定的程度，可能超過32位，這種情況下，可以用32位代替，不過最好加上注釋，告訴自己這個數可能越界，在后面調試的時候，要提示自己注意一下。另一種用途，是開發者為了速度的要求，對一些變量復制的時候，使用了強制性的指針賦值，這種情況下，就不能直接該成32位數據了，那樣的話，雖然編譯通過，后面運行，肯定有錯誤的。這種情況下，可以使用32位數據類型，分兩條語句對變量賦值，當然，這是個時候要千萬注意，不要把地址搞錯了。

3. Inline的問題，移植以后，編譯的時候Inline經常會報錯。雖然有編譯選項可以去掉錯誤，不過你如果和我一樣不熟悉的話，直接去掉 Inline關鍵字，到后面隨著對VDSP熟悉以后，如果有優化的需要，再按照VDSP的語法，為自己想要嵌入的函數增加Inline關鍵字。

經過上面的修改，一般情況下，編譯就沒有問題了，當然，這只是移植的第一步。距離成功，還很遠！

代碼可以編譯了以后，你可以嘗試著運行，一般情況下，都會出錯，并且，鏈接都會有問題，所以，還需要進行一下工作。

1. 配置LDF文件。因為剛移植的代碼，往往數據和程序都非常大，所以，SRAM里面肯定是放不下的，這個時候，鏈接就會有問題。剛開始的時候，最好把所有的程序和數據都放在SDRAM里面去，這樣的，鏈接就不會有問題了。Stack和heap情況類似，開始的時候，都先放到SDRAM。開始的時候，你需要的是一個可以運行正確的程序，速度倒在其次。

2.Malloc的問題。DSP下的開發，malloc都是一個需要解決的問題。動態申請內存，就算可以運行，結果往往也是不對的。所以，最好進行靜態分配，用數組的形式分配，這樣做的好處是可以方便自己管理，那些數組多大，放在那里，自己都很清楚，因為優化的時候，有一些是要放在SRAM中，另外一些特別大的才放在SDRAM中，這樣才能取的比較好的效果，另外，靜態數組也穩定性一些，不需要記著去釋放。

3.文件操作。在VDSP的SETTING下，有一個STDIO的開關，其實可以支持文件操作，但是我調試的時候發現，有些情況下是有問題的。比如我在一個循環中使用fread，但是他只有第一次的讀取是有效的，但有些時候，它好像又可以。所以，你調試的時候，如果發現結果和VC下運行的不同，可以重點看看，是不是這里出了問題。

4.調試跟蹤。經過上面的準備，程序已經可以運行了。你可以在Simulator下仿真，或者板子上直接仿真。在SI下，速度會很慢，不過Sesion里面，有一個blackfin family那個sision，速度還可以，當然，有板子會更好。我們開發的時候，我使用板子的時間總共不到兩個月，所以浪費了很多時間，現在回頭看看，好心痛。

調試結果OK了的話，說明移植已經成功了。就可以進入下一個最主要的階段---優化了。

移植搞好了以后，就可以進行優化了，優化是一個長期的，枯燥的，但很有挑戰性的工作。做優化，你要熟悉blackfin的匯編指令，熟悉H.264標準，熟悉你所移植的代碼結構，在優化過程中，的確是很枯燥的，需要你很有耐性，經常會因為一個小小的錯誤，讓你跟蹤幾天甚至幾星期，但是，當你看到隨著你工作的不斷進展，程序需要的cycle數越來越少，還是很有成就感的。

在blackfin上做優化，最主要的工作可以分為：

1.系統結構優化。

2.匯編優化。

3 cache和DMA優化。

一個好的優化程序，這幾個方面肯定都會涉及。至于各自所起的作用，我沒有詳細測試。系統結構優化和匯編優化可以先進行。等做到一定程度了，再進行cache和DMA的優化。