[發(fā)明專利]視頻數(shù)據(jù)處理方法和裝置

無效

• 申請?zhí)枺?/td>: 200610161048.6
• 申請日: 2006-12-04
• 公開（公告）號: CN101198005A
• 公開（公告）日: 2008-06-11
• 發(fā)明（設(shè)計）人: 李春生;張中華
• 申請（專利權(quán)）人: 中興通訊股份有限公司
• 主分類號: H04N7/15
• 分類號: H04N7/15
• 代理公司: 北京康信知識產(chǎn)權(quán)代理有限責(zé)任公司
• 代理人: 李偉;吳孟秋

技術(shù)領(lǐng)域

本發(fā)明涉及視頻數(shù)據(jù)通訊領(lǐng)域，并且特別地涉及視頻數(shù)據(jù)處理方法和裝置。

背景技術(shù)

在大中型企業(yè)內(nèi)部的會議電視系統(tǒng)和運營商建立的面向大眾的大規(guī)模視訊運營系統(tǒng)中，基于H.323協(xié)議的會議電視系統(tǒng)管理控制單元(management?control?unit，MCU)，都是采用全交換的媒體處理方法，即對于會議中的所有終端的媒體都進(jìn)行處理，接收所有終端的視頻，音頻，低速數(shù)據(jù)(low?speed?data，LSD)等媒體數(shù)據(jù)，全部進(jìn)行混音，交換，混合等處理，然后把處理后的數(shù)據(jù)發(fā)送給各個終端，這些媒體處理占用系統(tǒng)大量的運算能力，但并不都是必須的，因為音頻數(shù)據(jù)需要進(jìn)行混音處理，必須全部接收處理，但是視頻數(shù)據(jù)卻不是這樣，根據(jù)H.323協(xié)議，管理點(management?point，MP)主要完成視頻的切換，交換和混合。在同一組單畫面無速率匹配的會議里，只有廣播端和廣播端需要看的端視頻數(shù)據(jù)，對于多畫面，速率匹配會議，也只需要處理參加混合的視頻數(shù)據(jù)，其他端完全可以不參與混合與切換。視頻數(shù)據(jù)的處理很耗費系統(tǒng)能力，所以對于這些端的處理是對系統(tǒng)資源的極大浪費。

傳統(tǒng)的處理方法是全交換方法，如圖1所示，從終端看，在發(fā)送方向上，本端音頻、視頻從麥克風(fēng)、攝像頭輸入后，進(jìn)行壓縮，之后經(jīng)過RTP處理，再使用用戶數(shù)據(jù)報協(xié)議(user?datagram?protocol，UDP)發(fā)送到網(wǎng)絡(luò)上；而在接收方向上與發(fā)送方向上相反，使用UDP從網(wǎng)絡(luò)上接收遠(yuǎn)端的數(shù)據(jù)后，經(jīng)過RTP處理，進(jìn)行解壓縮還原為音頻、視頻，再輸出到音箱、電視上。

從MCU看，接收方向上，使用UDP從網(wǎng)絡(luò)上接收終端的音頻、視頻數(shù)據(jù)后，經(jīng)過RTP處理，接著經(jīng)過服務(wù)質(zhì)量(QoS)處理，再發(fā)送到高速總線(highway，HW)上，供后續(xù)模塊進(jìn)行音頻、視頻的交換或混合等；在發(fā)送方向上與之相反，從HW上接收經(jīng)過交換或混合的音頻、視頻，經(jīng)過RTP處理后，再使用UDP發(fā)送到網(wǎng)絡(luò)上。以上所述，就是MCU里面的網(wǎng)絡(luò)處理模塊所做的主要事情，簡化為如下：即在接收方向上，依次有UDP接收、RTP處理、QoS處理、HW發(fā)送等4個步驟；在發(fā)送方向上，依次有HW接收、RTP處理、UDP發(fā)送等3個步驟。

傳統(tǒng)的做法里面，MCU的網(wǎng)絡(luò)處理模塊，對參與會議的每一個終端，都是按上述步驟處理的，即接收方向有4個處理步驟，發(fā)送方向有3個處理步驟，這種做法情況下，當(dāng)參與會議的終端數(shù)量增大時，需要的處理能力也隨之線性增加。為便于分析，我們把對某個終端的某個處理步驟稱為一個處理點。那么對于一個有64個終端參與的會議，接收方向共有64×4＝256個處理點，發(fā)送方向共有64×3＝192個處理點，總共有256+192＝448個處理點，這將要消耗很大的處理能力，甚至?xí)沟肕CU不堪重負(fù)而使會議無法正常進(jìn)行。MCU接收所有終端的視頻數(shù)據(jù)，發(fā)送給備板HW，在內(nèi)部進(jìn)行處理，從備板HW接收所有處理后的視頻數(shù)據(jù)，然后再發(fā)送給各個終端；

這種方法優(yōu)點是功能單一，實現(xiàn)簡單，缺點是：處理了大量的無關(guān)數(shù)據(jù)，性能低下，并且降低了MCU的資源利用率。

隨著視訊系統(tǒng)的大規(guī)模使用，系統(tǒng)容量要求越來越高，為了提高M(jìn)CU的處理能力，必須改進(jìn)媒體處理資源的利用，但是修改或者增加硬件配置又會提高成本，所以軟件的處理方法就變得更加重要。

發(fā)明內(nèi)容

本發(fā)明所要解決的問題是提供一種高效率利用MCU媒體處理能力的方法和裝置，在現(xiàn)有系統(tǒng)硬件不改變的前提下，通過改進(jìn)軟件設(shè)計，減少資源的浪費，提高處理資源的有效利用率，從而提高M(jìn)CU的處理能力，最終表現(xiàn)為擴(kuò)大MCU的會議終端容量，卻不影響系統(tǒng)任何現(xiàn)有功能。

為了實現(xiàn)上述目的，根據(jù)本發(fā)明的一個方面，提供了一種視頻數(shù)據(jù)處理方法。

該方法包括：第一步驟，在信令交互過程中，獲得需要接收和發(fā)送的終端信息；第二步驟，在上端過程中，主控制器向主處理器發(fā)送消視頻復(fù)用和視頻解復(fù)用消息；以及第三步驟，主處理器根據(jù)消視頻復(fù)用和解視頻復(fù)用消息在視頻接收方向和發(fā)送方向進(jìn)行處理，其中，在視頻接收方向上的處理方式包括：終端流控方式、網(wǎng)口過濾方式、邏輯信道的數(shù)據(jù)丟棄方式。

其中，在終端流控方式下，管理控制模塊向終端發(fā)送媒體流控消息，指示終端不產(chǎn)生視頻的編碼。并且，在網(wǎng)口過濾方式下，通過設(shè)置網(wǎng)絡(luò)過濾信息使得只接收要接收的數(shù)據(jù)包，對于要丟棄的數(shù)據(jù)包在網(wǎng)口直接丟棄。另外，在邏輯信道的數(shù)據(jù)丟棄方式下，數(shù)據(jù)接收到應(yīng)用后，根據(jù)通道是否接收數(shù)據(jù)包決定丟棄數(shù)據(jù)還是進(jìn)入下一步處理。