web-dev-qa-db-ja.com

Webブラウザーでライブビデオをストリーミングするための現在のベストプラクティスは？

RTSP/UDPを介してH.264/MPEG4/MJPEGビデオをストリーミングするIPカメラ製品を開発しています。これにはWebインターフェイスがあり、現在、VLC Firefoxプラグインを使用して、ブラウザーでライブRTSPストリームを表示できるようにしていますが、FirefoxはNPAPIプラグインのサポートを中止しているため、現時点では行き止まりです。

カメラ自体は比較的低消費電力のARM SoC（Raspberry Piレベルと考える））であるため、ボード上でオンザフライでトランスコードストリームなどを行うための膨大なスペアリソースがありません。

主な目的は、Webインターフェースからビデオストリームが正しく機能していることを確認することです。そのため、他の形式/トランスポート/ストリーミングエンジンで新しいストリームをストリーミング（またはトランスコーディング）することは、元のRTSPストリームを直接再生するよりも望ましくありません。 。通常の使用では、ビデオはRTSP経由でVMSサーバーにストリーミングされるため、変更の余地はありません。

理想的な世界では、ソリューションはオープンソースのクロスブラウザーであり、HTML5タグ内で発生しますが、最も人気のある1つ以上のブラウザーで機能する場合は、それを採用します。

私は、HTML5ビデオタグ、WebRTC、HLSなどの勇敢な新しい世界について、さまざまなものをここやウェブ上で読んでいますが、関係のない賢明で完全なソリューションのように見えるものはまだ見ていませんいくつかの追加の変換/トランスコーディング/再ストリーミング。多くの場合、半分サポートされているフレームワークまたは中間にある追加のサーバーによって実行可能なソリューションではありません。

ストリームをwhat-html5-video-likesに「変換」するために何が必要かどうかについて、適切な説明がまだありません。同じ基本的なビデオストリームのわずかに異なるラッパーであっても、たくさんある場合でも、オーバーヘッドとすべてが異なります。同様に、変換がオンボードで実行されたのか、JSを使用してブラウザー内で実行されたのかは明確ではありません。

タイトルの理由は、すべての動作を変更する必要がある場合、「ベストプラクティス」と見なされ、可能な限り合理的に将来を見据えたあらゆることを行うことを目的とする可能性があるためです。ブラウザー更新の次のラウンド/次のW3Cプレスリリースを超えて機能する...

2017年には、これを達成するための賢明な方法がないように思われるので、少しがっかりしました（おそらく驚くべきことではありません）。

おそらく「最低ワーストプラクティス」がより適切な用語です...

htmlvideobrowservideo-streaminghtml5-video
11
John U

トランスコーディングを必要としない多くの方法を使用できます。

WebRTC

RTSPを使用している場合は、WebRTCを介してストリームを送信する方法がほとんどです。

WebRTCはストリームの宣言にSDPを使用し、RTP=これらのストリームの転送に使用します。WebRTC呼び出しのセットアップに必要な他のレイヤーがいくつかありますが、これらのどれも特に高価な計算を必要としません。ほとんどの（すべて？）WebRTCクライアントはH.264デコードをサポートしますが、その多くはブラウザーでハードウェアアクセラレーションを備えています。

WebRTCを使い始める最も簡単な方法は、最初にブラウザー間クライアントを実装することです。その後、独自の実装でレイヤーをさらに深くすることができます。

WebRTCは私があなたにお勧めするルートです。 NATトラバーサル（ほとんどの場合）およびP2P接続が組み込まれているため、顧客はIPアドレスを覚える必要がありません。シグナリングサービスを提供するだけで、顧客は直接カメラに接続できます。どこからでも自宅にアクセスできます。TURNサーバーを提供すると、両端がファイアウォールで保護されている場合でも接続できるようになります。このようなサービスを提供したくない場合は、軽量であり、カメラのようなモードで直接実行できます今日持っている。

<video>タグを使用したフラグメント化されたMP4 over HTTP Progressive

この方法はWebRTCよりもはるかに単純ですが、現在行っている方法とはまったく異なります。 H.264ストリームを取得し、トランスコーディングせずにMP4に直接ラップすることができます。その後、ページの<video>タグで再生できます。コードに適切なライブラリを実装する必要がありますが、クライアントにパイプ処理するSTDOUTに出力するFFmpegの例を次に示します。

ffmpeg \
  -i YOUR_CAMERA_HERE \
  -vcodec copy \
  -acodec copy \
  -f mp4 \
  -movflags frag_keyframe+empty_moov \
  -

その他...

あなたの場合、DASHに追加の利点はありません。 DASHは、ストリーミングにファイルベースのCDNを利用することを目的としています。サーバーを制御するので、ファイルを書き出すことや、HTTPリクエストをファイルのように処理することに意味はありません。トランスコーディングなしでH.264ストリームでDASHを使用することは確かに可能ですが、それはあなたの時間の無駄だと思います。

HLSはほとんど同じです。ストリームはHLSと互換性がありますが、HLSはコーデックに柔軟性がないため、急速に支持を失っています。 DASHとHLSは基本的に同じメカニズムです...メディアセグメントの束をCDNに書き込み、それらがどこにあるかを示すプレイリストまたはマニフェストを作成します。

10
Brad

Raspberry Pi 3に戻っているときにも同じことをしなければなりませんでした。piでffmpegを使用してオンザフライでトランスコードし、ストリーミングに https://github.com/phoboslab/jsmpeg を使用しましたmjpeg。その後、ブラウザ/イオンアプリで再生しました。

var canvas = document.getElementById('video-canvas');
this.player = new JSMpeg.Player(this.button.url ,{canvas: canvas});

私たちはPiで2〜5秒未満の最小遅延で最大4つの同時ストリームを管理していました。

しかし、React Nativeに移動したら、電話でRN VLCラッパーを使用しました

0
rMili