快樂蝦
本文適用於
adsp-bf561
優視bf561evb
開發板
uclinux-2008r1.5-rc3 (smp patch)
visual dsp++ 5.0(update 5)
歡迎到http://www.bfin-tools.org/bbs/viewthread.php?tid=28&extra=對本文進行討論。
由於vdsp
在編譯訊號處理相關**時效率較高，而且使用者程式可以控制所有的資源，因而採用這種方法的執行效率最高。當然這種方法的缺點也是顯而易見的，它的附加功能較難實現，比如網路功能等。
關於此法，網上有一篇流傳甚廣的文章《基於
adsp-bf561
的h.264
cache
的問題，這是其不足之處。
adi有乙個評估版在其**上，這大概是裸奔的極致了。可以同時做4路
cif@25fps或者1
路d1@22fps
。當然這是在只開
ppi中斷的情況下得到的資料。
此法應用甚廣，其基本思想是用a核跑
uclinux，b
核裸奔乙個
h264
的編碼器。
a核的程式使用
gnu toolchain
進行開發，
b核的程式可以採用
vdsp
進行開發，由
uclinux
在執行時動態載入。
採用這種方法，既可以發揮
uclinux
系統的好處，又可以兼具
vdsp
的高效。其技術點主要在於雙核之間的同步。
目前的uclinux
已經具備
smp的能力，因此可以只跑乙個系統管理兩個核，直接在此基礎上採用
gnu toolchain
進行開發，但由於很難使用
dma、l1、
l2 sram
等資源，在先天上就對此演算法有所限制。當然由於只需要使用
gnu toolchain
，其開發難度較低。
此法開發難度較高，其基本思想是讓編碼演算法做為核心執行緒來執行，好處是基本可以使用裸奔時用到的所有優化方法，也可以使用所有的系統資源，且可以使用
vdsp
編譯。採用這種方法，可以達到
d1 @ 15fps
，由此可見
uclinux
頻繁的時鐘中斷（
config_hz = 250
）對編碼演算法的影響。
uclinux系統移植到bf561板子上過程學習2
接下來要移植u boot引導程式，類似於pc機的bios，負責把核心映像從flash拷貝到sdram，然後把執行權交給核心。首先應該將u boot程式燒到目標板flash中，在此需要visual dsp 在裸板上除錯 燒寫 核心映象的除錯與燒寫 在uclinux dist目錄下執行make命令將完成...
H264關於RTP協議的實現
tag h264 rtprfc3984 端和客戶端分別進行了功能模組設計。伺服器端 rtp封裝模組主要是對h 264碼流進行打包封裝 rtcp分析模組負責產牛和傳送rtcp包並分析接收到的rtcp包 qos反饋控制模組則根據rr報文反饋資訊動態的對傳送速率進行調整 傳送緩衝模組則設定埠傳送rtp r...
實現RTP協議的h 264傳輸
2.rtp 協議關鍵引數的設定 3.h.264 基本流結構及其傳輸機制 3.1 h.264 基本流的結構 f forbidden zero bit.1 位，如果有語法衝突，則為 1。當網路識別此單元存在位元錯誤時，可將其設為 1，以便接收方丟掉該單元。nri nal ref idc.2 位，用來指示...