現在のオープンソース WebRTC プロジェクトテクノロジの選択

序文

現在、Webrtc 技術は成熟しており、大手企業が自社製品に Webrtc 機能を組み込んでいますが、Webrtc は映像・音声通信の実現に加えて、シグナリング伝送も実現する必要があり、Webrtc のコアモジュールはストリーム転送モジュールです。ストリーミングメディアサーバーです。ストリーミングメディアサーバーを自分で実装したい場合は、DTLS プロトコル、ICE プロトコル、SRTP/SRTCP プロトコルなどを研究する必要があるため、まだ比較的難しく、時間的コストがかかります。これらのプロトコルを理解するには多くの時間がかかりますが、実装はおろか、それほど時間もかからないため、オープンソース実装を使用するのが最も簡単な方法です。この記事では、いくつかのオープンソース webrtc を紹介し、比較します。

音声およびビデオ会議システムを迅速に構築したい場合は、オープンソーステクノロジソリューションを使用することが間違いなく最も早い方法であり、人件費と時間コストを最も節約できます。以下では、一般的なビデオ会議コアモジュール (ストリーム転送サーバー) SFU オープンソースソリューションの長所と短所を分析し、適切なオープンソースソリューションを選択するための参考情報を提供します。

1.メディアスープ

Mediasoup は、長い間起動されていない WebRTC ストリーミングメディアサーバーのオープンソースライブラリであり、アドレスは https://github.com/versatica/mediasoupです。

Mediasoup はアプリケーション層とデータ処理層で構成されます。アプリケーション層は Node.js によって実装され、データ処理層は DTLS プロトコル実装、ICE プロトコル実装、SRTP/SRTCP プロトコル実装、ルーティングと転送などを含む C++ 言語によって実装されます。

Mediasoup は各インスタンスをワーカーと呼びます。ワーカー内には複数のルーターがあり、各ルーターは部屋に相当します。各ルームには複数のユーザーまたは参加者が存在することができ、各参加者は Mediasoup のトランスポートによって表されます。つまり、ルーム（ルーター）にとって、トランスポートはユーザーに相当します。

Transport には、WebRtcTransport、PlainRtpTransport、PipeTransport の 3 種類があります。

WebRtcTransport は、ブラウザなどの WebRTC タイプのクライアントに接続するために使用されます。
PlainRtpTransport は従来の RTP クライアントとの接続に使用され、これを通じてマルチメディアファイルや FFmpeg プッシュストリームを再生できます。
PipeTransport はルーター間の接続に使用されます。つまり、ある部屋のオーディオおよびビデオストリームが PipeTransport を介して別の部屋に送信されます。

各トランスポートには複数のプロデューサーとコンシューマーを含めることができます。

プロデューサーはメディアストリームの共有者を表し、オーディオの共有者とビデオの共有者の 2 つのタイプに分けられます。
Consumer はメディアストリームのコンシューマを表し、これもオーディオコンシューマとビデオコンシューマの 2 つのタイプに分けられます。
Mediasoup の実装ロジックは非常に明確で、上位層アプリケーションがどのように実行されるべきかには考慮せず、基礎となるデータの送信のみを考慮し、それを究極のものにします。

Mediasoup の最下層は C++ で開発されており、非同期 IO イベント処理ライブラリとして libuv が使用されているため、高いパフォーマンスが保証されています。同時に、リアルタイム送信のためのほぼすべての WebRTC 最適化をサポートしているため、特に優れた WebRTC SFU ストリーミングサーバーです。Janus と比較すると、Janus はデータ送信のリアルタイムパフォーマンス、効率性、シンプルさに重点を置いていますが、Janus は Mediasoup よりも多くの機能を備えており、そのアーキテクチャとロジックはより複雑です。

比較的強力な開発能力を持つ企業にとって、自社のビジネスニーズに応じて Mediasoup で二次開発を行うことも強く推奨される技術ソリューションです。

携帯電話側では、Android および iOS SDK を自分で実装する必要があります

2.ライコード

LicodeはSFU型ストリーミングサーバーとしてもMCU型ストリーミングサーバーとしても利用可能です。一般的にはSFUタイプのストリーミングメディアサーバーに使用されます。

Licode は、ストリーミングメディアコミュニケーションサーバーであるだけでなく、メディアコミュニケーション層、ビジネス層、ユーザー管理などの機能を含む完全なシステムであり、分散展開もサポートしています。

Licode は C++ および Node.js 言語によって実装されます。このうち、メディア通信部分はC++言語で実現し、シグナリング制御、ユーザー管理、ルーム管理はNode.jsで実現しています。ソースアドレスは https://github.com/lynckia/licodeです。次の図は、Licode の全体的なアーキテクチャです。

この図から、Licode は機能レベルで Nuve、ErizoController、ErizoAgent の 3 つの部分に分かれており、メッセージキューを介して通信していることがわかります。

Nuve は、ユーザー、ルームの管理、トークンの生成、およびルームの負荷分散を行うための Web サービスです。MangoDB を使用してルームとトークンの情報を保存しますが、ユーザー情報は保存しません。
ErizoController は、管理制御、シグナリング、および非オーディオおよびビデオデータの受信に使用されます。メッセージキューを介してNuveと通信します。つまり、Nuveはメッセージキューを介してErizoControllerを制御できます。
ErizoAgent は、オーディオおよびビデオのストリーミングデータの送信に使用され、分散方式で導入できます。ErizoAgent と ErizoController 間の通信もメッセージキューを介して行われ、シグナリングメッセージは ErizoController で受信された後、メッセージキューを介して ErizoAgent に送信され、ErizoAgent の制御が実現されます。

icodeは単なるSFUストリーミングメディアサーバーではなく、ストリーミングメディア関連の業務管理システムやシグナリングシステム、ストリーミングメディアサーバーやクライアントSDKなどが含まれており、比較的完成度の高い製品と言えるでしょう。

Licodeをストリーミングサーバーとして利用すれば、基本的に二次開発が不要となるため、音声や映像の蓄積がない企業や個人にとっては非常に魅力的なシステムです。現在、インテル CS プロジェクトは Licode をベースに開発され、多くの企業にサービスを提供しています。

公式ウェブサイトでは学習デモやドキュメントを提供しています。

ただし、Licode には次のような欠点もあります。

github star 2.4k の問題と広報は非常に活発ですが、コミュニティは従来の質問を使用しており、タイムリーなコミュニケーションは比較的貧弱です
Linux では、現在 Ubuntu 14.04 バージョンのみがサポートされており、他のバージョンをコンパイルして渡すことは困難です。
LicodeにはSFUだけでなくMCUも含まれているため、コード構造が比較的重く、学習と習得に多くの時間がかかります。
Licode のパフォーマンスは平均的ですが、ストリーミングサーバーのパフォーマンスを最優先する場合、Licode は特に理想的な SFU ストリーミングサーバーではありません。
AndroidとiOS用のSDKは公式には見当たりませんでした、他の人は実装していますが、長い間更新されていません、AndroidとiOSを検討したい場合は、自分で頑張るかもしれません。

三、Janus-gateway

Janus は非常に有名な WebRTC ストリーミングメディアサーバーであり、Linux スタイルで記述され、C 言語で実装されたサービスプログラムであり、Linux/MacOS でのコンパイルとデプロイメントをサポートしていますが、Windows 環境はサポートしていません。

これはオープンソースプロジェクトであり、ソースコードのコンパイルとインストールは非常に簡単で、GitHub の指示に従うだけです。ソースコードとコンパイルマニュアルのアドレスは、 https://github.com/meetecho/janus-gatewayです。

Janus の展開も非常に簡単です。具体的な手順はドキュメントで詳しく説明されています。アドレスは次のとおりです。

https://janus.conf.meetecho.com/docs/deploy.html 。

上のアーキテクチャ図から、Janus はアプリケーション層とトランスポート層の 2 つの層に分かれていることがわかります。

プラグイン層はアプリケーション層とも呼ばれ、各アプリケーションはプラグインであり、ユーザーのニーズに応じてアプリケーションを動的にロードまたはアンインストールできます。プラグインアーキテクチャ方式は、柔軟性があり、拡張が容易で、耐障害性が高いため、非常に優れた設計方式であり、より複雑なビジネスを行う企業に特に適していますが、実装が複雑でコストがかかるという欠点があります。比較的高いです。

Janus でデフォルトでサポートされているプラグインには次のものがあります。

SIP: このプラグインは Janus を SIP ユーザーのプロキシにし、WebRTC エンドポイントを SIP サーバー (Asterisk など) に登録し、SIP サーバーとの間でオーディオおよびビデオストリームを送受信できるようにします。
TextRoom: このプラグインは、DataChannel を使用してテキストチャットルームアプリケーションを実装します。
ストリーミング: WebRTC エンドポイントで、事前に記録されたファイルや他のツールによって生成されたメディアを視聴したりできるようになります。
VideoRoom: ビデオ会議の SFU サービスを実装しており、実際にはオーディオ/ビデオルーターです。
VideoCall: 2 台の WebRTC 端末が相互に通信できるシンプルなビデオ通話アプリケーションです。WebRTC 公式 Web サイト ( https://apprtc.appspot.com ) の例に似ています。ビデオストリームが転送され、 WebRTC 公式 Web サイトの例では P2P 直接接続を使用しています。
RecordPlay: このプラグインには 2 つの機能があります。1 つは WebRTC に送信されたデータを記録することで、もう 1 つは WebRTC 経由でデータを再生することです。

トランスポート層には、メディアデータ伝送とシグナリング伝送が含まれます。メディアデータ送信層は、主にストリーミングメディアプロトコルと、DTLS プロトコル、ICE プロトコル、SDP プロトコル、RTP プロトコル、SRTP プロトコル、SCTP プロトコルなどの WebRTC の関連プロトコルを実装します。

シグナリングトランスポート層は、Janus のさまざまなシグナリングを処理するために使用され、サポートされるトランスポートプロトコルには、HTTP/HTTPS、WebSocket/WebSockets、NanoMsg、MQTT、PfUnix、RabbitMQ が含まれます。ただし、一部のプロトコルはコンパイルオプションによってインストールまたは制御できない場合があり、これらのプロトコルがすべてデフォルトでインストールされるわけではないことに注意してください。さらに、すべての Janus シグナリングの形式は Json 形式です。

Janus の全体的なアーキテクチャはプラグインソリューションを採用しており、これは非常に優れており、ユーザーはニーズに応じて独自のアプリケーションを簡単に作成できます。

そして現在、SIP、RTSP、オーディオおよびビデオファイルの再生、録音などのサポートなど、多くの機能をサポートしているため、他のシステムとの統合において大きな利点があります。

また、基盤となるコードは C 言語で書かれており、パフォーマンスも非常に優れています。Janus の開発および導入マニュアルも非常に充実しており、素晴らしいオープンソースプロジェクトです。

github star4.1k を使用しており、問題と PR を比較的迅速に処理します。

Android および iOS 用の公式 SDK が提供されます。

欠点:

構造が複雑すぎて初心者には不向き、企業が採用すると人件費や時間コストが比較的高くなる
Janus は、epoll のような非同期 I/O イベント処理メカニズムを使用しません。これは、Janus の大きな欠陥とも言えます。
Janus も glib ライブラリを使用しています。国内の開発学生の多くにとって glib ライブラリはあまり使用されていないため、ある程度の学習コストがかかります。

4.メドゥーズ

Medooze は、WebRTC プロトコルスタックだけでなく、RTP、RTMP などの他の多くのプロトコルもサポートする包括的なストリーミングメディアサーバーです。ソースアドレスは次のとおりです: https://github.com/medooze/media-server

大きな観点から見ると、Medooze は RTP/RTCP、SRTP/SRCP およびその他の関連プロトコルをサポートしているため、WebRTC 端末と相互接続できます。さらに、Medooze は RTP ストリーム、RTMP ストリームなどにもアクセスできるため、GStreamer/FFmpeg を使用してストリームを Medooze にプッシュすることができ、同じ部屋に入っている他の WebRTC 端末が GStreamer/FFmpeg Pushed によって送信されたストリームを見たり聞いたりすることができます。オーディオとビデオのストリームをアップします。さらに、Medooze は、上図の Recorder モジュールの役割である録音機能もサポートしています。これにより、室内のオーディオおよびビデオストリームを後で再生するために録音できます。

Medooze の制御ロジック層は、Node.js を通じて実装されます。Medooze は、Node.js を通じて完全な制御ロジック操作に関連する API を提供します。これらの API を通じて、Medooze の動作を簡単に制御できます。

Mediasoup と比較すると、Medooze はコア層で同様の機能を備えていますが、Medooze には録音、RTMP ストリームのプッシュ、FLV ファイルの再生などの関連操作を含むより強力な機能があり、一方 Mediasoup にはこれらの機能がありません。

Medooze にもいくつかの欠点があります。Medooze も C++ によって開発されたストリーミングメディアサーバーであり、非同期 IO イベント処理メカニズムを使用しますが、使用する非同期 IO イベント処理 API は、poll です。強力な非同期 IO イベント API である epoll と比較すると、非常に劣るため、オーディオおよびビデオパケットの送受信時のパフォーマンスは Mediasoup よりわずかに悪くなります。

5、ジッツィ

Javaで構築したサーバも最下層でc/c++を使用しており、Java言語を使用しているため、c/c++に比べてパフォーマンスは劣ります。

主なモジュールと実装言語:

Jitsi Video-Bridge (ソフトウェアビデオブリッジ実装言語 Java)
Jitsi Jicofo (jitsi カンファレンス実装言語 Java に必須のコンポーネント)
Prosody (XMPP サーバー実装言語 lua)
Nginx (Web サーバー)
Jitsi Meet (Web アプリケーション – エンドユーザーが対話するアプリケーション。実装言語は js)

アドバンテージ：

github star12.3k、発行とprの処理が速い
完全なドキュメント
公式の Android および iOS SDK が提供されており、React Native を使用して自分で SDK をコンパイルすることもできます。
公式の Web 側 SDK が提供され、デスクトップ側のパッケージングに Electron の使用が提供されます (最後は非常に完成しています)
コミュニティはコミュニケーションにフォーラムを使用しており、非常に活発です。
コミュニティは分散ソリューションを提供していますが、ドキュメントはまばらです。
保守チームは毎週月曜日にjitsiでビデオ会議を行ったり、開発者からの質問に答えたり、英語でコミュニケーションをとったりするのですが、国内時間は夜になるようです。
コミュニティのバージョン更新の反復が高速化される

六、Kurento

Kurento は、jitsi と同様に、長年にわたって維持され、時の試練を乗り越えてきました。違いは、C++ で開発されており、豊富なドキュメントとサンプルがあり、開発者にとって非常にフレンドリーであることです。

7. pion/webrtc

WebRTC API の Pure Go 実装 (github のスター 4.7k) は、現在少数の人々によって使用されています。実稼働環境で使用することはお勧めできません。学習して参照用に使用できます。支払うことをお勧めします。長い間注意してください。

要約:

SFU ストリーミングメディアサーバーの選択には最適なものはなく、最も適したものがあるだけです。オープンソース実装はそれぞれに特徴があり、実際の製品に適用することができますが、開発者には独自の技術的背景があり、自分の特性やプロジェクトの特性に応じて最適なものを選択する必要があります。次に、私がこれらのオープンソースプロジェクトをどのように判断し、選択しているかを紹介します。

チーム内のチームは、プロジェクト開発用の言語として必ず誰もが使い慣れている言語を選択するため、オープンソースプロジェクトを選択するときは、その言語で開発されたオープンソースプロジェクトを選択する必要があります。例えば、Ali部門では基本的にJava言語で開発を行っているため、オープンソースプロジェクトを選ぶ場合は基本的にJavaで開発されたオープンソースプロジェクトを選択することになりますが、オーディオやビデオストリーミングサービスの開発者はパフォーマンスを追求するためにC/C++を選択することが一般的です。 . 言語開発のためのオープンソースプロジェクト。チームの人員が十分でない場合は、ドキュメントが少なく、特に複雑なオープンソーステクノロジを選択しないようにしてください。

ビジネスに適したものにするためには、ビジネスのユーザーとユーザーグループの数を十分に考慮する必要があります。ビジネスの規模が大きく分散する必要がある場合は、まず、選択したオープンソーステクノロジが分散展開をサポートしているかどうかを理解する必要があります。そのように展開します。1 台のマシンでどの程度の同時実行がサポートされているか、サーバーを使用して実際に自分でテストするのが最善です。公式データは実際のテストデータとは多少異なります。プロジェクトの機能も考慮する必要があり、たとえばビジネスでは記録と再生が必要ですが、オープンソース技術にはそのような機能はありません。

二次開発 Licode は、分散クラスター展開をサポートする完全なシステムであるため、システムは比較的複雑で、学習サイクルは長くなります。実稼働環境に直接デプロイできますが、二次開発の柔軟性は十分ではありません。Janus-gateway は、豊富なシグナリングプロトコルをサポートし、プラグイン開発をサポートし、拡張が容易な独立したサービスであり、Linux/C のバックグラウンドを持つ開発者にとっては良い選択です。Medooze と Mediasoup は両方ともストリーミングサーバーライブラリであり、ストリーミングサーバーを製品に統合する必要がある開発者にとっては選択肢となるはずです。

時間コスト同社は、プロジェクトの時間計画とコストも考慮します。オープンソーステクノロジの使用には多かれ少なかれ落とし穴があり、その落とし穴が長期間続く可能性があるため、オープンソーステクノロジを使用する方が良いからです。完全なドキュメントと活発なコミュニティ。

どのオープンソーステクノロジーを選択する場合でも、初期段階で十分な調査を行い、実際に構築して使用してから決定する必要があります。選択した後、技術的負債を補うためには、次のことが必要です。オープンソーステクノロジのコードを深く理解する必要があります。そうしないと、借金を返済するときに非常に苦労することになります。

元のリンク:現在のオープンソース WebRTC プロジェクトテクノロジの選択

★記事末尾の名刺では、オーディオ・ビデオ開発学習教材（FFmpeg、webRTC、rtmp、hls、rtsp、ffplay、srs）やオーディオ・ビデオ学習ロードマップ等を無料で受け取ることができます。

以下を参照してください！