WebRTCを使用してIPカメラからビデオストリームをブロードキャストします

一般的に言えば、IPカメラからのオンラインブロードキャストの問題を解決するには、WebRTCを使用する必要はありません。 カメラ自体はサーバーであり、IPアドレスを持ち、ビデオコンテンツを配信するためにルーターに直接接続できます。 では、なぜWebRTCを使用するのですか？











これには少なくとも2つの理由があります。



1.イーサネットブロードキャストの視聴者の数が増えるにつれて、最初はチャンネルの厚さが不足し、次にカメラ自体のリソースが不足します。



2.前述のように、IPカメラはサーバーです。 しかし、彼女はどのプロトコルでビデオをデスクトップブラウザーに提供できますか？ モバイルデバイス？ ほとんどの場合、ビデオフレームまたはJPEG画像がHTTP経由で送信されるHTTPストリーミングになります。 ご存じのとおり、HTTPストリーミングはリアルタイムストリーミングビデオに完全に適しているわけではありませんが、ストリームインタラクティブ性と遅延が特に重要ではないオンデマンドビデオで実証されています。 実際、映画を視聴する場合、他の人と同時にこの映画を視聴しない限り、数秒の遅延で悪化することはありません。 「いや！ ジャックは彼女を殺した！ -悲劇的な結果の10秒前に、アリスをボブのネタバレとチャットで書きます。



または、RTSP / RTPおよびH.264になります。この場合、VLCやQuickTimeなどのビデオプレーヤープラグインをブラウザにインストールする必要があります。 このようなプラグインは、プレーヤー自体のようにビデオをピックアップして再生します。 しかし、松葉杖やプラグインを追加インストールせずに、実際のブラウザストリーミングが本当に必要です。



まず、IPカメラをスニッフィングして、このデバイスをブラウザーに正確に送信するものを見つけます。 テスト対象はD-Link DCS 7010Lカメラです。







カメラのインストールと設定の詳細については、下記をご覧ください。ただし、ここでは、ビデオストリーミングに使用するものを確認します。 Webインターフェースを介してカメラの管理パネルにアクセスすると、次のような現象が見られます（風景についてはごめんなさい）：







画像はすべてのブラウザーで開き、1秒に1回程度、均等に改ざんされます。 ストリームを監視するカメラとラップトップの両方が1つのルーターに接続されていることを考えると、すべてがスムーズで美しいはずですが、そうではありません。 HTTPのように見えます。 Wiresharkを起動して、推測を確認します。







ここでは、1514バイト長のTCPフラグメントのシーケンスを確認します







そして、JPEGの長さが受け入れられ、後続のHTTP 200 OK：







次に、 Chrome / Developer Tools / Networkに移動し、GETがちらつく様子をリアルタイムで確認しますHTTP経由で送信されたリクエストと画像：







このようなストリーミングは必要ありません。 スムーズではなく、HTTPリクエストをプルします。 カメラは1秒あたりいくつの要求に耐えますか？ 視聴者10人以前では、カメラが安全に曲がったり、ひどいグリッチを起こしたり、スライドを放り出したりすると考えられる理由があります。



カメラ管理パネルのHTMLページを見ると、次のような興味深いコードが表示されます。

if(browser_IE) DW('<OBJECT CLASSID="CLSID:'+AxUuid+'" CODEBASE="/VDControl.CAB?'+AxVer+'#version='+AxVer+'" width="0" height="0" ></OBJECT>'); else { if(mpMode == 1) var RTSPName = g_RTSPName1; else if(mpMode == 2) var RTSPName = g_RTSPName2; else if(mpMode == 3) var RTSPName = g_RTSPName3; var o=''; if(g_isIPv6) //because ipv6 not support rtsp. var host = g_netip; else var host = g_host; o+='<object id="qtrtsp_object" width="0" height="0" codebase="http://www.apple.com/qtactivex/qtplugin.cab" '; o+='classid="clsid:02BF25D5-8C17-4B23-BC80-D3488ABDDC6B" type="video/quicktime">'; o+='<param name="src" value="http://'+host+":"+g_Port+'/qt.mov" />'; o+='<param name="autoplay" value="true" />'; o+='<param name="controller" value="false" />'; o+='<param name="qtsrc" value="rtsp://'+host+':'+g_RTSPPort+'/'+RTSPName+'"/>'; o+='</object>'; //alert(o); DW(o); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

RTSP / RTPは、適切なビデオ再生に必要なものです。 しかし、これはブラウザで機能しますか？ -いいえ。 ただし、QuickTimeプラグインをインストールすると、すべてが機能します。 しかし、私たちは純粋なブラウザベースのストリーミングを行っています。



ここでは、適切なWowzaタイプのサーバーを介してRTSP、RTP、H.264から変換されたRTMPストリームを受信できるFlash Playerに言及することもできます。 しかし、ご存知のように、Flash Playerはブラウザープラグインでもありますが、VLCやQuickTimeよりも比類なき人気があります。



この場合、同じRTSP / RTPの再ストリーミングをテストしますが、追加のブラウザープラグインやその他の松葉杖のないWebRTC互換ブラウザーは、紛失したデバイスとして使用されます。 リレーサーバーをセットアップします。リレーサーバーは、IPカメラからストリームを取得し、WebRTCをサポートするブラウザーを使用して、任意の数のユーザーにインターネットに送信します。

IPカメラ接続

前述のように、テストにはシンプルなD-Link DCS-7010L IPカメラが選択されました。 ここでの主要な選択基準は、デバイスがRTSPプロトコルをサポートしていることです。これは、サーバーがカメラからビデオストリームを取得するために使用されるためです。



キットに含まれているパッチコードを使用して、カメラをルーターに接続します。 電源を入れてルーターに接続すると、カメラはDHCP経由でIPアドレスを取得しました。この場合は192.168.1.34でした（ルーターの設定に入ると、DCS 7010Lデバイスが接続されていることがわかります-これです）。 カメラをテストします。



ブラウザ192.168.1.34で指定されたIPアドレスを開き、カメラ管理者のWebインターフェースに入ります。 デフォルトではパスワードはありません。







ご覧のとおり、管理パネルではカメラからのビデオが正しくブロードキャストされています。 同時に、定期的なけいれんが顕著です。 これはWebRTCを使用して修正します。

カメラのセットアップ

まず、カメラの設定で認証をオフにします。テストの一環として、要求するすべてのユーザーにストリームを提供します。 これを行うには、カメラのウェブインターフェースの[設定]-[ネットワーク設定]に移動し、 [ 認証 ]オプションを[無効 ] に設定します。



そこで、RTSPプロトコルポートの値をチェックします。デフォルトでは554です。送信されるビデオの形式は、使用されるプロファイルによって決まります。 カメラには3つまで設定できます。最初のlive1.sdpを使用します。デフォルトでは、ビデオにH.264を、オーディオにG.711を使用するように設定されています。 必要に応じて、 セットアップ-オーディオとビデオのセクションで設定を変更できます。







これで、RTSPを介してカメラを確認できます。 VLC Playerを開き（RTSPをサポートする他のものを使用できます-QuickTime、Windows Media Player、RealPlayerなど）、Open URLダイアログでRTSPカメラアドレスを設定します：rtsp：//192.168.1.34/live1.sdp







まあ、すべてが正常に機能します。 カメラは、RTSPプロトコルを介してプレーヤーでビデオストリームを定期的に再生します。







ところで、ストリームはアーティファクトなしで非常にスムーズに再生されます。 WebRTCからも同じことを待っています。

サーバーのインストール

そのため、カメラがインストールされ、デスクトッププレーヤーでテストされ、サーバーを介したブロードキャストの準備が整います。 whatismyip.comを使用して、カメラの外部IPアドレスを特定します。 私たちの場合、それは178.51.142.223でした。 RTSPを介してポート554にアクセスすると、着信要求がIPカメラに送信されることをルーターに伝えることが残っています。



適切な設定をルーターに打ち込んで......







... telnetを使用して外部IPアドレスとRTSPポートを確認します。



telnet 178.51.142.223 554



このポートで応答があることを確認した後、WebRTCサーバーのインストールに進みます。



Amazon EC2の Centos 64ビット上の仮想サーバーがホスティングを担当します。

パフォーマンスの問題が発生しないように、1つのVCPUを持つm3.mediumインスタンスを選択しました。







はい、はい、LinodeとDigitalOceanもありますが、この場合は驚きました。

今後は、Amazon EC2コントロールパネルで、いくつかのルール（転送ポート）を追加する必要がありますが、これがないとこの例は機能しません。 これらは、WebRTC（SRTP、RTCP、ICE）トラフィック用のポートとRTSP / RTPトラフィック用のポートです。 試してみると、Amazonルールは着信トラフィックに対して類似したものを持つ必要があります。







ちなみに、DigitalOceanを使用すると、すべてがより簡単になります。ファイアウォールでこれらのポートを開くか、ファイアウォールを消してください。 DOインスタンスの操作に関する最新の経験によれば、それらは依然として静的IPアドレスを発行し、NATを気にしません。つまり、Amazonの場合のようにポート転送は必要ありません。



RTSP / RTPストリームをWebRTCに中継するサーバーソフトウェアとして、 Flashphonerの WebRTC Media＆Broadcasting Serverを使用します。 ストリーミングサーバーは、RTSP / RTPストリームをFlashに送信できるWowzaに非常に似ています。 唯一の違いは、このストリームがFlashではなくWebRTCに送信されることです。 つまり ブラウザーとサーバーの間で正直なDTLSが行われ、SRTPセッションが確立され、VP8でエンコードされたストリームがビューアーに送られます。



インストールには、SSHアクセスが必要です。







理論的には、ポイント10の代わりに、必要なすべてのポートとファイアウォールルールを設定するのが正しいでしょうが、テストの目的で、彼らは単にファイアウォールを無効にすることを決めました。

サーバーのセットアップ

WebRTCブロードキャストの構造は次のとおりです。







この図の基本的な要素は既に設定済みであり、相互作用の「矢印」を確立するために残っています。



ブラウザーとWebRTCサーバー間の接続は、 githubにあるWebクライアントによって提供されます。 JS、CSS、およびHTMLファイルのセットは、インストール段階で/ var / www / htmlに単純にスローされます（ネタバレの下の上記の段落9を参照）。



ブラウザーとサーバー間の対話は、XML構成ファイルflashphoner.xmlで構成されます。 そこで、WebクライアントがHTML5 Websocketを使用してWebRTCサーバーに接続できるように、サーバーのIPアドレスを入力する必要があります（上記のポイント9）。



サーバーのセットアップはここで終了し、その動作を確認できます。



ブラウザでindex.html Webクライアントページを開きます（このため、 yum -y install httpdコマンドを使用してApacheを同じAmazonサーバーにインストールしました ）。



54.186.112.111/wcs_media_client/?id=rtsp://webrtc-ipcam.ddns.net/live1.sdp







ここで、 webrtc-ipcam.ddns.netは、外部IPアドレスを参照する動的DNSサーバーnoip.comから取得した無料のドメインです。 ネットワークNATアドレスの変換規則（上記も参照）に従ってRTSP要求を192.168.1.34にリダイレクトするようにルーターに指示しました。

id = rtsp：//webrtc-ipcam.ddns.net/live1.sdpパラメーターは、再生するストリームのURLを指定します。 WebRTCサーバーは、カメラからのストリームを要求し、それらを処理し、WebRTC経由で再生するためにブラウザーに渡します。 ルーターがDDNSをサポートしている可能性があります。 そうでない場合、IPカメラ自体にそのようなサポートがあります。







したがって、DDNSサポートはルーター自体を調べます。







これで、テストを開始して結果を評価できます。

テスト中

ブラウザーでリンクを開くと、WebRTCサーバーへの接続が行われ、WebRTCサーバーはIPカメラにビデオストリームを受信する要求を送信します。 プロセス全体には数秒かかります。







この時点で、ブラウザーはWebソケットを介してサーバーに接続し、サーバーはRTSPを介してIPカメラを要求し、RTPを介してH.264ストリームを受信し、VP8 / SRTPにトランスコードします-最終的にWebRTCブラウザーを再生します。







さらに、少し待ってから、すでにおなじみの写真が表示されます。







ビデオの下部に、ビデオストリームのURLが表示されます。このURLはコピーして、別のブラウザーまたはタブから表示するために開くことができます。

これが本当にWebRTCであることを確認します。

突然、私たちはwereされ、IPカメラからのビデオは再びHTTPを経由しますか？ ぼんやりと写真を見ることはありませんが、実際にどのようなトラフィックが得られるかを確認します。 もちろん、ChromeでWiresharkとデバッグコンソールを再度実行します。 Chromeブラウザコンソールでは、次のことを確認できます。







今回はちらつきがなく、HTTP経由で送信された写真は表示されません。 今回目にするのはWebsocketフレームのみで、それらのほとんどはWebsocketセッションをサポートするためのping / pongタイプです。 興味深いフレーム：connect、prepareRtspSession、onReadyToPlay-これがサーバーへの接続の確立方法です。最初にWebsocketを介して接続し、次にストリームの再生を要求します。



そして、これがchrome：// webrtc-internalsが示すものです







グラフによると、IPカメラのビットレートは1Mbpsです。 発信トラフィックもあります。ほとんどの場合、これらはRTCPおよびICEパケットです。 AmazonサーバーへのRTTは約300ミリ秒です。



ここでWiresharkを見てみましょう。サーバーのIPアドレスからのUDPトラフィックがそこにはっきりと見えます。 次の図は、1468バイトのパケットを示しています。 これはWebRTCです。 より正確には、ブラウザ画面で見ることができるVP8ビデオフレームを運ぶSRTPパケット。 さらに、STUN要求（写真の最下位のパケット）はスキップします-このWebRTC ICEは接続を慎重にチェックします。







また、ビデオ再生の比較的小さな遅延（データセンターへのpingは約250ミリ秒でした）に注目する価値があります。 WebRTCはSRTP / UDPで動作します。これは、HTTP、RTMP、および他のTCPに似たストリーミング方式が何であれ、パケットを配信する最速の方法です。 つまり 目に見える遅延は、RTT +ブラウザによるバッファリング、デコード、および再生の時間です。 この場合、視覚的にはそうです-目にはほとんど遅延が見えず、500ミリ秒未満です。



次のテストは、他の視聴者を接続することです。 私はなんとか10個のChromeウィンドウを開くことができ、それぞれに写真が表示されました。 同時に、Chrome自体も少し鈍くなってきました。 別のコンピューターで11番目のウィンドウを開くと、再生はスムーズなままでした。

モバイルデバイス上のWebRTCについて

ご存知のように、WebRTCはAndroidプラットフォーム上のChromeおよびFirefoxブラウザーをサポートしています。

ブロードキャストがそこに表示されるかどうかを確認します。







HTC電話の写真では、カメラからのビデオがFirefoxブラウザーに表示されます。 デスクトップからの再生の滑らかさに違いはありません。

おわりに

その結果、最小限の労力でIPカメラから複数のブラウザーにWebRTCオンラインブロードキャストを開始することができました。 タンバリンと一緒に踊る必要もロケット科学も必要ありません。LinuxとSSHコンソールの基本的な知識だけが必要です。



放送品質は許容範囲内であり、再生ラグは目に見えません。



要約すると、ブラウザベースのWebRTCブロードキャストには存在する権利があると言えます。 私たちの場合、WebRTCはもはや松葉杖やプラグインではなく、ブラウザでビデオを再生するための実際のプラットフォームです。

WebRTCの普及が見られないのはなぜですか？

主なブレーキは、おそらく、コーデックの不足です。 WebRTCコミュニティとベンダーは努力して、H.264コーデックをWebRTCに導入する必要があります。 VP8に対して言うことはありませんが、H.264で動作する互換性のある何百万ものデバイスとソフトウェアを放棄するのはなぜですか？ 特許、そのような特許...



第二に、ブラウザでの完全なサポートではありません。 たとえば、C IEとSafariの場合、質問は開いたままなので、別の種類のストリーミングに切り替えるか、webrtc4allなどのプラグインを使用する必要があります。



そのため、将来的には、トランスコーディングとストリーム変換が不要になり、ほとんどのブラウザーがさまざまなデバイスから直接ストリームを獲得できる、より興味深いソリューションを期待しています。