プログレッシブHTTPダウンロードは、ライブビデオを提供するためのHLS / DASH / RTMPの実行可能な代替手段ですか?


16

ライブビデオをユーザーにストリーミングする必要があるWebサイトで作業しているため、現在のブラウザーベースのビデオストリーミングテクノロジーの残念な状態を回避する必要がありました。現在、ライブストリーミングの最も一般的なソリューションには互換性の問題があります。RTMPはFlashを必要とし、HLSはAndroidのSafariとChromeでのみネイティブにサポートされ、DASHはどこでもネイティブにサポートされず、dash.jsを使用するにはMedia Source Extensionsが必要ですが、これはまだ広くサポートされていません。

これは私には明らかな質問につながります:ブラウザーサポートまたはプラグインを必要とするHLS、RTMP、DASHのようなプロトコルの代替として単純なプログレッシブダウンロードを使用することは可能ですか?

プログレッシブダウンロードを使用してライブメディアをストリーミングするというアイデアは、これまでにないものではありません。人々はすでにオーディオのためにそれをしています。liveCasterなどのツールを使用すると、事前に記録されたMP3ファイルを必要とせずに、単一のプログレッシブHTTP応答を介してライブMP3オーディオをストリーミングできます。

しかし、ビデオでこの手法が実際に使用されている例は見たことがありませんが、その理由はわかりません。面倒で難しいブラウザ側の互換性の問題の層を比較的少ないトレードオフで削除するようです。(そして、ライブストリーミングの場合、プロが行っても互換性は依然として大きな問題です。FirefoxでBBCのiPlayerでライブビデオを視聴しようとすると、Flashをインストールするように指示するエラーメッセージが表示されます。)このテクニックは、私以外の誰もこのアイデア言及するのを見たことがない。

どうして?生成されているプログレッシブダウンロードを介してMP4のようなビデオファイルをストリーミングし、ダウンロードしながら<video>要素で再生することを不可能にする根本的な制限はありませんか?


HLS javascriptライブラリ(たとえば、hls.js:github.com/video-dev/hls.js/tree/master)を使用して、ページのクロスブラウザーHLSサポートを追加できませんでしたか?もともとこの質問をしたとき、これはおそらく存在しなかったと思います...しかし、今は存在します。:)
stuckj

回答:


3

あなたの質問は有効であり、理論的には、ライブビデオストリーミングにプログレッシブダウンロードを使用できると思います。実際、YouTubeなどのオンラインストリーミングビデオの多くは、すでにHTTPを使用しています。ストリーミングだけでなく、ライブストリーミングについて厳密に話していると思います。

ただし、自分でライブストリーミングのユースケースを実装する必要があります。それ以外の場合、ストリーミングプロトコル(RTMPなど)はそれ自体を実行します。これらのプロトコルとアーキテクチャを好む理由は次のとおりです。

1.可変ビットレート

ほとんどのライブストリーミングビデオはVBRでエンコードされているため、クライアントのネットワーク輻輳の変化にすばやく対応する必要があります。そのため、クライアント接続の速度に応じて、非常に短い時間でビデオの複数の解像度を切り替えることができます。

ウィキペディアによると

ユーザーの帯域幅とCPU容量をリアルタイムで検出し、それに応じてビデオストリームの品質を調整することで機能します。

2.ライブコンテンツ

最も重要な点は、ライブストリーミングはライブコンテンツを意味するということです。HTTPプログレッシブダウンロードとは異なり、いつでもバッファリングできません。ユーザーは全世界向けの最新フレームを見る必要があり、遅れることはありません。

3.シークを無効にする

軽微な問題ですが、プロトコルではユーザーが逆方向(および明らかに順方向)にシークすることを明確に許可しないでください。これは、ビデオプレーヤーレベルだけでなく、ネットワークレベルでも制御する必要があります。

4.頻繁な切断/信頼性の低いネットワーク

この点については少しわかりませんが、着信HTTPダウンロードが切断されると、別のハンドシェイクを確立するのに時間がかかることがあります(であってもkeep-alive)。ライブプロトコルは、次の点により接続と切断がはるかに高速です->

5.レイテンシー

HTTPは本質的にTCP上で実行され、パケットの配信が保証されます。これを、速度が保証よりも優先される多くのプロトコル(特にライブマルチプレイヤーゲーム)で使用されるUDPと比較してください。

詳細については、こちらをご覧ください -> https://en.wikipedia.org/wiki/Streaming_media#Protocols

6.コンテンツのコピー

ほとんどのライブストリームサーバーは、現在の時間のコンテンツにのみ応答します。ライブストリームのコンテンツをコピーすることはまだ可能ですが、スクリーンキャプチャなどに頼る必要があります。HTTPプログレッシブダウンロードを行うと、コンテンツのコピー作業が非常に簡単になります(したがって、非常に多くのYouTubeダウンローダーがあります)。

現在、HTTP は上記のほとんどを提供するようにモデル化できます。

AppleのHTTP Live Streaming(HLS)は、あなたが述べたように、あなたが達成しようとしているものに最も近くなります。

そして、ここで示されているように、この分野で活発な研究が行われています-> http://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=65749&PageNum=2

詳細を探しているので、この回答を更新します。


主要な競合他社が複数のシーケンシャルHTTPリクエストを介してビデオのセグメントを配信するDASHとHLSを含むことを考えると、HTTPプログレッシブダウンロードを使用することの欠点としてレイテンシーを言及するのは間違っているようです。プロトコルの詳細はわかりませんが、プログレッシブダウンロードアプローチでは理論上の最小レイテンシはないのに対し、後者のアプローチでは少なくとも使用されるセグメント長の最小レイテンシが必要だと思います。広告プログレッシブダウンロード方式の見晴らしの良い、右?
マークアメリー

また、ここでのその他の懸念のいくつか-切断からの探索や回復など-は、DASHのJavaScript実装にも同様に適用される問題ですが、dash.jsはおそらくそれらを克服します。プログレッシブダウンロードプレーヤーでは、dash.js開発者が思いついたあらゆるソリューションを盗むだけで、それらを克服できると思います。
マークアメリー

@MarkAmery DASHとHLSを比較すると、はい、私はそれと同等だと思います。しかし、UDPを介した古いプロトコルのいくつかと比較すると、HTTPは手を失います!たとえ多くのリアルタイムシステムが今日見られるとしても、その待ち時間の問題のためにWebsocketとeschew HTTPを使用して構築されています。
ガウラヴラマナン

1
ただし、dash.jsやHLSに比べて、コンテンツのコピーが簡単なことは大きな欠点です。また、プログレッシブダウンロードを使用して可変ビットレートストリームを実装する方法はわかりませんが、少しlittleな方法で可能になると予想しています。
マークアメリー

@MarkAmeryリアルタイムおよびライブストリーミングに関しては、可能性だけでなくパフォーマンスも考慮する必要があります。DASHを調べますが、ストリーミングプロトコルと切断から回復するHTTPのパフォーマンスの比較を示すベンチマークがあるかどうか疑問に思います。
ガウラヴラマナン
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.