一種三方視頻會議的視頻實現方法
2023-04-28 09:33:26 1
專利名稱：一種三方視頻會議的視頻實現方法
技術領域：
本發明涉及ー種三方視頻會議的視頻實現方法。
背景技術：
目前市面上支持三方會議功能的設備較多，但大多數為音頻會議設備，而視頻會議設備往往價格較高，這主要是由於大部分實現三方視頻會議功能算法對硬體要求較高，從而使得整體成本提升。傳統三方會議設備基本都是採用主持方接收其餘兩方數據混合RTP數據後傳遞給另外兩方進行實現，其中音頻與視頻的實現方法各有所不同，下面針對這兩種實現類型進行分析
I、傳統音頻會議的實現方法
如圖I所示，A與C方實際並不直接傳遞數據，而是通過主持方B作為中轉站，將第三方的數據與B方自身的數據進行混合後傳遞給第二方，因此，主持方B的處理尤為重要，但由於音頻數據的處理相對較為簡單，因此，原則上只需多創建兩條線程對數據進行混合即可滿足要求。對於主持方B的三方音頻會議通話步驟為
Cl)主持方B創建針對A、C兩方的RTP接收端ロ的Socket，並進行監聽等待；
(2)將主持方B自身所發出的聲音進行採樣；
(3)主持方B接收A方所傳輸過來的RTP音頻數據，解碼後在揚聲器中放出，並將解碼後的聲音數據與B方自身聲音混合後，打包為RTP數據包發送給協商網絡參數時C方的RTP接收端ロ ；
(4)(與步驟(3)並行)主持方B接收C方所傳輸過來的RTP音頻數據，解碼後在揚聲器中放出，並將解碼後的音頻數據與主持方B自身的混合後，打包為RTP數據包發送給協商網絡參數時A方的RTP接收端ロ ；
(5)這樣，A方聽到的聲音就為B/C兩方混合的聲音，B方聽到的聲音則為A/C雙方混合的聲音，C方聽到的聲音為A/B雙方混合的聲音,從而形成三方音頻會議。2、傳統視頻會議的實現方法
在視頻會議情況下，若不考慮硬體成本，採用如上音頻會議的方案也是可以實現的，並且可以達到參與方看到另ー參與方與主持方的效果，但由於使用該方案對硬體要求較高，而目前大部分的視頻話機都達不到該要求，因此，市面上的話機基本都退而求其之，只要三方都能夠聽到其餘兩方的聲音，而參與方只要能看到主持方的視頻，主持方也只要能同時查看其中任一方的視頻即可。三方視頻會議中佔用資源最多也最為複雜的是混合數據，因此，如圖2所示，主持方B去除了混合視頻數據的過程，而對於A/C兩方數據的處理是有區別的，主要是由於對於視頻通話來說，接收數據所佔用的CPU相對於解碼數據來說是較少的，因此，節省資源最為有效的是減少解碼，故而去除了非當前激活的C方數據的解碼，只保留關鍵幀以方便後續重新查看時的解碼正常。因此，此時的CPU資源佔用為三方音頻會議+單路純視頻通話+單路RTP數據接收 所佔用的CPU總和，基本只是比起單路音視頻通話多佔用音頻混合的資源損耗。對於主持方B的三方視頻會議通話步驟如下(音頻部分處理參見上面音頻會議的實現方法)
(1)主持方B創建針對A、C兩方RTP接收端ロ的Socket，並進行監聽等待；
(2)將主持方B自身的視頻圖像進行採樣，並打包為RTP數據包，分別發送給協商網絡參數時A、C兩方的RTP接收端ロ ；
(3)假定主持方B設置A方視頻為當前顯示的主視頻，則主持方B接收A方所傳輸過來的RTP數據,解碼後在顯示屏的FrameBuffer上顯示出來讓用戶可查看到；
(4)(與步驟(3)並行)B方接收C方所傳輸過來的RTP數據，但不進行解碼，只是存儲關鍵幀I幀數據，用於後續進行切換主視頻為C方後進行解碼補償，避免剛顯示時出現馬賽克現象；
(5)若主持方B此時設置主視頻為C方，則主持方B利用通信控制協議(SIP或自定義協議)請求C方重發I幀，從而更新最新視頻圖像，並將A、C兩方數據處理方式對換。上面的方案裡解決了資源不足的問題，但仍存在以下問題
A、一方參與方無法查看到另ー參與方的視頻信息，失去三方會議最重要的原則:三方互相可聽可見；
B、主持方只能同時查看到某ー參與方視頻，若需要查看另一參與方的視頻就要進行切換，用戶操作較為麻煩。
發明內容
本發明的目的在於提供一種可以控制住視頻資源損耗，在低成本的硬體運行環境下，會議三方可同時互相可聽可見的三方視頻會議的視頻實現方法。本發明ー種視頻三方會議的視頻實現方法，具體包括如下步驟
步驟I、主持方B創建針對兩個會議參與方A、C的RTP接收端ロ的Socket，並進行監聽等待;
步驟2、主持方B將自身的視頻圖像進行採樣，並在主持方B的屏幕上的對應B方的顯示區域顯示B方的視頻；
步驟3、主持方B接收會議參與方A所傳輸過來的RTP數據，經解碼後在主持方B的屏幕上對應會議參與方A的顯示區域顯示A方的視頻；
步驟4、(與步驟3並行)主持方B接收會議參與方C所傳輸過來的RTP數據，經解碼後在主持方B的屏幕上對應會議參與方C的顯示區域顯示C方的視頻；
步驟5、主持方B截取自身屏幕上由A、B、C三方的顯示區域組成的聯合顯示區域，將其打包為RTP數據包，並將其分別發送給協商網絡參數時兩個會議參與方A、C的RTP接收端Π ；
步驟6、該兩會議參與方A、C將來自主持方B的截屏RTP數據解碼後在各自的屏幕上顯不O本發明進一歩將收發包與編解碼的處理步驟分離
主持方B在上述步驟I中創建完Socket後，創建獨立線程Tl用於接收來自A或C方的RTP數據包，並將其分別存放在兩個不同的公用隊列中，並且在接收前將公用隊列的數據加上訪問鎖，接收完成後將訪問鎖釋放，該訪問鎖用幹與下面的解碼線程進行訪問同步； 另一條獨立解碼線程T2通過定時獲取上述兩公用隊列中的數據，將兩公用隊列中的所有數據取出後，將涉及整幀圖像的多個數據包同時進行解碼，這樣在毎次取數據前通過判斷此時公用隊列中積壓的數據包的數量，如超過閾值，則解碼線程T2在該情況出現後將中間的非關鍵幀去除直接解碼I幀，取出解碼前也需要將公用隊列的數據加上訪問鎖，解碼完成後將訪問鎖釋放；
解碼過程中解碼線程T2在毎次取數據前通過判斷此時公用隊列中積壓的數據包的數量，若超過閾值，則該解碼線程T2直接通過RTCP信令向數據發送方發送RTP數據包速率控制指令，請求減緩RTP數據包的發送速率；
編碼過程也以上述步驟處理。本發明利用屏幕的顯示資源，將在主持方屏幕上組合完成的三方視頻截取後進行編碼發送給會議參與方，在會議參與方的各自屏幕上分別顯示該主持方發來的截屏數據，這樣免去了混合視頻數據的資源佔用。
圖I為傳統音頻會議實現方式的原理示意 圖2為傳統視頻會議實現方式的原理示意 圖3為本發明的流程示意 圖4為本發明進ー步改進的原理示意 圖5為本發明視頻會議實現方式的原理示意 以下結合附圖和具體實施例對本發明做進ー步詳述。
具體實施例方式如圖3、5所示，本發明ー種視頻三方會議的視頻實現方法，具體包括如下步驟 步驟I、主持方B創建針對兩個會議參與方A、C的RTP接收端ロ的Socket，並進行監
聽等待；
步驟2、主持方B將自身的視頻圖像進行採樣，並在主持方B的屏幕上的對應B方的顯示區域顯示B方的視頻；
步驟3、主持方B接收會議參與方A所傳輸過來的RTP數據，經解碼後在主持方B的屏幕上對應會議參與方A的顯示區域顯示A方的視頻；
步驟4、(與步驟3並行)主持方B接收會議參與方C所傳輸過來的RTP數據，經解碼後在主持方B的屏幕上對應會議參與方C的顯示區域顯示C方的視頻；
步驟5、主持方B截取自身屏幕上由A、B、C三方的顯示區域組成的聯合顯示區域(如圖3所示可以是矩形)，並將其打包為RTP數據包，分別發送給協商網絡參數時兩個會議參與方A、C的RTP接收端ロ ；
步驟6、該兩會議參與方A、C將來自主持方B的截屏RTP數據解碼後在各自的屏幕上顯不O本發明ー種視頻三方會議的實現方法，主持方利用屏幕顯示資源，將組合完成的三方視頻截取進行編碼後發送給會議參與方，這樣免去混合視頻數據的資源佔用，如圖3所示，從該CPU資源佔用計算上可以看出，本發明雖然滿足了三方可以互相查看對方視頻的要求，但此時的資源佔用還是要比其他話機多出一路視頻通話解碼，而對於視頻通話來說，視頻的解碼對資源要求也是較高的，尤其是在H264-CodeC下，而H264目前基本已成為視頻通話的首選Codec，因此，需要進ー步改進，將資源佔用率再次下降。
如圖3所示，主持方B此時的CPU資源佔用三方音頻會議+兩路純視頻通話解碼+截屏+單路視頻編碼+基本的網絡收發包總和。從本發明的CPU資源佔用上來看，由於截屏本身的資源佔用較低，同時在實現時使用數據緩存方式已基本達到最優方案，因此重點還是在於解碼資源的利用上，而解決該問題最直接的方法當然是改進解碼算法，但由於目前所採用的解碼算法已為較為成熟的算法，同時若修改算法，則可能帶來較多兼容性問題，因此，從另一方面考慮，將突破點放在降低解碼時的資源佔用上，而由於此時長期進行的操作只有編碼與網絡傳輸，而編碼的修改與解碼類似，故而從網絡傳輸的資源佔用上考慮。首先，不可能降低網絡傳輸速率，其次，也不可能去除網絡包的發送，但可從避免網絡傳輸峰值的佔用考慮。由於之前網絡發送與接收是與編解碼綁定的，即在同一線程處理，因此，造成解碼的速度會受到收發包的影響。如圖4所示，本發明進一歩將收發包與編解碼的處理步驟分離
主持方B在所述步驟I中創建完Socket後，創建獨立線程Tl用於接收來自A或C方的RTP數據包，並將其分別存放在兩個不同的公用隊列中，並且在接收前將公用隊列的數據加上訪問鎖，接收完成後將訪問鎖釋放，該訪問鎖用幹與下面的解碼線程進行訪問同步；
另一條獨立解碼線程T2通過定時獲取上述兩公用隊列中的數據，將兩公用隊列中的所有數據取出後，多個數據包(即整幀圖像，一般為6個數據包左右)同時進行解碼，這樣在毎次取數據前通過判斷此時公用隊列中積壓的數據量，如超過20個數據包，則解碼線程在該情況出現後將中間的非關鍵幀(即非I幀)去除直接解碼I幀，避免由於數據包過多而造成本地頻繁解包，從而CPU佔用過高的現象，取出解碼前也需要將公用隊列的數據加上訪問鎖，解碼完成後將訪問鎖釋放。解碼過程中解碼線程T2在毎次取數據前通過判斷此時公用隊列中積壓的數據量，如超過30個數據包，則該線程直接通過RTCP信令向數據發送方發送RTP數據包速率控制指令，請求減緩RTP數據包的發送速率，避免緩衝區不足。編碼過程也類似處理。這樣，可以通過多個數據共同解碼的方式避免原來通過同一線程將接收與解碼串行，造成數據積壓，從而頻繁取包等待，佔用CPU資源較高的問題，也可以通過解碼線程根據當前積壓數據的量來請求數據發送方RTP數據包發送的速率，從而可以控制整體傳輸帶寬。以上所述，僅是本發明較佳實施例而已，並非對本發明的技術範圍作任何限制，故凡是依據本發明的技術實質對以上實施例所作的任何細微修改、等同變化與修飾，均仍屬於本發明技術方案的範圍內。
權利要求
1.一種視頻三方會議的視頻實現方法，其特徵在於包括如下步驟 步驟I、主持方B創建針對兩個會議參與方A、C的RTP接收端ロ的Socket，並進行監聽等待; 步驟2、主持方B將自身的視頻圖像進行採樣，並在主持方B的屏幕上的對應B方的顯示區域顯示B方的視頻； 步驟3、主持方B接收會議參與方A所傳輸過來的RTP數據，經解碼後在主持方B的屏幕上對應會議參與方A的顯示區域顯示A方的視頻； 步驟4、(與步驟3並行)主持方B接收會議參與方C所傳輸過來的RTP數據，經解碼後在主持方B的屏幕上對應會議參與方C的顯示區域顯示C方的視頻； 步驟5、主持方B截取自身屏幕上由A、B、C三方的顯示區域組成的聯合顯示區域，將其打包為RTP數據包，並將其分別發送給協商網絡參數時兩個會議參與方A、C的RTP接收端Π ； 步驟6、該兩會議參與方A、C將來自主持方B的截屏RTP數據解碼後在各自的屏幕上顯不O
2.根據權利要求I所述的ー種視頻三方會議的視頻實現方法，其特徵在於進ー步將收發包與編解碼的處理步驟分離 主持方B在上述步驟I中創建完Socket後，創建獨立線程Tl用於接收來自A或C方的RTP數據包，並將其分別存放在兩個不同的公用隊列中，並且在接收前將公用隊列的數據加上訪問鎖，接收完成後將訪問鎖釋放，該訪問鎖用幹與下面的解碼線程進行訪問同步； 另一條獨立解碼線程T2通過定時獲取上述兩公用隊列中的數據，將兩公用隊列中的所有數據取出後，將涉及整幀圖像的多個數據包同時進行解碼，這樣在毎次取數據前通過判斷此時公用隊列中積壓的數據包的數量，如超過閾值，則解碼線程T2在該情況出現後將中間的非關鍵幀去除直接解碼I幀，取出解碼前也需要將公用隊列的數據加上訪問鎖，解碼完成後將訪問鎖釋放； 解碼過程中解碼線程T2在毎次取數據前通過判斷此時公用隊列中積壓的數據包的數量，若超過閾值，則該解碼線程T2直接通過RTCP信令向數據發送方發送RTP數據包速率控制指令，請求減緩RTP數據包的發送速率； 編碼過程也以上述步驟處理。
全文摘要
本發明一種視頻三方會議的視頻實現方法，主持方利用屏幕的顯示資源，將在主持方屏幕上組合完成的三方視頻截取後進行編碼發送給會議參與方，在會議參與方的各自屏幕上分別顯示該主持方發來的截屏數據，這樣免去了混合視頻數據的資源佔用，從而可以控制住視頻資源損耗，在低成本的硬體運行環境下，會議三方可同時互相可聽可見。
文檔編號H04N7/15GK102625079SQ20121007593
公開日2012年8月1日 申請日期2012年3月21日 優先權日2012年3月21日
發明者艾志敏 申請人:廈門億聯網絡技術有限公司