背景
最近同社は、コールとして2つのマイクロ文字の機能の基本的なバージョンを達成するだけでなく、マルチオーディオおよびビデオ会議が同様に呼び出しをサポートするためだけでなく、研究プロジェクトからIMでのオーディオおよびビデオ通信をサポートするための機能を追加する必要があります。、我々は考えるかもしれない、ここを参照してください
非常に単純なこと、それはない、オーディオおよびビデオ機能を向上させますか？？クラウドコミュニケーションプラットフォームSDKからの直接アクセスはそれで逃げますか？それには困難がありません。
実際には、このような一般的なビジネスアプリケーションは、大きな問題を達成するために、同社は常に比較的剛性の要件となっている、すべてのものは、あなたがのためとして、（オープンソースコードを使用することができますが、SDKを使用することができないことを意味自習要件、あります何、）...と言ってあまりありません。IMプロジェクトの現在の自己開発を含め、すべてのエンジンとオープンソース、過SDKの無い他の使用の研究に基づいて開発されました。
技術選択
私は、SDKを使用することはできませんので、あなただけの弾丸をかむと、自分の各機能を実現することができます。いくつかのチームは、アカウントに関連するオーディオやビデオのプロジェクトを取る前に行っている、戦闘経験の欠如は、これは0-1からのプロジェクトがあり、そしてチームは、それが技術的に言えば、非常に大きな課題である、ペアであります高い技術的要件、基礎となる技術的なシステム部分プログラム。そのため、直接には自分のオーディオおよびビデオシステムを渡す実現するために、我々はオープンソースプロジェクトに基づいて二次開発を選択し、オープンソースを採用することにしました。だから、どのように我々はオープンソースプロジェクトの右のチームが行う選ぶのですか？プロジェクトは、マルチオーディオおよびビデオ機能をサポートするために必要であることを考えると、私たちは市場での研究のシリーズを行い、最終的にいくつかのオプションに来る：
▸ のWebRTC
▸ h323plush
▸ Live555では
▸ OpenMeetings
1つのWebRTC
世界で最も先進的なリアルタイムのオーディオおよびビデオ通信技術、ネットワーク伝送モジュール、収集モジュール、オーディオとビデオのエンコードとAndroid / IOSを含む他のパッケージで行わ非常に有力なプロジェクトとして知られているオープンソースのブラウザプロジェクトに基づいて、Googleのオープンソースリアルタイム通信、実現/ウェブや他の主流の側、その最大の特徴は、ブラウザで直接、オーディオとビデオの通信が可能です。短所：しかし、このプロジェクトは、マルチオーディオおよびビデオ会議をサポートしていません。
2 h323plus
これは、ほとんどが、それは、このようなMCUサーバなどのビデオ会議の多数の実装の参考例があり、オーディオおよびビデオ会議機能など、H.323プロトコル機能のすべてを含むオープンソースのオーディオおよびビデオ・システムの古いセットを、成熟考えることができます。従来のLAN、オーディオおよびビデオ会議でのプロジェクトアプリケーションは、一般的なアプリケーションは、このような学校の用途に地方政府の会議として、それは一緒にハードウェアのサポートに使用する必要があります。
3 Live555では
C ++有名なストリーミング・メディア・サーバなどのトランスポートプロトコル（SIP、RTP）、オーディオおよびビデオエンコーダ（H.264、MPEG4）だけでなく、を含む、また、その送信モジュール、プロジェクトのための選択のストリーミングメディア、ストリーミングメディアサーバの例を含みますビデオ会議は、リファレンスとして開発価値があるが、それはサーバーのみをサポートし、クライアントは、達成するために行かなければなりません
4 OpenMeetings
主にフラッシュクライアントのオープンソースプロジェクトに基づいてOpenMeetingsは、コア技術は、オーディオおよびビデオ会議、ホワイトボードや他の開発言語を含む他のオープンソースのRed5に基づいており、Javaのです
项目名称 | h323plus | webrtc | live555 | OpenMeetings
------- | --------------- | --------- | -------- | --------------
使用场景 | 基于局域网高清联机会议| 互联网行业 | 只用作服务器 | 互联网行业
缺点 | 对手机端支持不够 | 暂无 |没有实现客户端 | 只支持flash客户端
开源语言 | c | c++/node.js/go | c++ | java
上記の比較から見ると、我々は非常にはるかに成熟して、現在主流の高精細ビデオ会議にh323plus LANものの、のWebRTCの優先順位とh322plus 2つのオープンソースプロジェクトを比較したが、私たちのアプリケーションの視野はインターネットである、提供する必要性5末端（アンドロイド/ IOS / H5 / PC / MAC） クライアント機能、私たちは、オーディオとビデオのWebRTCプロジェクトの開発を使用することにしました。
前述したように、利点は、シングルポイント（P2P）ビデオ通信間の音のWebRTCプロジェクトは、人々は、オーディオおよびビデオ通信をサポートしていませんが、プロジェクトは多人数ビデオ会議を実現するために必要なオーディオおよびビデオ機能を実現するために必要とされる以上を必要とすることですサポートすることができますサーバー側のプログラム開発が必要でなければなりません（損失の多くを食べる前にこのチームを、私たちは、研究のWebRTCでのマルチオーディオとビデオをサポートする方法について多くの時間を費やしたが、最終的に研究によってサポートされていない）
以上のものを達成するために、人々は三つの可能なモード、すなわち理解するために、関数を呼び出す：メッシュモード、MCUモード、SFUモード、メッシュモデルは、クライアントの実装に主に依存しているが、後者の2つのモデルがサーバの実装に依存している、彼らの長所と短所が異なっています。
メッシュパターン
また、メッシュモードとして知られている、我々は彼らのオーディオおよびビデオデータが均等にも他のクライアントからのデータを受け入れる一方で、他のクライアントに配布する一方で、各クライアント間の接続を確立しました。欠点は、一定数（5）クライアントの参加よりも後に、クライアントが非常に困難になることです。
MCUモード
融合後、またMCUモデルサーバは、各クライアントに転送融合圧縮符号化ストリームに合わせ各クライアントと混合メディア・ストリーム（視聴覚区別）のためのサーバとしても知られています。比較的メッシュモードでは、クライアントが1つだけ送信し、データが大幅にサーバーのコストの増加に対応する費用で、当然のことながら、クライアントへの圧力を軽減するためにすべての方法をストリーミング受信する必要があります。
SFUモード
SFU（選択転送単位）は、選択的転送サービスを呼び出し、必要に応じて選択MCUモードのクライアントに比べて、クライアントにデータ・ストリームを転送するサーバは、単一のストリームを受信し、クライアントが複数のサーバから受け取りますストリームを介して転送、ビジネス層より簡単に拡張。
いくつかのモデルの比較
そのため、一般的に2つのモードの選択の後ろ以上を達成するために、設計原理は、主に、システムをより良いパフォーマンスと機能を拡張し、より複雑なシナリオをサポートするために、再点灯クライアントサービス側に取られている従来の一般的なインターネットアプリケーション、オーディオおよびビデオ機能。
結論
自分のチームと組み合わせることで、最終的な選択はのWebRTC技術システムに基づいて、オーディオおよびビデオ機能を実装します。WebRTCによるオーディオおよびビデオ機能を実現するP2P。マルチオーディオとビデオをサポートするために、独立した研究開発チームはのWebRTCサーバー製品のプロジェクトを必要とする複数の画面表示もダイナミックマイクの操作が必要なので、サポートマルチオーディオおよびビデオ機能など、サーバのMCU / SFU混合モードを選択します。オープンソースプロジェクトのより多くのサポートMCU / SFUモード、コンテンツがより多くの、それは次回の記事で紹介されますされます。。
考えます
あなたは、リアルタイムのオーディオおよびビデオシステムを実現するために作ると仮定し、あなたはそれを何を意味するのかによって、技術的な研究と技術の選択ですか？BaiduのGoogleや他のより効率的な方法は、それを介してますか？？ウェルカムメッセージ交換