基于DSP系統(tǒng)開發(fā)的視頻編解碼系統(tǒng)，國(guó)內(nèi)幾乎都是走的移植，優(yōu)化的路線，并且移植的代碼，都是開源的。畢竟花費(fèi)大量的人力，物力去開發(fā)一套自己的代碼，并不見得比一些成熟的開源代碼效率更高，健壯性更好。更何況開發(fā)速度對(duì)于一個(gè)產(chǎn)品的發(fā)展而言，更是重要。

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

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

準(zhǔn)備好了這些，就可以開始移植了，移植，也是一個(gè)考驗(yàn)?zāi)愕倪^程。

做好了移植的準(zhǔn)備工作，就進(jìn)入了開發(fā)過程的第一個(gè)重要階段---移植。

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

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

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

3. Inline的問題，移植以后，編譯的時(shí)候Inline經(jīng)常會(huì)報(bào)錯(cuò)。雖然有編譯選項(xiàng)可以去掉錯(cuò)誤，不過你如果和我一樣不熟悉的話，直接去掉 Inline關(guān)鍵字，到后面隨著對(duì)VDSP熟悉以后，如果有優(yōu)化的需要，再按照VDSP的語法，為自己想要嵌入的函數(shù)增加Inline關(guān)鍵字。

經(jīng)過上面的修改，一般情況下，編譯就沒有問題了，當(dāng)然，這只是移植的第一步。距離成功，還很遠(yuǎn)！

代碼可以編譯了以后，你可以嘗試著運(yùn)行，一般情況下，都會(huì)出錯(cuò)，并且，鏈接都會(huì)有問題，所以，還需要進(jìn)行一下工作。

1. 配置LDF文件。因?yàn)閯傄浦驳拇a，往往數(shù)據(jù)和程序都非常大，所以，SRAM里面肯定是放不下的，這個(gè)時(shí)候，鏈接就會(huì)有問題。剛開始的時(shí)候，最好把所有的程序和數(shù)據(jù)都放在SDRAM里面去，這樣的，鏈接就不會(huì)有問題了。Stack和heap情況類似，開始的時(shí)候，都先放到SDRAM。開始的時(shí)候，你需要的是一個(gè)可以運(yùn)行正確的程序，速度倒在其次。

2.Malloc的問題。DSP下的開發(fā)，malloc都是一個(gè)需要解決的問題。動(dòng)態(tài)申請(qǐng)內(nèi)存，就算可以運(yùn)行，結(jié)果往往也是不對(duì)的。所以，最好進(jìn)行靜態(tài)分配，用數(shù)組的形式分配，這樣做的好處是可以方便自己管理，那些數(shù)組多大，放在那里，自己都很清楚，因?yàn)閮?yōu)化的時(shí)候，有一些是要放在SRAM中，另外一些特別大的才放在SDRAM中，這樣才能取的比較好的效果，另外，靜態(tài)數(shù)組也穩(wěn)定性一些，不需要記著去釋放。

3.文件操作。在VDSP的SETTING下，有一個(gè)STDIO的開關(guān)，其實(shí)可以支持文件操作，但是我調(diào)試的時(shí)候發(fā)現(xiàn)，有些情況下是有問題的。比如我在一個(gè)循環(huán)中使用fread，但是他只有第一次的讀取是有效的，但有些時(shí)候，它好像又可以。所以，你調(diào)試的時(shí)候，如果發(fā)現(xiàn)結(jié)果和VC下運(yùn)行的不同，可以重點(diǎn)看看，是不是這里出了問題。

4.調(diào)試跟蹤。經(jīng)過上面的準(zhǔn)備，程序已經(jīng)可以運(yùn)行了。你可以在Simulator下仿真，或者板子上直接仿真。在SI下，速度會(huì)很慢，不過Sesion里面，有一個(gè)blackfin family那個(gè)sision，速度還可以，當(dāng)然，有板子會(huì)更好。我們開發(fā)的時(shí)候，我使用板子的時(shí)間總共不到兩個(gè)月，所以浪費(fèi)了很多時(shí)間，現(xiàn)在回頭看看，好心痛。

調(diào)試結(jié)果OK了的話，說明移植已經(jīng)成功了。就可以進(jìn)入下一個(gè)最主要的階段---優(yōu)化了。

移植搞好了以后，就可以進(jìn)行優(yōu)化了，優(yōu)化是一個(gè)長(zhǎng)期的，枯燥的，但很有挑戰(zhàn)性的工作。做優(yōu)化，你要熟悉blackfin的匯編指令，熟悉H.264標(biāo)準(zhǔn)，熟悉你所移植的代碼結(jié)構(gòu)，在優(yōu)化過程中，的確是很枯燥的，需要你很有耐性，經(jīng)常會(huì)因?yàn)橐粋€(gè)小小的錯(cuò)誤，讓你跟蹤幾天甚至幾星期，但是，當(dāng)你看到隨著你工作的不斷進(jìn)展，程序需要的cycle數(shù)越來越少，還是很有成就感的。

在blackfin上做優(yōu)化，最主要的工作可以分為：

1.系統(tǒng)結(jié)構(gòu)優(yōu)化。

2.匯編優(yōu)化。

3 cache和DMA優(yōu)化。

一個(gè)好的優(yōu)化程序，這幾個(gè)方面肯定都會(huì)涉及。至于各自所起的作用，我沒有詳細(xì)測(cè)試。系統(tǒng)結(jié)構(gòu)優(yōu)化和匯編優(yōu)化可以先進(jìn)行。等做到一定程度了，再進(jìn)行cache和DMA的優(yōu)化。

總結(jié)

以上是生活随笔為你收集整理的H.264视频编解码的代码移植和优化的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。