ポリビジョン IP カメラからの Rtsp ストリーム。 RTSP プロトコル経由のビデオ監視。 落とし穴 #2 - カメラのビットレートと損失
RTSPプロトコル
RTSP (Real Time Streaming Protocol、ロシア語ではリアルタイム ストリーミング プロトコル) は、ビデオ ストリームを制御するためのコマンドを記述するアプリケーション プロトコルです。 これらのコマンドを使用すると、たとえばビデオ ストリームのブロードキャストを開始するようにカメラまたはサーバーに「命令」できます。 再生開始リクエストの例は次のようになります: PLAY rtsp://192.168.0.200/h264 RTSP/1.0
つまり、RTSP はビデオ ストリームを制御するためのコマンドのセットにすぎません。 実験をしてみましょう。 これを行うには、RTSP プロトコルとその RTSP アドレスをサポートする IP カメラが必要です。 このアドレスは rtsp:// のようになります。
TCPプロトコル
RSTP over TCP 方式を選択し、ビデオ ストリームの送信を開始したいとします。 輸送メカニズムのレベルでは何が起こるでしょうか? まず、いくつかのコマンドを使用して、送信者と受信者の間で接続を確立します。 その後、ビデオデータの転送が開始されます。 同時に、TCP メカニズム
すべてのデータが変更されることなく、必要な順序で受信者に届くようにします。 TCP はまた、送信側が受信側で処理できる以上のデータを送信しないように、送信レートを制御します。
UDP は、TCP トランスポート プロトコルの代替です。 TCP とは異なり、UDP は予備接続を確立せず、単にデータの送信を開始します。 UDP はデータが受信されたことを確認せず、一部が欠落していたり、エラーが発生して到着した場合でもデータを複製しません。 UDPレス
TCP よりも信頼性が高くなります。 しかしその一方で、失われたパケットを再送信するメカニズムがないため、ストリームの送信が高速になります。 TCP プロトコルと UTP プロトコルの違いは、次の例で説明できます。 二人の友人が出会う。 TCP オプション:
イワン：「こんにちは！ チャットしましょうか？ （接続が確立されました）
セミョン「こんにちは！ しましょう！」 （接続が確立されました）
アイヴァン：「昨日も店にいたんです。 わかりますか？" （データ転送）
セミョン「はい！」 （確認）
イワン: 「新しい機器がそこに降ろされました。 わかりますか？" （データ転送）
セミョン：「いいえ」（確認）
イワン: 「新しい機器がそこに降ろされました。 わかりますか？" (再送信)
セミョン「はい！」 （確認）
イワン：「明日、またそこに行きます。 わかりますか？" （データ転送）
セミョン「はい！」 （確認）
UDPオプション
イワン：「こんにちは！ 昨日お店にいたんです」（データ転送）
イワン: 「新しい機器がそこに降ろされました」 (データ転送)
イワン：「明日、また行きます」（データ転送）
アイヴァン: 「価格をお調べします」 (データ転送)
Ivan: 「彼らは大量の割引を約束しました」 (データ転送)
イワン：「よかったら電話してください、一緒に行きますよ」（データ転送）
セミョン「はい、電話します」（データ転送）
次の実験を行うことによって、プロトコルの違いを確認することもできます。カメラを RTSP over TCP モードに設定し、レンズの前で手を振ってみてください。モニター画面に遅延が表示されます。 次に、RTSP over UDP モードで同じテストを実行します。 遅延も少なくなります。 遅延は、圧縮形式、コンピュータの能力、伝送プロトコル、ビデオ デコードに関連するソフトウェアの機能など、いくつかの要因によって影響されます。
RTP (リアルタイム トランスポート プロトコル)、またはロシアのリアルタイム トランスポート プロトコル。 このプロトコルは、リアルタイム トラフィックを送信するために特別に作成されました。 送信データの同期を監視し、パケット配信のシーケンスを調整できるため、他のものよりもビデオおよびオーディオ データの送信に適しています。 一般に、ビデオ ストリームの送信には RTP または UDP を使用することが望ましいです。 TCP プロトコルはデータ転送中に発生するエラーや障害を修正できるため、問題のあるネットワークで作業する必要がある場合にのみ、TCP 経由で作業することが正当化されます。
CCTV カメラに付属のマニュアルには、デバイスの動作に応じた RTSP プロトコルに関する情報が含まれていない場合があります。 ただし、このプロトコルを使用する必要がある場合が非常に多いため、そのアドレスを調べる必要があります。
ビデオ監視システムの所有者は、さまざまな状況で RTSP ストリームを知る必要がある場合があります。
- ビデオカメラをクラウドサーバーに接続します。
- ウェブサイトへのビデオ情報の送信を設定するため。
- 携帯電話、ラップトップ、タブレットなどのさまざまなデバイスでプレーヤー ストリーム内のビデオを再生します。
RTSP プロトコルが必要な理由は何ですか?
プロトコル名 RTSP は制御をオンライン モードに移します。 したがって、リアルタイム ストリーミング プロトコルは、オンライン ビデオ ストリーミングの管理に役立ちます。 このプロトコルには必要なコマンドの記述が含まれているため、IP ビデオ監視でよく使用されます。
RTSP プロトコルを使用すると、セキュリティ カメラの所有者はいくつかの重要な機能を解決できます。
- VLC を使用してデータをブロードキャストします。
- リソースやプラットフォームにビデオをブロードキャストします。
- NVRビデオレコーダーを設定します。
- ビデオ監視カメラを仮想ストレージに接続します。
- Android または iOS ベースのモバイル アプリケーションにビデオ カメラを追加します。
同時に、ビデオ監視システムの多くのユーザーにとって RTSP ストリームを開くことは、それほど単純ではなく、非常に困難です。
CCTV カメラの RTSP アドレスを調べる
対応する手順にビデオ カメラの RTSP ストリームが示されていない場合に、それを見つけることができるオプションがいくつかあります。
ロシアで販売されている多数の IP ビデオ カメラには、中国製の XMEye 要素が含まれています。 これらのコンポーネントは、Vesta、HiQ、SVplus などの国内カメラメーカーでも見られます。 このようなモデルのカメラの RTSP ストリーム形式は次のとおりです。
rtsp://192.168.132.32:554/user=admin&password=12345&channel=1&stream=0.cgi
このアドレスには次のコンポーネントが含まれています。
- 192.168.132.32 – デバイスの直接 IP アドレス。
- 554 – プロトコル ポート (デフォルトでは 554 の番号が付けられていますが、このパラメータはデバイス設定で変更できます)。
- 管理者 – CCTV カメラのログイン。
- 12355 – ユーザーログインのパスワード。
IP ビデオ カメラに他のコンポーネントが含まれている場合は、以下にリストされている 2 つのオプションのいずれかを使用する必要があります。
最初のオプションが最も単純化されています。 CCTV カメラからの RTSP ストリームを確認するには、このデバイスのメーカーまたはサプライヤーに問い合わせる必要があります。 リクエストに応じて、必要なストリームの形式を提供することができ、中国の販売者でも、中国の工場または AliExpress ウェブサイトからこのサービスを提供できます。
2 番目のオプションは、専用のソフトウェアを使用することです。 この方法は、ビデオ監視システムの所有者がサプライヤーに RTSP ストリーム アドレスを要求する能力または要求を持たない場合に役立ちます。 その後、ソフトウェアを使用して自分で行うことができます。
まず、One Device Manager というプログラムをダウンロードする必要があります。 インストール後、このソフトウェアは RTSP アドレスを見つけるのに役立ちます。
一般に、ほとんどのビデオ カメラは onvif プロトコルをサポートしているため、ソフトウェアの使用に問題はありません。 重要なニュアンス - これが正しく動作するには、プログラムがインストールされるラップトップまたはコンピュータと、IP デバイス自体を同じローカル ネットワークに接続する必要があります。
RTSP ストリームのアドレスを含むリスト全体は、インターネット上で見つけることができます。このデータは、ビデオ監視カメラのブランドによって異なるためです。
ビデオカメラでRTSPストリームを開くにはどうすればよいですか?
RTSP ストリーム アドレスが追跡システムの所有者に知られると、所有者は IP カメラからビデオ情報を受信できるようになります。 ストリーミング ビデオ ブロードキャストを開くには、次の手順を完了する必要があります。
- ビデオ カメラの永久 IP アドレスを設定し、インターネット プロバイダーに注文します。
- ビデオ カメラからのローカル要求を RTSP ポートに転送します。
- 性能試験に合格する。
静的アドレスは、IP Hunter プログラムを使用して構成できます。または、プロバイダーに連絡して、追加オプションとして永続的な IP アドレスを提供するように依頼することもできます。 この後、ポート転送を設定し、ビデオ カメラのローカル ポートから RTSP ポートにポートを転送する必要があります。 その後、フローの確認に進むことができます。
RTSP リンクが機能しているかどうかを確認するには、VLC プレーヤーを開いて確認します。 これを行うには、プレーヤーのメイン メニューで「メディア」カテゴリをクリックし、「URL を開く」を選択する必要があります。 次に、「ソース」ウィンドウの「ネットワーク」タブに移動し、リンクを指定する必要があります。
RTSP (リアルタイム ストリーミング プロトコル)– ビデオ ストリームを制御するための基本コマンドの単純なセットを含むリアルタイム ストリーミング プロトコル。
ビデオ会議での RTSP ソースと IP カメラの接続
RTSP プロトコルを使用すると、TrueConf ユーザーは、このプロトコルを使用してブロードキャストする IP ビデオ カメラやその他のメディア コンテンツ ソースに接続し、リモート オブジェクトを監視できます。 ユーザーは、ビデオ会議中にそのようなカメラに接続して画像をブロードキャストすることもできます。
RTSP プロトコルのサポートにより、TrueConf Server ユーザーは IP カメラに接続できるだけでなく、RTSP プレーヤーやメディア サーバーにビデオ会議をブロードキャストすることもできます。 RTSP ブロードキャストについて詳しくは、こちらをご覧ください。
TrueConf ソフトウェア ソリューションで IP カメラを使用する利点
- オフィスや工場に IP カメラを設置し、いつでも接続できるようにすることで、会社の生産プロセスを管理できるようになります。
- 遠隔オブジェクトを 24 時間監視できます。 たとえば、休暇に出かけており、アパートを無人のままにしたくない場合は、そこに 1 つ以上の IP カメラを設置するだけです。 TrueConf クライアント アプリケーションがインストールされている PC からこれらのカメラのいずれかを呼び出すことで、いつでもアパートに接続して、そこで何が起こっているかをリアルタイムで確認できます。
- Windows、Linux、macOS 用の TrueConf クライアント アプリケーションでは、すべてのユーザーがビデオ会議を録画する機能にアクセスできるため、ビデオ監視中にあらゆるイベントを録画し、その証拠文書を受け取ることができます。
「互換性リストにない 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を使用する
.jpg)
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と互換性がありますか?
対応しているなら接続方法は!?
いくつかの報告によると、今日では、 何億ものビデオ監視用の 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 つのオプションがあります。
- 必要なビットレートで視聴者ごとにビデオ ストリームを個別にトランスコードします。
- ストリームをトランスコードするのは、接続している各ユーザーではなく、視聴者のグループです。
- いくつかの解像度とビットレートでカメラ ストリームを事前に準備します。
2 番目のオプショントランスコーディング グループを使用してサーバー CPU の負荷を軽減することです。 サーバーはビットレートごとにいくつかのグループを作成します (例: 2 つ)。
- 200Kbps
- 1Mbps
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 |
レイテンシー値を記録するために写真を何枚か撮りました。
