低遅延のRTSP IPカメラからのWebRTCブラウザブロードキャスト

一部のレポートによると、今日、ビデオ監視用の数億台の IPカメラが世界中に設置されています。 ただし、ビデオ再生の遅延は、それらすべてにとって重大とはほど遠いものです。 原則として、ビデオ監視は「静的に」行われます-ストリームはストレージに記録され、動きを分析できます。 ビデオ監視用に多くのソフトウェアとハ​​ードウェアのソリューションが開発されており、それらの仕事はうまくいきます。

この記事では、 IPカメラのわずかに異なるアプリケーション、つまり、 低い通信遅延が必要なオンラインブロードキャストでのアプリケーションを検討します。

まず第一に、ウェブカメラとIPカメラに関する用語の誤解を排除しましょう。

Webカメラは、独自のプロセッサとネットワークインターフェイスを持たないビデオキャプチャデバイスです。 Webカメラには、コンピューター、スマートフォン、またはネットワークカードとプロセッサーを備えたその他のデバイスへの接続が必要です。


IPカメラは、キャプチャされたビデオを圧縮してネットワークに送信するための独自のネットワークカードとプロセッサを備えたスタンドアロンデバイスです。 したがって、IPカメラは、ネットワークに完全に接続し、別のデバイスへの接続を必要とせず、ネットワークに直接ブロードキャストできるスタンドアロンのミニコンピューターです。

低レイテンシは、IPカメラとオンラインブロードキャストではかなりまれな要件です。 たとえば、ビデオストリームのソースがこのストリームの視聴者と積極的にやり取りする場合、低レイテンシで作業する必要があります。


ほとんどの場合、ゲームのユースケースでは低レイテンシが必要です。 例には、リアルタイムビデオオークション、ライブカジノビデオディーラー、ホストとのインタラクティブなオンラインテレビ番組、クアドロコプターのリモートコントロールなどがあります。


職場でのライブオンラインカジノのディーラー。

通常、通常のRTSP IPカメラはH.264コーデックでビデオを圧縮し、 インターリーブと非 インターリーブの 2つのデータ転送モードで動作できます。

インターリーブモードは最も人気があり便利です。 このモードでは、ビデオデータはカメラへのネットワーク接続内でTCPを介して送信されます。 IPカメラからインターリーブに配信するには、カメラの1つのRTSPポート（たとえば554）を外部に開いて転送するだけです。 プレーヤーは、TCPを介してカメラに接続し、この接続内で既にストリームを取得するだけです。


カメラの2番目の動作モードは、 インターリーブされていません 。 この場合、 RTSP / TCPプロトコルを使用して接続が確立され、作成されたTCPチャネル外のRTP / UDPプロトコルを使用して、トラフィックが個別に送信されます。


非インターリーブモードは、 RTP / UDPプロトコルを使用するため、ビデオを最小限の遅延でブロードキャストするのに適していますが、同時にプレーヤーがNATの背後にある場合は問題が多くなります 。


NATの背後にあるプレーヤーのIPカメラに接続する場合、プレーヤーは、オーディオとビデオのトラフィックを受信するために使用できる外部IPアドレスとポートを知っている必要があります。 これらのポートは、テキストSDP-configで指定され、RTSP接続の確立時にカメラに送信されます。 NATが正しく開かれ、正しいIPアドレスとポートが決定されていれば、すべてが機能します。

したがって、最小限の遅延でカメラからビデオを取得するには、 非インターリーブモードを使用し、UDP経由でビデオトラフィックを受信する必要があります。

ブラウザは、RTSP / UDPプロトコルスタックを直接サポートしていませんが、組み込みWebRTCテクノロジーのプロトコルスタックをサポートしています。


ブラウザとカメラの技術は非常に似ており、特にSRTPは暗号化されたRTPです。 しかし、ブラウザに正しく配信するには、IPカメラがWebRTCスタックの部分的なサポートを必要とします。

この非互換性を排除するには、IPカメラプロトコルとブラウザープロトコル間のブリッジになる中間リレーサーバーが必要です。


サーバーは、 RTP / UDPを介してIPカメラからのストリームを自身に取り込み、WebRTCを介して接続されたブラウザーに提供します。

WebRTCテクノロジーはUDP上で動作するため、 Server> Browserの方向に低遅延を提供します 。 IPカメラはRTP / UDPプロトコルも使用し、 Camera> Serverの方向に低遅延を提供します 。

カメラは、限られたリソースと帯域幅のために、限られた数のストリームを提供できます。 中間サーバーを使用すると、IPカメラから多数の視聴者に向けてブロードキャストを拡大できます。

一方、サーバーを使用する場合、2つの通信レッグがオンになります。
1）視聴者とサーバー間
2）サーバーとカメラ間
このようなトポロジには、多くの「機能」または「落とし穴」があります。 以下にリストします。

落とし穴＃1-コーデック

低レイテンシでの作業の障害およびシステム全体のパフォーマンスの低下の理由は、コーデックを使用している可能性があります。

たとえば、カメラがH.264で720pのビデオストリームを提供し、VP8のみをサポートするAndroidスマートフォンにChromeブラウザーが接続されている場合。


トランスコーディングが有効になっている場合、接続されているIPカメラごとにトランスコーディングセッションを作成する必要があります。これにより、 H.264がデコードされ、 VP8でエンコードされます。 この場合、16コアのデュアルプロセッササーバーは、物理コアあたり1台のカメラのおおよその計算から、10〜15台のIPカメラのみを提供できます。

したがって、サーバーの容量が計画された数のカメラのトランスコードを許可しない場合は、トランスコードを避ける必要があります。 たとえば、H.264をサポートするブラウザのみを提供します。また、H.264コーデックのサポートがあるiOSまたはAndroid向けのネイティブモバイルアプリケーションの使用を推奨するブラウザもあります。


モバイルブラウザでトランスコーディングをバイパスするオプションとして、 HLSを使用できます 。 ただし、HTTPを介したストリーミングは低遅延ではなく、現時点ではインタラクティブなブロードキャストには使用できません。

落とし穴＃2-カメラのビットレートと損失

UDPプロトコルは、遅延に対処するのに役立ちますが、ビデオパケットの損失を許可します。 したがって、カメラとサーバー間のネットワークで大きな損失が発生する低遅延にもかかわらず、画像が破損する可能性があります。


損失を除外するには、カメラで生成されたビデオストリームのビットレートがカメラとサーバー間の専用帯域に収まることを確認する必要があります。

落とし穴＃3-観客のビットレートと損失

サーバーに接続されている各ブロードキャストビューアーには、特定のダウンロード帯域幅もあります。

IPカメラが視聴者のチャンネルの能力を超えるストリームを送信した場合（たとえば、カメラは1 Mbpsを送信し、視聴者は500 Kbpsのみを受信できます）、このチャンネルで大きな損失が発生し、その結果、ビデオまたは強いアーティファクトがフリーズします。


この場合、3つのオプションがあります。

1. 各視聴者のビデオストリームを必要なビットレートに個別にトランスコードします。
2. 接続された各ストリームではなく、視聴者グループのグループのストリームをトランスコードします。
3. 事前にいくつかの解像度とビットレートでカメラからストリームを準備します。

各ビューアのトランスコーディングの最初のオプションは、すでに10〜15個のビューアでCPUリソースを消費するため、適合しません。 ただし、このオプションは最大のCPU使用率で最大の柔軟性を提供することに注意してください。 つまり これは理想的です。たとえば、地理的に分散した10人だけをストリーミングする場合、それぞれが動的なビットレートを受け取り、それぞれに最小限の遅延が必要です。


2番目のオプションは、トランスコーディンググループを使用してサーバーのCPUの負荷を減らすことです。 サーバーは、ビットレートごとに複数のグループを作成します。たとえば、次の2つです。

• 200 Kbps
• 1 Mbps

視聴者が十分な帯域幅を持っていない場合、視聴者はビデオストリームを快適に受信できるグループに切り替えます。 したがって、トランスコーディングセッションの数は、最初の場合のように視聴者の数と同じではありませんが、 2つのトランスコーディンググループがある場合、2などの固定数です。


3番目のオプションには、サーバー側でのトランスコーディングの完全な拒否と、さまざまな解像度とビットレートで既に準備されたビデオストリームの使用が含まれます。 この場合、カメラは解像度とビットレートが異なる2つまたは3つのストリームを返すように構成され、視聴者は帯域幅に応じてこれらのストリームを切り替えます。

この場合、サーバーのトランスコーディングの負荷はなくなり、カメラ自体にシフトされます。 カメラは1つではなく2つ以上のストリームをエンコードするようになりました。


その結果、視聴者の帯域幅を調整するための3つのオプションを検討しました。 1つのトランスコーディングセッションが1サーバーコアを使用すると仮定すると、次のCPU負荷テーブルが取得されます。

	調整方法	サーバー上のコアの数
1	各視聴者のビデオストリームを必要なビットレートにトランスコードします	N-視聴者の数
2	ビデオストリームをグループごとにユーザーにトランスコードする	G-視聴者のグループの数
3	いくつかの解像度とビットレートで事前にカメラからストリームを準備します	0

この表は、カメラのトランスコーディングの負荷をシフトしたり、サーバーにトランスコーディングを与えたりできることを示しています。 オプション2と3は同時に最適に見えます。

WebRTCとしてのRTSPのテスト

何が起こっているのかを正確に把握するために、いくつかのテストを実施する時が来ました。 実際のIPカメラを使用してテストを実施し、ブロードキャスト遅延を測定します。

テストのために、 RTSPおよびH.264およびG.711コーデックをサポートする古代のDリンクDCS-2103 IPカメラを使用してみましょう。


カメラは他の便利なデバイスやワイヤを使用してクローゼット内に長時間置かれていたため、カメラの背面にあるボタンを10秒間押し続けてリセットする必要がありました。

ネットワークに接続した後、カメラで緑色のライトが点灯し、ルーターはローカルネットワーク上のIPアドレス192.168.1.37の別のデバイスを見ました。

カメラのWebインターフェースに入り、テスト用のコーデックと解像度を設定します。


次に、ネットワーク設定に移動して、カメラのRTSPアドレスを見つけます。 この場合、RTSPアドレスはlive1.sdpです 。つまり、 カメラはrtspで入手できます：//192.168.1.37/live1.sdp


カメラの可用性は、 VLCプレーヤーを使用して簡単に確認できます。 メディア-オープンネットワークストリーム。



カメラが動作し、RTSPでビデオを提供できると確信しました。

テスト用のサーバーとしてWeb Call Server 5を使用します。 これは、 RTSPおよびWebRTCプロトコルをサポートするストリーミングサーバーです。 RTSPを介してIPカメラに接続し、ビデオストリームを取得します。 次に、 WebRTCを介してストリームを配信します。

ホストにWeb Call Serverをインストールするか、 既製のAmazon EC2インスタンスを実行できます 。

インストール後、サーバーを上記で説明したRTSP 非インターリーブモードに切り替える必要があります。 これは、設定を追加することで実行できます。

rtsp_interleaved_mode=false 

この設定はflashphoner.properties構成に追加され、サーバーの再起動が必要です。

 service webcallserver restart 

したがって、非インターリーブ方式に従って動作し、UDPを介してIPカメラからパケットを受信し、WebRTC（UDP）を介して配信するサーバーがあります。


テストサーバーは、フランクフルトのデータセンターにあるVPSサーバー上にあり、2つのコアと2ギガバイトのRAMを備えています。

カメラは192.168.1.37のローカルネットワークにあります。

したがって、最初にすべきことは、サーバーがIPカメラへの接続を確立できるように、着信TCP / RTSP接続用にポート554をアドレス192.168.1.37に転送することです。 これを行うには、ルーターの設定に1つのルールのみを追加します。


ルールは、ポート554に着信するすべてのトラフィックをIPアドレスである37にリダイレクトするようにルーターに指示します。

その後、外部IPアドレスを確認します。 whatismyipをグーグル検索することで、5〜15秒でこれを実行できます。

フレンドリーNATがあり、外部IPアドレスがわかっている場合は、サーバーでテストを開始できます。

Google Chromeの標準デモプレーヤーは次のようになります。


RTSPストリームの再生を開始するには、 Streamフィールドにアドレスを入力するだけです。
この場合、ストリームアドレスは次のとおりです。rtsp：//ip-cam/live1.sdp
ここで、 ip-camはカメラの外部IPアドレスです。 サーバーは、このアドレスで接続を確立しようとします。

VLCレイテンシテストとWebRTC

IPカメラを構成し、 VLCでテストし、サーバーを構成し、 WebRTC配信を使用してサーバーを介したRTSPストリームをテストした後、最終的に遅延を比較できます。

これを行うには、モニター画面に一瞬を表示するタイマーを使用します。 タイマーをオンにして、 VLCでビデオストリームをローカルで 、およびリモートサーバーを介してFirefoxブラウザーで同時に再生します。

サーバーへのping 100 ms 。
ローカルで1ミリ秒の Ping。


タイマーを使用した最初のテストは次のようになります。


黒い背景には元のタイマーがあり、遅延はゼロです。 左側はVLC 、右側はFirefoxで、リモートサーバーからWebRTCストリームを受信します。

	ゼロ	VLC	Firefox、WCS
時間	50.559	49.791	50.238
レイテンシーms	0	768	321

このテストでは、 VLCのビデオがローカルネットワークで再生され、Firefoxで表示されるビデオがドイツのデータセンターのサーバーを通過して返されるにもかかわらず、 VLCの遅延がFirefox + Web Call Serverの遅延の2倍であることがわかります戻る。 この不一致は、VLCがTCP（インターリーブモード）で動作し、ビデオをスムーズに再生するための追加のバッファーが含まれているために発生する可能性があります。

遅延値をキャプチャするためにいくつかのショットを取りました。



測定結果は次のようになります。

	メートル法	ゼロ	VLC	Firefox、WCS
Test1	時間	50.559	49.791	50.238
	待ち時間	0	768	321
Test2	時間	50.331	49.565	49.951
	待ち時間	0	766	380
Test3	時間	23.870	23.101	23.548
	待ち時間	0	769	322
平均			768	341

したがって、 ローカルネットワークでVLCを使用してテストした場合の平均遅延は768ミリ秒でした。 ビデオをリモートサーバーに渡す際の平均遅延は341ミリ秒でしたが、 UDPとWebRTCを使用した場合、 2倍低くなりました。

RTMPレイテンシテストとWebRTC

Wowzaサーバーを介してRTMPプレーヤーで同様のテストを実行し、 Web Call Serverを介してWebRTCプレーヤーで同時にテストを実行します 。

左側では、RTMP接続でWowzaからビデオストリームを取得します。 右側では、WebRTCを介してストリームを取得します。 上記は絶対時間（遅延ゼロ）です。

テスト-1


テスト-2


テスト-3


テスト-4


テスト結果は、すでにおなじみの表に表示できます。

	メートル法	ゼロ	RTMP	WebRTC
Test1	時間	37.277	35.288	36.836
	待ち時間	0	1989	441
Test2	時間	02.623	00.382	02.238
	待ち時間	0	2241	385
Test3	時間	29.119	27.966	28.796
	待ち時間	0	1153	323
Test4	時間	50.051	48.702	49.664
	待ち時間		1349	387
平均			1683	384

したがって、RTMPを介してFlash Playerで RTSPストリームを再生する際の平均遅延は1683ミリ秒でした。 WebRTCの平均遅延は384ミリ秒です。 つまり WebRTCのレイテンシは平均で4倍向上しました。

参照資料

WebRTCテクノロジー
RTSP -RFC
RTSPインターリーブ -RFC 10.12 Embedded（Interleaved）Binary Data
RTMP仕様
Web Call Server -RTSPをサポートするWebRTCメディアサーバー
VLC -RTSPを再生するためのプレーヤー