家 › インターネット › rtsp 経由で IP カメラを表示します。 WebRTC を使用して IP カメラからビデオストリームをブロードキャストします。 RTSP プロトコルが必要な理由は何ですか?

rtsp 経由で IP カメラを表示します。 WebRTC を使用して IP カメラからビデオストリームをブロードキャストします。 RTSP プロトコルが必要な理由は何ですか?

いくつかの報告によると、今日では、 何億ものビデオ監視用の IP カメラ。ただし、ビデオ再生の遅延はすべてのビデオにとって重大な問題ではありません。ビデオ監視は通常、「静的に」行われます。ストリームはストレージに記録され、動きを分析できます。ビデオ監視用に開発された、適切に機能するソフトウェアおよびハードウェアソリューションが数多くあります。

この記事では、少し異なるアプリケーションについて説明します。 IPカメラ、つまり、必要な場合のオンラインブロードキャストでのアプリケーション 通信遅延が低い。

まず最初に、Web カメラと IP カメラに関する用語の誤解を解いておきましょう。

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

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

低遅延(低遅延) は、IP カメラやオンラインブロードキャストにとってはかなりまれな要件です。たとえば、ビデオストリームのソースがこのストリームの視聴者と積極的に対話する場合、低遅延で動作する必要性が生じます。

ほとんどの場合、ゲームの使用例では低遅延が必要とされます。このような例には、リアルタイムビデオオークション、ライブディーラーがいるビデオカジノ、ホストがいるインタラクティブなオンラインテレビ番組、クアッドコプターのリモコンなどが含まれます。

仕事中のライブオンラインカジノディーラー。

通常の RTSP IP カメラはビデオをストリーミングします。 H.264コーデックに対応しており、次の 2 つのデータトランスポートモードで動作できます。 インターリーブされたそして 非インターリーブ.

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

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

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

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

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

ブラウザは RTSP/UDP プロトコルスタックを直接サポートしませんが、ネイティブテクノロジプロトコルスタックをサポートします。 WebRTC.

ブラウザとカメラのテクノロジーは特によく似ています。 SRTPそれは暗号化されています RTP。ただし、ブラウザに正しく配信するには、IP カメラが WebRTC スタックを部分的にサポートする必要があります。

この非互換性を解消するには、IP カメラプロトコルとブラウザプロトコルの間のブリッジとして機能する中間中継サーバーが必要です。

サーバーは、次を介して IP カメラからのストリームを引き継ぎます。 RTP/UDPそして、それを WebRTC 経由で接続されているブラウザに送信します。

WebRTC テクノロジーはプロトコルに従って動作します UDPしたがって、方向の遅延が少なくなります。 サーバー > ブラウザ。 IP カメラは、次のプロトコルを使用して動作することもできます。 RTP/UDP方向の遅延が少ない カメラ > サーバー.

リソースと帯域幅が限られているため、カメラが出力できるストリームの数は限られています。中間サーバーを使用すると、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 のネイティブモバイルアプリケーションの使用を提供します。

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

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

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

損失をなくすためには、カメラによって生成されたビデオストリームのビットレートがカメラとサーバー間の専用帯域幅に適合することを確認する必要があります。

落とし穴 #3 - 視聴者のビットレートと損失

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

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

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

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

最初のオプショントランスコーディングを使用した場合は、10 ～ 15 台のビューアが接続されている場合でも CPU リソースを消費するため、各ビューアには適していません。ただし、このオプションは最大の CPU 負荷で最大の柔軟性を提供することに注意してください。それらの。これは理想的なオプションです。たとえば、地理的に分散した 10 人のみにストリームをブロードキャストする場合、各人は動的ビットレートを受信し、各人が必要とする遅延は最小限に抑えられます。

2 番目のオプショントランスコーディンググループを使用してサーバー CPU の負荷を軽減することです。サーバーはビットレートごとにいくつかのグループを作成します (例: 2 つ)。

200Kbps
1Mbps

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

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

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

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

この表は、トランスコーディングの負荷をカメラに移すか、トランスコーディングをサーバーに転送できることを示しています。オプション 2 と 3 が最も最適であると思われます。

RTSP を WebRTC としてテストする

何が起こっているかの本当の姿を特定するために、いくつかのテストを実施する時期が来ています。実際の IP カメラを使用して、ブロードキャスト遅延を測定するテストを実施してみましょう。

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

カメラは他の便利な機器やワイヤーと一緒にクローゼットの中に長い間眠っていたので、送付する必要がありました。 リセットカメラの背面にあるボタンを 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プロトコル。 IP カメラに接続します。 RTSPそしてビデオストリームを選択します。次にストリームを配信します WebRTC.

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

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

サービス webcallserver の再起動
したがって、ノンインターリーブ方式に従って動作し、IP カメラから UDP 経由でパケットを受信し、WebRTC (UDP) 経由でパケットを配信するサーバーがあります。

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

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

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

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

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

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

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

VLC と WebRTC の遅延テスト

IP カメラを設定してテストした後、 VLC、サーバーを構成してテストしました RTSPによる配布によりサーバーを介して流れます WebRTC, 最後にレイテンシを比較できます。

これを行うには、モニター画面に秒の端数を表示するタイマーを使用します。タイマーをオンにしてビデオストリームを同時に再生します ローカルでの VLC Firefox ブラウザではリモートサーバー経由でアクセスできます。

サーバーへの ping 100ミリ秒.
ローカルで ping を実行する 1ミリ秒.

タイマーを使用した最初のテストは次のようになります。
黒い背景にはオリジナルのタイマーがあり、遅延がゼロであることを示しています。左 VLC、右側 Firefox、受信 WebRTCリモートサーバーからのストリーム。

	ゼロ	VLC	Firefox、WCS
時間	50.559	49.791	50.238
レイテンシミリ秒	0	768	321

このテストでは、次の遅延が見られます。 VLC遅延の2倍 Firefox + Web コールサーバー VLC のビデオはローカルネットワークで再生され、Firefox で表示されるビデオはドイツのデータセンターのサーバーを経由して戻ってくるにもかかわらず、です。この不一致は、VLC が TCP (インターリーブモード) 上で動作し、スムーズなビデオ再生のための追加のバッファが含まれているという事実によって引き起こされる可能性があります。

レイテンシー値を記録するために写真を何枚か撮りました。

「互換性リストにない IP カメラを NVR に接続するにはどうすればよいですか?」という質問がよくあります。

選択肢は 2 つあります ONVIF と RTSP

ONVIF プロトコル (Open Network Video Interface Forum) から始めましょう

ONVIF は、すべてのデバイスが異なるメーカーの場合に備えて、IP カメラ、NVR、ソフトウェアを共同操作するための一般に受け入れられたプロトコルです。 ONVIF は、人々の国際コミュニケーションにおける英語にたとえることができます。

接続されているデバイスが ONVIF をサポートしていることを確認してください。一部のデバイスでは ONVIF がデフォルトで無効になっている場合があります。
または、ONVIF による認証が無効になっている可能性があります。つまり、ログイン/パスワードは常にデフォルトになります。
WEBのログイン/パスワード問わず

一部のデバイスではONVIF プロトコル経由で動作するための別のポート

ONVIFのパスワードはWEBアクセスのパスワードと異なる場合があります。

ONVIF 経由で接続すると何が利用できますか?

デバイスの検出

ビデオ送信

音声データの受信と送信

PTZカメラ制御

ビデオ分析 (動き検出など)

これらのパラメータは、ONVIF プロトコルのバージョンの互換性によって異なります。場合によっては、一部のパラメーターが使用できないか、正しく機能しないことがあります。

Kさんと ONVIF を使用する

SNR および Dahua レコーダーでは、ONVIF プロトコルは [リモートデバイス] タブの製造元行にあります。

デバイスが接続されるチャンネルを選択します

[製造元] タブから、 ONVIF

特定 IPアドレスデバイス

RTSPポートはデフォルトのまま

カメラの使用 ONVIF ポート8080
(2017 年以降、新しい ONVIF モデルでは、Alpha および Mira シリーズのポートは 80 に変更されました)
オムニーカメラベース使用 ONVIF ポート80、レジストラでは HTTP ポートとして示されます。

名前

パスワードデバイスパラメータに従って

リモートチャンネルデフォルトは 1 です。デバイスがマルチチャネルの場合は、チャネル番号が表示されます。

デコーダバッファ— 時間値を示すビデオストリームのバッファリング

サーバーの種類ここではTCP、UDPスケジュールの選択があります

TCP- 送信者と受信者間の接続を確立し、すべてのデータが変更されることなく、必要な順序で受信者に到達することを保証し、また送信速度も調整します。

TCPとは異なり、 UDPは予備接続を確立せず、単にデータの送信を開始します。 UDP はデータが受信されたことを監視せず、損失またはエラーが発生した場合でもデータを複製しません。

UDP は TCP よりも信頼性が低くなります。しかしその一方で、失われたパケットの再送信がないため、より高速なストリーム送信が可能になります。

スケジュール— 自動タイプ検出。

Dahua では、接続されたデバイスは次のように表示されます

緑色のステータスは、レコーダーとカメラが正常に接続されていることを意味します

赤色のステータスは、接続に問題があることを意味します。たとえば、接続ポートが間違っています。

2つ目の接続方法は、 RTSP(リアルタイムストリーミングプロトコル)

RTSPビデオストリームを制御するためのコマンドを記述するリアルタイムストリーミングプロトコル。

これらのコマンドを使用して、ビデオストリームがソースから受信者にブロードキャストされます。

たとえば、IP カメラから DVR またはサーバーへ。

RTSP 経由で接続すると何が利用できますか?

ビデオ送信

音声データの受信と送信

アドバンテージこの転送プロトコルは、バージョンの互換性を必要としません。

現在、RTSP はほぼすべての IP カメラと NVR でサポートされています。

欠陥このプロトコルでは、ビデオとオーディオデータの送信以外には何も利用できません。

カメラの接続例を見てみましょうと RTSPを使用する

RTSP[リモートデバイス] タブの [製造元] 行にあり、SNR および Dahua レコーダーでは次のように表示されます。一般的な

デバイスが接続されるチャンネルを選択します

URLアドレス- ここに、カメラが送信するクエリ文字列を入力します。 基本的な RTSPストリーム高い 解決。

追加の URL - ここカメラが送信するクエリ文字列を入力します追加 RTSPストリーム 低解像度。

リクエストの例:

rtsp://172.16.31.61/1 メインストリーム

rtsp://172.16.31.61/2 追加ストリーム

なぜ追加のスレッドが必要なのでしょうか?

マルチピクチャレコーダーに接続されたローカルモニターでは、レコーダーは追加のスレッドを使用してリソースを節約します。たとえば、ウィンドウが 16 個ある小さな画像では、フル HD 解像度をデコードする必要はまったくなく、D1 で十分です。 1/4/8 ウィンドウを開いた場合、この場合、メインストリームは高解像度でデコードされます。

名前デバイスパラメータに従って

パスワードデバイスパラメータに従って

デコーダバッファ時間値を示すビデオストリームのバッファリング

サーバーの種類- TCP、UDP、スケジュール (ONVIF プロトコルと同様)

この記事では、次のような最も一般的な質問に答えます。

IPカメラはNVRと互換性がありますか?

対応しているなら接続方法は!?

RTSP (リアルタイムストリーミングプロトコル)– ビデオストリームを制御するための基本コマンドの単純なセットを含むリアルタイムストリーミングプロトコル。

ビデオ会議での RTSP ソースと IP カメラの接続

RTSP プロトコルを使用すると、TrueConf ユーザーは、このプロトコルを使用してブロードキャストする IP ビデオカメラやその他のメディアコンテンツソースに接続し、リモートオブジェクトを監視できます。ユーザーは、ビデオ会議中にそのようなカメラに接続して画像をブロードキャストすることもできます。

RTSP プロトコルのサポートにより、TrueConf Server ユーザーは IP カメラに接続できるだけでなく、RTSP プレーヤーやメディアサーバーにビデオ会議をブロードキャストすることもできます。 RTSP ブロードキャストについて詳しくは、こちらをご覧ください。

TrueConf ソフトウェアソリューションで IP カメラを使用する利点

オフィスや工場に IP カメラを設置し、いつでも接続できるようにすることで、会社の生産プロセスを管理できるようになります。
遠隔オブジェクトを 24 時間監視できます。たとえば、休暇に出かけており、アパートを無人のままにしたくない場合は、そこに 1 つ以上の IP カメラを設置するだけです。 TrueConf クライアントアプリケーションがインストールされている PC からこれらのカメラのいずれかを呼び出すことで、いつでもアパートに接続して、そこで何が起こっているかをリアルタイムで確認できます。
Windows、Linux、macOS 用の TrueConf クライアントアプリケーションでは、すべてのユーザーがビデオ会議を録画する機能にアクセスできるため、ビデオ監視中にあらゆるイベントを録画し、その証拠文書を受け取ることができます。

ビデオ放送を快適に視聴したり、パソコン上のソフトウェアマルチメディアプレーヤーを使用して設定したりできます。今日は、最も人気のあるプレーヤーの 1 つである VLC Media Player で、Dahua Technology ネットワーク機器の RTSP ストリームを構成する方法を見ていきます。

RTSP (Real Time Streaming Protocol) は、ユーザーがハイパーリンクとマルチメディアプレーヤー (この場合は VLC Media Player) を使用して、マルチメディアデータ (オーディオとビデオ) のストリームをリモートで再生できるようにするプロトコルです。

ビデオストリームを構成する必要がある場合は、次の手順を実行します。

まず、公式 Web サイトから無料で入手できる VLC Media Player をダウンロードしてインストールする必要があります。
メニュー項目「メディア – ネットワークストリームを開く (URL を開く)」をクリックします。
プロンプトラインに RTSP ネットワークアドレスを入力します。
ビデオ画像が画面に表示されたら、再生ボタンを押します。

リンクの説明 RTSP

例：

rtsp:// :@:/cam/realmonitor?channel= &サブタイプ=

どこ：

: ユーザー名 (ログイン)。

: パスワード。

：ネットワークビデオカメラのIPアドレス。

: デフォルトのポートは 554 です。この値は無視できます。

: チャンネル番号。番号付けは1から始まります。

: ストリームタイプ。意味メインスレッドは 0、追加スレッド 1 は 1、追加スレッド 2 は 2 です。たとえば、追加スレッド番号 1 のリンクは次のようになります。

rtsp://管理者: [メールで保護されています]:554/cam/realmonitor?channel=1&subtype=1

Dahua Technology IP ビデオカメラは、TCP および UDP データ転送プロトコルをサポートしています。ポート 554 が変更されている場合は、ビデオカメラ設定 (Web インターフェイス) の対応するフィールドで変更します。

RTSP ストリームの設定に問題がある場合は、該当するセクションを参照してください。

さまざまな Web ブラウザで IP カメラから RTSP ストリームをブロードキャストできるかどうかを確認する方法

Windows、Mac OS X、Linux を実行しているデスクトップ、および Android および iOS を実行しているモバイルデバイス上の Chrome、Firefox、Safari ブラウザで RTSP ビデオストリームの表示を確認してみましょう。

VLCでRTSPストリームを確認する

RTSP ストリームが利用可能でビデオがストリーミングされていることをすぐに確認するには、VLC プレーヤーで開きます。ストリームが正しく再生されたら、Web インターフェイスのテストに進みます。 IP カメラのコントロールパネルで RTSP URL を取得するか、公開されている RTSP ビデオストリーム (例: rtsp://b1.dnsdojo.com:1935/live/sys3.stream) を使用できます。

Google Chrome および Mozilla Firefox ブラウザでの RTSP-WebRTC ストリームのテスト

同じ RTSP ストリームが Chrome ブラウザと Firefox ブラウザの通常の HTML ページで再生されることを確認します。

1. アドレスにあるデモインターフェイスをロードし、メニュー「Demo / Streaming Min」を選択します。これは、WebRTC テクノロジーを使用して Chrome および Firefox ブラウザーに RTSP ビデオストリームを表示する最小限の HTML5 Web インターフェイスです。