WebRTC とビデオ監視: カメラからのビデオ遅延をどのように克服したか

クラウド ビデオ監視システムに取り組み始めた最初の日から、私たちは Ivideon を諦めるような解決策のない問題に直面していました。これは私たちのエベレストであり、多くのエネルギーを必要とした登山でしたが、今ではついに解決できました。クロスプラットフォームパズルの上部にピッケルを突き刺しました。

インターネット経由でオーディオとビデオを送信するシステムは、機器、Web クライアント、およびそれらがサポートする標準に依存すべきではなく、ネットワーク アドレス変換プログラムやファイアウォールの存在下でも正しく動作する必要があります。クラウド ビデオ監視のユーザーは、たとえアナログ カメラを使用していてもサービスにアクセスしたいと考えており、最新のデバイスでライブ ビデオ ブロードキャストを視聴することを好みます。

ユーザーが遅延を最小限に抑えてビデオを視聴したいと考えることは非常に重要です。ブラウザーで低遅延でビデオを表示するほぼ唯一の方法は、WebRTC (Web リアルタイム通信) を使用することです。 WebRTC は、ブラウザーでビデオとオーディオをピアツーピアで送信するための一連のテクノロジーであり、当初はビデオ ストリームを低遅延で送信および再生するために設計されました。この目的のために、とりわけ UDP プロトコルが使用されます。

新しいエンジンがユーザーに何を提供するかを説明する前に、当社が HLS テクノロジーをサポートする理由とその理由、および次の移行を決定した理由を思い出してください。

HLS エンジン: 長所と短所

(c)

HLS（HTTP Live Streaming）技術はAppleによって開発されたため、Appleデバイスで最初にサポートされたのは当然のことです。現在では、HLSビデオはほぼすべてのセットトップボックスや、Apple OSを搭載した多くのデバイスでサポートされています。 Android.

HLS エンジンは、よく知られている H264 ビデオ コーデックを AAC または MP3 オーディオ ストリームと組み合わせて使用​​し、ビデオ データをストリーミングします。オーディオおよびビデオ データ ストリーム全体が MPEG-TS トランスポート コンテナにパッケージ化されます。 HTTP プロトコル経由で送信する場合、ストリームに含まれる情報は m3u8 プレイリストに記述されたフラグメントに分割されます。そして、これらのフラグメントがプレイリストとともに HTTP 経由で送信されるようになります。チャンク化は自動的に秒単位の遅延を意味します。これは MPEG-TS コンテナの機能です。

HLS エンジンは、マルチビットレート ストリーム、ライブ/VOD もサポートします。

HLS の主な利点:

• すべての主要なブラウザにサポートが組み込まれています。
• 実装の容易さ (WebRTC と比較して)。
• セグメントを一度 CDN にアップロードできるため、多数の視聴者向けにあらゆる種類のブロードキャストを編成するのに非常に便利で効率的です。

エンジンはシンプルですが、すべてが思ったほどスムーズに進むわけではありません。主な問題は、サードパーティのプレーヤー開発者が、サポートされているオーディオ形式などに関して Apple の推奨事項から遠ざかっていることです。特に、多くの開発者は、mpeg2 ビデオ、mpeg2 オーディオなどの一般的なオーディオ ストリームを操作する機能を追加し始めました。その結果、プレーヤーごとに異なるプレイリスト形式を作成する必要がありました。

しかし、HLS エンジンの最大の問題の 1 つは、データ転送の待ち時間が長いことです。

「ブレーキ」の起源

HLS の待ち時間が長い主な理由は、プログラマーが最高品質の画像を取得するためにエンジンを作成したという事実にあります。したがって、使用されるフレーム間隔と再生バッファのサイズのパラメータは、ライブ ビデオ ブロードキャストにはまったく適していません。このため、ビデオ映像の送信にはかなりの遅延が発生し、5 ～ 7 秒かかる場合があります。

一方で、これは、たとえばビデオ ホスティング サーバーから映画を視聴する人にとっては大したことではありません。しかし、ビデオ監視システムの場合、ビデオ映像の送信遅延が非常に重要になる可能性があります。

従業員が 5 時間に XNUMX 回モニターから顔を上げているオフィスを監視している場合、XNUMX 秒の遅延はまったく問題になりません。しかし、人々は、たとえば、サッカーの試合を放送するときに、すでにチャットに GOOOOL と書いているのに、これはまだビデオには含まれていないと不満を言い始めました:)。 Ivideon が事実上 Skype に置き換わるべきというユーザー ケースがすでに多数あります。

HLS でレイテンシを克服することは可能ですか?この質問に対する答えは、「ネズミを駆除することはできませんが、その数を適切な最小限まで減らすことはできます。」という、経験豊富なネズミ駆除業者が初心者の害虫駆除専門家に講義する際のスピーチのように聞こえます。 HLS の遅延と同様に、遅延をゼロにすることはできませんが、遅延を大幅に削減できるソリューションが市販されています。

細かいカット

このエンジンのもう 1 つの欠点は、データ転送に小さなファイルが使用されることです。これの何が問題なのでしょうか？

多数の小さなファイルをある媒体から別の媒体にコピーしようとしたことのある人は、おそらく、そのようなセットの書き込み速度が、同じサイズの 10 つの大きなファイルよりもはるかに遅いことに気づいたでしょう。また、ハード ドライブへのアクセスの強度が大幅に増加し、一般にコンピューター全体のパフォーマンスに悪影響を及ぼします。したがって、ビデオ データを XNUMX 秒の小さなチャンクで送信することも、エンジンの遅延の増加につながります。

HLS テクノロジーの長所と短所をすべて簡単にまとめてみましょう。

HLS の利点:

1. あらゆるデバイスで動作する機能。スマートフォン、タブレット、ラップトップ、デスクトップ PC など、最新のデバイスでビデオを視聴できます。主なことは、Web ブラウザーが最新であり、HTML5 およびメディア ソース拡張機能と互換性があることです。
2. 優れた画質。使用される適応型データ送信機能により、インターネット接続の帯域幅に応じて、送信されるビデオの品質を動的に変更できますが、アルゴリズムは最高の品質を維持するように努めます。
3. ユーザーの機器に複雑な設定を行う必要はありません。

短所：

1. 一部のデバイスでのエンジンの操作に対するサポートは限定的です。
2. 画像送信の遅延が大きい。
3. 小さなファイルを使用するため、最適化のオーバーヘッドと複雑さが大幅に増加します。コンテナーの性質上、セグメント サイズよりも低いレイテンシを取得することはできません。

私たちにとって HLS の欠点がその利点を上回ったため、代替オプションを探す必要がありました。

WebRTCとは

(c)

WebRTC プラットフォームは、最小限の遅延でブラウザとモバイル アプリケーション間でストリーミング ビデオおよびオーディオ データを送信するために、2011 年に Google によって開発されました。このために、標準の UDP プロトコルと特別なフロー制御アルゴリズムが使用されます。現在、これはオープンソース プロジェクトであり、Google によって積極的に保守され、開発されています。

WebRTC は、ピアツーピアのビデオおよびオーディオ送信のための一連のテクノロジーです。つまり、たとえば、WebRTC を使用するユーザー ブラウザは、データの保存や処理にリモート サーバーを使用せずに、相互にデータを直接転送できます。すべての情報は、エンド ユーザーのブラウザやモバイル アプリケーションによっても処理されます。

この技術の利便性と幅広い機能は、すべての人気ブラウザの開発者から高く評価されています。WebRTC は現在、Mozilla Firefox、Opera、Google Chrome（およびすべての Chromium ベースのブラウザ）に加え、モバイル アプリでもサポートされています。 Android そしてiOS。

WebRTC には疑いのない利点がある一方で、いくつかの重大な欠点があります。

選択の難しさ

WebRTC テクノロジーは P2P に関するものであるため、ネットワーク インタラクションの点でははるかに複雑です。デバッグやテストが難しく、予期しない動作をする可能性があります。同時に、NAT とファイアウォールを克服する必要があり、UDP がブロックされているネットワークでの動作を保証する必要があります。

Google の WebRTC 実装は非常に使いにくいです。企業全体が SDK アセンブリ サービスを提供しているところもあります。さらに、Google の実装は、ビデオ全体を再エンコードせずにシステムに統合するのが非常に困難でした。

しかし、私たちは長い間、ユーザーに本格的な「ライブ」ビデオを操作して、画面上の画像とイベント自体の間の遅延を最小限に抑える機会を提供したいと考えていました。さらに、遅延が重要な PTZ カメラをより快適に使用したいという願望もありました。

他のアンチラグ実装はまだ機能が限られており、動作が著しく悪いことを考慮して、WebRTC を使用することにしました。

私たちが何をしてしまったのか

WebRTC プラットフォームを適切に実装することは簡単な作業ではありません。計算ミスや不正確さがあると、ビデオ送信の遅延が他のプラットフォームと比べて減少しないだけでなく、増加する可能性さえあります。

WebRTC が正しく動作するには、まず、Web ビデオを処理するためのスタックの技術アップグレードを実行する必要があります。それが私たちがやったことです。

まず、WebSocket 上に WebRTC シグナリング プロトコル サーバーを実装し、webrtc.org SDK に基づいてクラウドに WebRTC ピア サーバーを展開しました。そのタスクは、ビデオ トランスコーディングを行わずに、ビデオ ストリームを H.264 + Opus/G.711 形式でクライアント WebRTC ピアに配信することです。

シグナリング プロトコルとして Websocket を選択したのは、Websocket がすでにすべての一般的な Web ブラウザーで高品質のサポートを備えているためです。このため、開発オーバーヘッドを大幅に削減できるだけでなく、AJAX と比較して、TCP および TLS ハンドシェイクの繰り返しによる時間とリソースの無駄も回避できます。

実際のところ、デフォルトでは、WebRTC は、ソース アプリケーションとクライアント アプリケーション間のリアルタイム ビデオ通信を適切に構成、維持、終了するために必要なシグナリング プロトコルを提供していません。

また、シグナリング テクノロジを独自に実装するには、いくつかの Web プロトコル (Websocet、WebRTC) をサポートする独自のシグナリング サーバーを開発する必要がありました。また、セッションや通知、ビデオ管理などをリアルタイムで安全に管理する機能も備えています。

P2P ではなく、UDP とフロー制御によって遅延を削減することで、P2P の制限を克服しました。主な使用例はブラウザを介した p2p 会話であるため、これは WebRTC にも組み込まれています。

モバイル クライアントでは、webrtc.org SDK を使用してプレーヤーを実装しました。これは、フロー制御を正しく実装し、既知の前方誤り訂正 (FEC) スキームをすべて備え、すべてのブラウザーにパケットを再送信するメカニズムを正しく実装しているだけであるためです。 webrtc.org SDK が Google によって積極的に開発されていることも重要です。

WebRTC を導入するとどうなるでしょうか?

カメラからのライブビデオを表示するために、WebRTC に基づいて最適化された新しいプレーヤーを個人アカウントに追加しました。ビデオの読み込み速度が速くなり、視聴時間の増加に伴う遅延の問題が完全に解消されます。

Ivideon クラウド サービスに WebRTC サポートを導入した後、クライアントは本格的なライブ ビデオを視聴できるようになったと完全な自信を持って言えます。ビデオ シーケンスをブロードキャストする際の遅延が 5 秒を超えなくなりました。比較のために、以前の HLS エンジンでは 7 ～ XNUMX 秒の遅延でビデオ配信が行われました。ビデオ デモンストレーション速度の違いは非常に大きく、ユーザーはビデオ サービスの使用を開始するとすぐにそのことに気づくでしょう。

予想通り、新しいプレーヤーの実装により、PTZ とカメラとの音声通信の応答性が向上しました。

注意していただきたい微妙な点が 1 つだけあります。新しい WebRTC プレーヤーは現在テスト モードで動作しています。そのため、デフォルトではすべてのクライアントに対してこの機能が有効になっていません。ただし、カメラ設定で対応する項目を有効にすることで、自分で有効にすることができます (これを行うには、次のリンクに移動します) 専用事務室).

Ivideon サービスにおける WebRTC 実装の特徴

WebRTC は現時点ではまだ実験的なテクノロジーです。そのサポートはまだすべてのブラウザとユーザー デバイスに正しく実装されておらず、またすべてのカメラにも正しく実装されているわけではありません。

これがまさに、WebRTC プレーヤーをまだすべてのユーザーのデフォルトにしていない理由です。

現時点では、Google Chrome ブラウザーでのみ WebRTC を使用することをお勧めします。 Firefox と Safari の最新バージョンもこのテクノロジーをサポートしていますが、残念ながらまだ不安定です。

モバイル デバイス上のブラウザーに対する WebRTC サポートはまだ実装されていません。現在、モバイル デバイスからログインして WebRTC をアクティブ化する場合、このモードは機能しません。ただし、WebRTC はモバイル アプリケーションで利用できます。 Android и iOS.

私たちのサービスにおける WebRTC 実装の機能に関する話を締めくくるにあたり、さらに 2 つの微妙な点に注目してみましょう。

まず、このテクノロジーはリアルタイムでライブビデオをブロードキャストすることに焦点を当てています。したがって、チャネルにビデオを送信するのに十分な帯域幅がない場合、フレーム ドロップが発生します (HLS を使用すると、ビデオのフェージングと遅延の増加に気づきますが、フレーム ドロップは発生しません)。ただし、ビデオは実際にはブロードキャストされます。時間。

第 2 に、このテクノロジーは特にライブ ビデオをリアルタイムで処理するように設計されているため、アーカイブされたビデオ データを処理するためには使用しません。

その他のサービス変更点

現時点では、Flash は自動エンジン選択メカニズムには関与していません。このようなプレーヤーは引き続き使用できますが、これを行うには、アカウントまたはカメラの設定で手動で選択する必要があります。これはファッションへの賛辞ではなく、私たちのサービスの統計によれば、Flash を使用するユーザーは事実上存在していないというだけです。そして、ユーザーのブラウザがそれをサポートしているかどうかを判断しようとすると、約 2 秒の貴重な時間が失われます。

ここでは、クラウドビデオ監視システムと個人アカウントであなたを待っている変更の概要を簡単に説明します。ぜひニュースをフォローしてください！

出所： habr.com