Wowza vs Red5 Pro
～Red5 Proが有利な5つのポイント～

Red5 ProはWowzaと比較してどうなのでしょうか？ 一言で言えば：より有利です。

もう少し説明すると、Red5 Proはより高速で、より多くのユーザーに対応し、ホスティングプロバイダーに制限されることなく、優れた技術サポートを提供します。

興味がわきましたか？もう少し詳しく説明しましょう。

低遅延

ライブストリーミングにおいては遅延が非常に重要なポイントになります。ライブストリーミングは文字通り「ライブ」。つまりリアルタイムであることを意味しています。

ライブ ストリーミング アプリケーションの多くは、何らかしらの双方向の対話機能を必要としています。たとえば何かの試合を見ている最中に、より速度の早いアプリケーションを使って視聴している誰かから先に試合結果を教えられてしまっては台無しでしょう。またオンラインオークションに参加している場合は、価格を入力したタイミングで入札できていないといけません。オークション主催者の早い進行に合わせて、落札におけるほんの数秒の違いが支払いに影響するのです。また、会話をする際でも、大幅な遅延が発生すると沈黙の時間が長くなり、会話がぎこちなくなり、理解しづらく感じます。

Red5 Pro は、遅延を最小限にしたライブ配信ができるによう設計されています。当社のWebRTCをベースとした製品では、遅延を500ミリ秒未満に抑えることを実現しました。これによって、配信者と視聴者がほぼリアルタイムに同じ映像を見ることができ、最高のユーザーエクスペリエンスが達成されています。

Wowza は WebRTCの技術をつかって配信できますが、予想される実際の低遅延の情報についてはあまり情報を公開していないようです。ただし、"超低遅延のストリーミング クラウド" プラットフォームでは、3 秒未満の低遅延を実現するといっています。しかしながら、遅延を秒単位で測定しているならばリアルタイムとは言い難いでしょう。

さらに、以下はWowza社のサイトより望ましくない引用です：

「Wowza ストリーミングクラウド超低遅延ターゲットにストリームを送信した場合、他のWowza Streaming Cloudターゲットに送信した場合よりレイテンシは短くなります。しかし他のストリーミングワークフローで達成できる3秒未満のレイテンシという基準には達しない可能性があります。」

つまり、WebRTC をパブリッシャーとして使用すると、既に長すぎる 3秒よりも長い遅延が発生する可能性があるといっています。

これだけでも問題ですが、次のセクションでWowza の WebRTC 統合に関するもう一つの大きな問題について説明します。

スケーリング（大規模配信）

Wowza の WebRTC ソリューションはスケーリングを実現できません。Wowzaの場合、WebRTC から、Apple HLS、Adobe HDS、MPEG-DASH など、高遅延のHTTP ストリーミング形式にトランスコードする必要があります。また、同様に高遅延のMSEやWebSocketのアプローチの利用を推奨しています。

スケーリングの「問題」の根源は、複数の接続が必要な場合に、WebRTCのピアツーピア接続では調整しない限り接続しづらいことです。WowzaはGoogle Chromeでは同時接続数を500まで制限しており、ツァイ・レヴェント-リーヴィ 氏が推奨している50以下の同時接続についても引用しています。技術的にはこれらの見解は正しいのですが、Red5 Proではアーキテクチャ全体を再考し再設計することで、これらの制限を打開しました。

Red5 Pro のオートスケーリングソリューションは、クラウド インフラストラクチャを活用して、数百万人に配信できるスケーラビリティを実現できます。Red5 Pro は、配信クライアント（ブロードキャスター）と受信クライアント（サブスクライバ）間をピアツーピアで接続するのではなく、サーバー インスタンス(ノード)を介してルーティングされるように設計されています。さらに、リレーサーバを使用することでChromeの同時接続500の制限を回避することができます。

Red5 ProのアプリケーションであるStream Managerの動作ロジックにてトラフィックやサーバーの使用状況は監視され、一つまたは複数のクラスタおよびノードグループがストリーミングが発生するリージョンに準備されます。

それぞれのノードは エッジ、オリジン、リレーのRed6 Pro サーバーインスタンスのいずれかとなります。大まかに言うと、オリジンサーバインスタンスがブロードキャスターを受け入れ、エッジサーバインスタンスはサブスクライバを受け入れ、リレーサーバがそれらを接続します。Stream Managerは、現在のトラフィックの状況に応じて、サーバーの追加または削除をリアルタイム処理します。リレーサーバは、追加の接続に対応するために、複数のオリジンまたはエッジ間にて作成されます。これにより、現在視聴している人に影響を与えることなく、より多くの視聴者がストリームに参加して同期することが出来ます。

特筆すべきは、このオートスケーリング ソリューションは500 ミリ秒未満の待機時間を維持しながら、数百万にもスケールアウトできることです。

前述のように、Wowza はスケーリングのために高遅延のHTTP プロトコルまたは MSE+WebSocket に依存していますが、これはWowzaがCDN ネットワークの上に構築されているためです。これが次のポイントです。

ホスティング環境に対し非依存

Red5 Pro はホスティングプラットフォームに依存しません。AWS、GCP、Azure、およびDigitalOceanにも自由に対応し、提供されたAPIを用いて高度にカスタマイズしたバックエンドを実現します。また、アーキテクチャ全体を変更することなく既存のアプリケーションをRed5 Proと統合させて、遅延を減らし、スケーラビリティを向上することができます。

一方、Wowzaではこのような高度な柔軟性は提供されていません。システムの上にアプリケーションを構築すると、基本的にはプラットフォームにバインドされます。つまり、トラフィックフローやデータ使用量などの処理方法に変更があった場合、価格とパフォーマンスが潜在的に変化することを制御できなくなります。

機能

上記で説明したように、Wowza のソリューションには大きな問題と制限があります。以下はその他の機能を比較しています。

	Wowza	RED5 PRO
データ チャネル	Web RTCではサポートされず、テキストチャットの作成方法もありません。	Red5 Pro では同様の機能を実行するために WebSocket を使用する共有オブジェクト機能を作成しました。
ストリーム品質/一貫性	サポートしていません。また、転送エラーの訂正、低帯域使用をサポートする再送信、RTPエラーの訂正についてもサポーしていません。	Red5 Pro は NACK を使用して重要なパケットを再送信し、スムーズなストリームを確保します。
オーディオのサポート	部分的にサポートされています。Google Chrome と Mozilla Firefox では音声はサポートされていません。	Red5 Proは、スケーリングや遅延に影響を与えることなく、AACとOpusの間で自動的に変換/トランスコードして返すソフトウェアを作成しました。
音質	サポートしていません。Wowzaではオーディオの品質は制御外であるブラウザの実装に依存すると主張しています。	サポートしています。
ABR サポート	サポートしていません。	サポートしています。
WEBRTC トランスコーディング	サポートしていません。Wowza では RTMP、RTSP、MPEG-TS ストリームを取得し WebRTC 経由で配信できません。	サポートしています。
Stun	サポートに制限があります。	STUN と TURNを完全にサポートしています。
VP8 および H.264 トランスコーディング	サポートしていません。	サポートしています。 自動トランスコーディングを提供しています。