專利名稱：一種三方視頻會議的視頻實現(xiàn)方法
技術領域：
本發(fā)明涉及ー種三方視頻會議的視頻實現(xiàn)方法。
背景技術：
目前市面上支持三方會議功能的設備較多，但大多數(shù)為音頻會議設備，而視頻會議設備往往價格較高，這主要是由于大部分實現(xiàn)三方視頻會議功能算法對硬件要求較高，從而使得整體成本提升。傳統(tǒng)三方會議設備基本都是采用主持方接收其余兩方數(shù)據(jù)混合RTP數(shù)據(jù)后傳遞給另外兩方進行實現(xiàn)，其中音頻與視頻的實現(xiàn)方法各有所不同，下面針對這兩種實現(xiàn)類型進行分析
I、傳統(tǒng)音頻會議的實現(xiàn)方法
如圖I所示，A與C方實際并不直接傳遞數(shù)據(jù)，而是通過主持方B作為中轉(zhuǎn)站，將第三方的數(shù)據(jù)與B方自身的數(shù)據(jù)進行混合后傳遞給第二方，因此，主持方B的處理尤為重要，但由于音頻數(shù)據(jù)的處理相對較為簡單，因此，原則上只需多創(chuàng)建兩條線程對數(shù)據(jù)進行混合即可滿足要求。對于主持方B的三方音頻會議通話步驟為
Cl)主持方B創(chuàng)建針對A、C兩方的RTP接收端ロ的Socket，并進行監(jiān)聽等待；
(2)將主持方B自身所發(fā)出的聲音進行采樣；
(3)主持方B接收A方所傳輸過來的RTP音頻數(shù)據(jù)，解碼后在揚聲器中放出，并將解碼后的聲音數(shù)據(jù)與B方自身聲音混合后，打包為RTP數(shù)據(jù)包發(fā)送給協(xié)商網(wǎng)絡參數(shù)時C方的RTP接收端ロ ；
(4)(與步驟(3)并行)主持方B接收C方所傳輸過來的RTP音頻數(shù)據(jù)，解碼后在揚聲器中放出，并將解碼后的音頻數(shù)據(jù)與主持方B自身的混合后，打包為RTP數(shù)據(jù)包發(fā)送給協(xié)商網(wǎng)絡參數(shù)時A方的RTP接收端ロ ；
(5)這樣，A方聽到的聲音就為B/C兩方混合的聲音，B方聽到的聲音則為A/C雙方混合的聲音，C方聽到的聲音為A/B雙方混合的聲音,從而形成三方音頻會議。2、傳統(tǒng)視頻會議的實現(xiàn)方法
在視頻會議情況下，若不考慮硬件成本，采用如上音頻會議的方案也是可以實現(xiàn)的，并且可以達到參與方看到另ー參與方與主持方的效果，但由于使用該方案對硬件要求較高，而目前大部分的視頻話機都達不到該要求，因此，市面上的話機基本都退而求其之，只要三方都能夠聽到其余兩方的聲音，而參與方只要能看到主持方的視頻，主持方也只要能同時查看其中任一方的視頻即可。三方視頻會議中占用資源最多也最為復雜的是混合數(shù)據(jù)，因此，如圖2所示，主持方B去除了混合視頻數(shù)據(jù)的過程，而對于A/C兩方數(shù)據(jù)的處理是有區(qū)別的，主要是由于對于視頻通話來說，接收數(shù)據(jù)所占用的CPU相對于解碼數(shù)據(jù)來說是較少的，因此，節(jié)省資源最為有效的是減少解碼，故而去除了非當前激活的C方數(shù)據(jù)的解碼，只保留關鍵幀以方便后續(xù)重新查看時的解碼正常。因此，此時的CPU資源占用為三方音頻會議+單路純視頻通話+單路RTP數(shù)據(jù)接收 所占用的CPU總和，基本只是比起單路音視頻通話多占用音頻混合的資源損耗。對于主持方B的三方視頻會議通話步驟如下(音頻部分處理參見上面音頻會議的實現(xiàn)方法)
(1)主持方B創(chuàng)建針對A、C兩方RTP接收端ロ的Socket，并進行監(jiān)聽等待；
(2)將主持方B自身的視頻圖像進行采樣，并打包為RTP數(shù)據(jù)包，分別發(fā)送給協(xié)商網(wǎng)絡參數(shù)時A、C兩方的RTP接收端ロ ；
(3)假定主持方B設置A方視頻為當前顯示的主視頻，則主持方B接收A方所傳輸過來的RTP數(shù)據(jù),解碼后在顯示屏的FrameBuffer上顯示出來讓用戶可查看到；
(4)(與步驟(3)并行)B方接收C方所傳輸過來的RTP數(shù)據(jù)，但不進行解碼，只是存儲關鍵幀I幀數(shù)據(jù)，用于后續(xù)進行切換主視頻為C方后進行解碼補償，避免剛顯示時出現(xiàn)馬賽克現(xiàn)象；
(5)若主持方B此時設置主視頻為C方，則主持方B利用通信控制協(xié)議(SIP或自定義協(xié)議)請求C方重發(fā)I幀，從而更新最新視頻圖像，并將A、C兩方數(shù)據(jù)處理方式對換。上面的方案里解決了資源不足的問題，但仍存在以下問題
A、一方參與方無法查看到另ー參與方的視頻信息，失去三方會議最重要的原則:三方互相可聽可見；
B、主持方只能同時查看到某ー參與方視頻，若需要查看另一參與方的視頻就要進行切換，用戶操作較為麻煩。

發(fā)明內(nèi)容
本發(fā)明的目的在于提供一種可以控制住視頻資源損耗，在低成本的硬件運行環(huán)境下，會議三方可同時互相可聽可見的三方視頻會議的視頻實現(xiàn)方法。本發(fā)明ー種視頻三方會議的視頻實現(xiàn)方法，具體包括如下步驟
步驟I、主持方B創(chuàng)建針對兩個會議參與方A、C的RTP接收端ロ的Socket，并進行監(jiān)聽等待;
步驟2、主持方B將自身的視頻圖像進行采樣，并在主持方B的屏幕上的對應B方的顯示區(qū)域顯示B方的視頻；
步驟3、主持方B接收會議參與方A所傳輸過來的RTP數(shù)據(jù)，經(jīng)解碼后在主持方B的屏幕上對應會議參與方A的顯示區(qū)域顯示A方的視頻；
步驟4、(與步驟3并行)主持方B接收會議參與方C所傳輸過來的RTP數(shù)據(jù)，經(jīng)解碼后在主持方B的屏幕上對應會議參與方C的顯示區(qū)域顯示C方的視頻；
步驟5、主持方B截取自身屏幕上由A、B、C三方的顯示區(qū)域組成的聯(lián)合顯示區(qū)域，將其打包為RTP數(shù)據(jù)包，并將其分別發(fā)送給協(xié)商網(wǎng)絡參數(shù)時兩個會議參與方A、C的RTP接收端Π ；
步驟6、該兩會議參與方A、C將來自主持方B的截屏RTP數(shù)據(jù)解碼后在各自的屏幕上顯不O本發(fā)明進一歩將收發(fā)包與編解碼的處理步驟分離
主持方B在上述步驟I中創(chuàng)建完Socket后，創(chuàng)建獨立線程Tl用于接收來自A或C方的RTP數(shù)據(jù)包，并將其分別存放在兩個不同的公用隊列中，并且在接收前將公用隊列的數(shù)據(jù)加上訪問鎖，接收完成后將訪問鎖釋放，該訪問鎖用干與下面的解碼線程進行訪問同步； 另一條獨立解碼線程T2通過定時獲取上述兩公用隊列中的數(shù)據(jù)，將兩公用隊列中的所有數(shù)據(jù)取出后，將涉及整幀圖像的多個數(shù)據(jù)包同時進行解碼，這樣在毎次取數(shù)據(jù)前通過判斷此時公用隊列中積壓的數(shù)據(jù)包的數(shù)量，如超過閾值，則解碼線程T2在該情況出現(xiàn)后將中間的非關鍵幀去除直接解碼I幀，取出解碼前也需要將公用隊列的數(shù)據(jù)加上訪問鎖，解碼完成后將訪問鎖釋放；
解碼過程中解碼線程T2在毎次取數(shù)據(jù)前通過判斷此時公用隊列中積壓的數(shù)據(jù)包的數(shù)量，若超過閾值，則該解碼線程T2直接通過RTCP信令向數(shù)據(jù)發(fā)送方發(fā)送RTP數(shù)據(jù)包速率控制指令，請求減緩RTP數(shù)據(jù)包的發(fā)送速率；
編碼過程也以上述步驟處理。本發(fā)明利用屏幕的顯示資源，將在主持方屏幕上組合完成的三方視頻截取后進行編碼發(fā)送給會議參與方，在會議參與方的各自屏幕上分別顯示該主持方發(fā)來的截屏數(shù)據(jù)，這樣免去了混合視頻數(shù)據(jù)的資源占用。


圖I為傳統(tǒng)音頻會議實現(xiàn)方式的原理示意 圖2為傳統(tǒng)視頻會議實現(xiàn)方式的原理示意 圖3為本發(fā)明的流程示意 圖4為本發(fā)明進ー步改進的原理示意 圖5為本發(fā)明視頻會議實現(xiàn)方式的原理示意 以下結合附圖和具體實施例對本發(fā)明做進ー步詳述。
具體實施例方式如圖3、5所示，本發(fā)明ー種視頻三方會議的視頻實現(xiàn)方法，具體包括如下步驟 步驟I、主持方B創(chuàng)建針對兩個會議參與方A、C的RTP接收端ロ的Socket，并進行監(jiān)
聽等待；
步驟2、主持方B將自身的視頻圖像進行采樣，并在主持方B的屏幕上的對應B方的顯示區(qū)域顯示B方的視頻；
步驟3、主持方B接收會議參與方A所傳輸過來的RTP數(shù)據(jù)，經(jīng)解碼后在主持方B的屏幕上對應會議參與方A的顯示區(qū)域顯示A方的視頻；
步驟4、(與步驟3并行)主持方B接收會議參與方C所傳輸過來的RTP數(shù)據(jù)，經(jīng)解碼后在主持方B的屏幕上對應會議參與方C的顯示區(qū)域顯示C方的視頻；
步驟5、主持方B截取自身屏幕上由A、B、C三方的顯示區(qū)域組成的聯(lián)合顯示區(qū)域(如圖3所示可以是矩形)，并將其打包為RTP數(shù)據(jù)包，分別發(fā)送給協(xié)商網(wǎng)絡參數(shù)時兩個會議參與方A、C的RTP接收端ロ ；
步驟6、該兩會議參與方A、C將來自主持方B的截屏RTP數(shù)據(jù)解碼后在各自的屏幕上顯不O本發(fā)明ー種視頻三方會議的實現(xiàn)方法，主持方利用屏幕顯示資源，將組合完成的三方視頻截取進行編碼后發(fā)送給會議參與方，這樣免去混合視頻數(shù)據(jù)的資源占用，如圖3所示，從該CPU資源占用計算上可以看出，本發(fā)明雖然滿足了三方可以互相查看對方視頻的要求，但此時的資源占用還是要比其他話機多出一路視頻通話解碼，而對于視頻通話來說，視頻的解碼對資源要求也是較高的，尤其是在H264-CodeC下，而H264目前基本已成為視頻通話的首選Codec，因此，需要進ー步改進，將資源占用率再次下降。
如圖3所示，主持方B此時的CPU資源占用三方音頻會議+兩路純視頻通話解碼+截屏+單路視頻編碼+基本的網(wǎng)絡收發(fā)包總和。從本發(fā)明的CPU資源占用上來看，由于截屏本身的資源占用較低，同時在實現(xiàn)時使用數(shù)據(jù)緩存方式已基本達到最優(yōu)方案，因此重點還是在于解碼資源的利用上，而解決該問題最直接的方法當然是改進解碼算法，但由于目前所采用的解碼算法已為較為成熟的算法，同時若修改算法，則可能帶來較多兼容性問題，因此，從另一方面考慮，將突破點放在降低解碼時的資源占用上，而由于此時長期進行的操作只有編碼與網(wǎng)絡傳輸，而編碼的修改與解碼類似，故而從網(wǎng)絡傳輸?shù)馁Y源占用上考慮。首先，不可能降低網(wǎng)絡傳輸速率，其次，也不可能去除網(wǎng)絡包的發(fā)送，但可從避免網(wǎng)絡傳輸峰值的占用考慮。由于之前網(wǎng)絡發(fā)送與接收是與編解碼綁定的，即在同一線程處理，因此，造成解碼的速度會受到收發(fā)包的影響。如圖4所示，本發(fā)明進一歩將收發(fā)包與編解碼的處理步驟分離
主持方B在所述步驟I中創(chuàng)建完Socket后，創(chuàng)建獨立線程Tl用于接收來自A或C方的RTP數(shù)據(jù)包，并將其分別存放在兩個不同的公用隊列中，并且在接收前將公用隊列的數(shù)據(jù)加上訪問鎖，接收完成后將訪問鎖釋放，該訪問鎖用干與下面的解碼線程進行訪問同步；
另一條獨立解碼線程T2通過定時獲取上述兩公用隊列中的數(shù)據(jù)，將兩公用隊列中的所有數(shù)據(jù)取出后，多個數(shù)據(jù)包(即整幀圖像，一般為6個數(shù)據(jù)包左右)同時進行解碼，這樣在毎次取數(shù)據(jù)前通過判斷此時公用隊列中積壓的數(shù)據(jù)量，如超過20個數(shù)據(jù)包，則解碼線程在該情況出現(xiàn)后將中間的非關鍵幀(即非I幀)去除直接解碼I幀，避免由于數(shù)據(jù)包過多而造成本地頻繁解包，從而CPU占用過高的現(xiàn)象，取出解碼前也需要將公用隊列的數(shù)據(jù)加上訪問鎖，解碼完成后將訪問鎖釋放。解碼過程中解碼線程T2在毎次取數(shù)據(jù)前通過判斷此時公用隊列中積壓的數(shù)據(jù)量，如超過30個數(shù)據(jù)包，則該線程直接通過RTCP信令向數(shù)據(jù)發(fā)送方發(fā)送RTP數(shù)據(jù)包速率控制指令，請求減緩RTP數(shù)據(jù)包的發(fā)送速率，避免緩沖區(qū)不足。編碼過程也類似處理。這樣，可以通過多個數(shù)據(jù)共同解碼的方式避免原來通過同一線程將接收與解碼串行，造成數(shù)據(jù)積壓，從而頻繁取包等待，占用CPU資源較高的問題，也可以通過解碼線程根據(jù)當前積壓數(shù)據(jù)的量來請求數(shù)據(jù)發(fā)送方RTP數(shù)據(jù)包發(fā)送的速率，從而可以控制整體傳輸帶寬。以上所述，僅是本發(fā)明較佳實施例而已，并非對本發(fā)明的技術范圍作任何限制，故凡是依據(jù)本發(fā)明的技術實質(zhì)對以上實施例所作的任何細微修改、等同變化與修飾，均仍屬于本發(fā)明技術方案的范圍內(nèi)。
權利要求
1.一種視頻三方會議的視頻實現(xiàn)方法，其特征在于包括如下步驟 步驟I、主持方B創(chuàng)建針對兩個會議參與方A、C的RTP接收端ロ的Socket，并進行監(jiān)聽等待; 步驟2、主持方B將自身的視頻圖像進行采樣，并在主持方B的屏幕上的對應B方的顯示區(qū)域顯示B方的視頻； 步驟3、主持方B接收會議參與方A所傳輸過來的RTP數(shù)據(jù)，經(jīng)解碼后在主持方B的屏幕上對應會議參與方A的顯示區(qū)域顯示A方的視頻； 步驟4、(與步驟3并行)主持方B接收會議參與方C所傳輸過來的RTP數(shù)據(jù)，經(jīng)解碼后在主持方B的屏幕上對應會議參與方C的顯示區(qū)域顯示C方的視頻； 步驟5、主持方B截取自身屏幕上由A、B、C三方的顯示區(qū)域組成的聯(lián)合顯示區(qū)域，將其打包為RTP數(shù)據(jù)包，并將其分別發(fā)送給協(xié)商網(wǎng)絡參數(shù)時兩個會議參與方A、C的RTP接收端Π ； 步驟6、該兩會議參與方A、C將來自主持方B的截屏RTP數(shù)據(jù)解碼后在各自的屏幕上顯不O
2.根據(jù)權利要求I所述的ー種視頻三方會議的視頻實現(xiàn)方法，其特征在于進ー步將收發(fā)包與編解碼的處理步驟分離 主持方B在上述步驟I中創(chuàng)建完Socket后，創(chuàng)建獨立線程Tl用于接收來自A或C方的RTP數(shù)據(jù)包，并將其分別存放在兩個不同的公用隊列中，并且在接收前將公用隊列的數(shù)據(jù)加上訪問鎖，接收完成后將訪問鎖釋放，該訪問鎖用干與下面的解碼線程進行訪問同步； 另一條獨立解碼線程T2通過定時獲取上述兩公用隊列中的數(shù)據(jù)，將兩公用隊列中的所有數(shù)據(jù)取出后，將涉及整幀圖像的多個數(shù)據(jù)包同時進行解碼，這樣在毎次取數(shù)據(jù)前通過判斷此時公用隊列中積壓的數(shù)據(jù)包的數(shù)量，如超過閾值，則解碼線程T2在該情況出現(xiàn)后將中間的非關鍵幀去除直接解碼I幀，取出解碼前也需要將公用隊列的數(shù)據(jù)加上訪問鎖，解碼完成后將訪問鎖釋放； 解碼過程中解碼線程T2在毎次取數(shù)據(jù)前通過判斷此時公用隊列中積壓的數(shù)據(jù)包的數(shù)量，若超過閾值，則該解碼線程T2直接通過RTCP信令向數(shù)據(jù)發(fā)送方發(fā)送RTP數(shù)據(jù)包速率控制指令，請求減緩RTP數(shù)據(jù)包的發(fā)送速率； 編碼過程也以上述步驟處理。
全文摘要
本發(fā)明一種視頻三方會議的視頻實現(xiàn)方法，主持方利用屏幕的顯示資源，將在主持方屏幕上組合完成的三方視頻截取后進行編碼發(fā)送給會議參與方，在會議參與方的各自屏幕上分別顯示該主持方發(fā)來的截屏數(shù)據(jù)，這樣免去了混合視頻數(shù)據(jù)的資源占用，從而可以控制住視頻資源損耗，在低成本的硬件運行環(huán)境下，會議三方可同時互相可聽可見。
文檔編號H04N7/15GK102625079SQ20121007593
公開日2012年8月1日 申請日期2012年3月21日 優(yōu)先權日2012年3月21日
發(fā)明者艾志敏 申請人:廈門億聯(lián)網(wǎng)絡技術有限公司