網(wǎng)絡解碼

1、系統(tǒng)框架系統(tǒng)框架DaVinci平臺下的軟件開發(fā)主要是圍繞DVSDK開發(fā)工具包與相應的Montavista文件系統(tǒng)進行的。Montavista提供了系統(tǒng)運行所需的Linux文件系統(tǒng)與庫文件，以及交叉編譯器等必要文件。DVSDK主要是提供了DSP下編程所需的交叉編譯器、支持庫，同時還提供了MPEG4、H264等常用的音、視頻編解碼算法在DSP端的實現(xiàn)庫。更重要的是，對于ARMDSP雙核的平臺特性，DVSDK還提供了用于ARM與DSP通信的主

2、體框架——CodecEngine。如圖1所示。SERVERVISA接口應用程序DMAI接口CE核心接口CODECDSPLINK模塊0x880000000x86700000…………圖1CodecEnging模塊角色結構圖CodecEngine是一套包含了同時運行在ARM和DSP兩個核心之上的程序以及溝通兩者之間的程序的框架集合，它介于應用層和信號處理層，是連接ARM與DSP或者協(xié)處理器之間的一個重要橋梁。ARM端的上層應用程序首先調用Co

3、decEngine提供的接口（DMAIVISA等），并將需要調用的算法與待處理數(shù)據(jù)在CMEM中的地址傳給該接口，該接口會把信息打包，以消息隊列的方式，通過DSPLINK模塊發(fā)送給DSP端的服務程序，服務程序解析出算法與內(nèi)存地址后便會在DSP端調用相應的算法程序，完成處理。UDP協(xié)議協(xié)議UDP是UserDatagramProtocol（用戶數(shù)據(jù)報協(xié)議）的英文縮寫。UDP只提供一種基本的、低延遲的被稱為數(shù)據(jù)報的通訊。所謂數(shù)據(jù)報，就是一種自帶

4、尋址信息，從發(fā)送端走到接收端的數(shù)據(jù)包。UDP協(xié)議經(jīng)常用于路由表數(shù)據(jù)交換轉發(fā)和系統(tǒng)信息、網(wǎng)絡監(jiān)控數(shù)據(jù)等的交換。UDP協(xié)沒有TCP那樣的三次握手并且基于數(shù)據(jù)報，因此UDP不基于連接，也沒有TCP那樣豐富的頭信息以實現(xiàn)諸多功能。UDP數(shù)據(jù)報的頭只包含了類似于TCP中包含的UDP源端口、UDP目的端口號、兩個字節(jié)的校驗和域、兩個字節(jié)的信息長度域（用來告訴接收端信息的大小，讓接收端判斷信息是否有效）。由于UDP協(xié)議是如此簡單，所以不要指望UDP連

5、接會像TCP連接那樣可靠，它一點都不可靠，UDP只負責盡力的轉發(fā)數(shù)據(jù)包，但是卻不會把錯誤的數(shù)據(jù)報重新發(fā)送，它會丟圖2圖3隨著現(xiàn)在視頻行業(yè)的高速發(fā)展，很多時候視頻都需要進行去隔行處理，要解決這個問題，其實也不難，問題就是出在隔行掃描的幀頻率太慢，奇場和偶場加起來每秒才25Hz，而且奇場偶場的數(shù)據(jù)是在分別不同的時間進行采集的。因此，當物體運動時在視覺效果上看起來就會有鋸齒感。具體的去隔行意思就是用單獨的一個奇場還原奇場偶場都有的完整圖像，單

6、獨的一個偶場也還原奇場偶場都有的完整圖像，這樣在每秒看到的就是50Hz的圖像，從人眼視覺敏感度上來說，就根本很難感覺到鋸齒感了。由于上述隔行掃描的種種問題，所以采取了一些去隔行的處理，如圖4所示。處理后每次視頻源輸出的單場(奇場或者偶場)就會被處理成一個完整的圖像，即每秒實際更新的圖像是50幀。圖4圖4中的去隔行濾波其實和很多資料中提及的4:2:2到4:4:4轉換的算法是一致的。簡單的說，也就是通過相近行的圖像數(shù)據(jù)來重構沒有數(shù)據(jù)的圖像。

7、后端顯示后端顯示VPBE在一些視頻設備上看到有YUV、YcbCr等標記的接口標識，此種接口成為色差端口(也稱分量視頻接口)。它通常采用YPbPr和YCbCr兩種標識，前者表示逐行掃描色差輸出，后者表示隔行掃描色差輸出。色差傳送的視頻有許多種方式，例如將三原色直接傳送的RGB方式，以及從RGB轉換為明度（Y）與色差（CbCr或PbPr）的方式。RGB方式將所有的顏色信息作同等的處理，雖然有最高的畫質，但由于RGB方式對傳輸帶寬和儲存空間的