[發明專利]一種三方視頻會議的視頻實現方法

有效

• 申請號: 201210075934.2
• 申請日: 2012-03-21
• 公開（公告）號: CN102625079A
• 公開（公告）日: 2012-08-01
• 發明（設計）人: 艾志敏
• 申請（專利權）人: 廈門億聯網絡技術有限公司
• 主分類號: H04N7/15
• 分類號: H04N7/15;H04N7/14
• 代理公司: 廈門市新華專利商標代理有限公司 35203
• 代理人: 朱凌

技術領域

本發明涉及一種三方視頻會議的視頻實現方法。

背景技術

目前市面上支持三方會議功能的設備較多，但大多數為音頻會議設備，而視頻會議設備往往價格較高，這主要是由于大部分實現三方視頻會議功能算法對硬件要求較高，從而使得整體成本提升。

傳統三方會議設備基本都是采用主持方接收其余兩方數據混合RTP數據后傳遞給另外兩方進行實現，其中音頻與視頻的實現方法各有所不同，下面針對這兩種實現類型進行分析：

1、傳統音頻會議的實現方法：

如圖1所示，A與C方實際并不直接傳遞數據，而是通過主持方B作為中轉站，將第三方的數據與B方自身的數據進行混合后傳遞給第二方，因此，主持方B的處理尤為重要，但由于音頻數據的處理相對較為簡單，因此，原則上只需多創建兩條線程對數據進行混合即可滿足要求。對于主持方B的三方音頻會議通話步驟為：

（1）主持方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、主持方只能同時查看到某一參與方視頻，若需要查看另一參與方的視頻就要進行切換，用戶操作較為麻煩。

發明內容

本發明的目的在于提供一種可以控制住視頻資源損耗，在低成本的硬件運行環境下，會議三方可同時互相可聽可見的三方視頻會議的視頻實現方法。

本發明一種視頻三方會議的視頻實現方法，具體包括如下步驟：

步驟1、主持方B創建針對兩個會議參與方A、C的RTP接收端口的Socket，并進行監聽等待；