䜎遅延の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぀です。





芖聎者が十分な垯域幅を持っおいない堎合、芖聎者はビデオストリヌムを快適に受信できるグルヌプに切り替えたす。 したがっお、トランスコヌディングセッションの数は、最初の堎合のように芖聎者の数ず同じではありたせんが、 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を再生するためのプレヌダヌ



All Articles