ストリーミングはダウンロードと同じ量の帯域幅を使用しますか？
コンテンツが同じ品質（ceteris paribus）であると仮定すると、ストリーミングメディア（すなわち、ビデオ、オーディオ）はそれをダウンロードするのと同じ量の帯域幅を使用しますか？
AmazonからHDムービーをダウンロードするかストリーミングするとしたら、それは同等の帯域幅の使用でしょうか。
多くの場合、同等ではありません。
ストリーミングプロバイダーは、 ダッシュ などのプロトコルを使用して、ユーザーの帯域幅の可用性と品質の要求に合わせてムービーの品質を動的に調整します。その後、サーバーは一定の量（10秒、おそらく30分、または1分程度）をバッファリングできるように接続を制限し、その後、コンテンツをリアルタイムで取得するために必要な帯域幅だけを取得できます。これはプロバイダの観点からは明らかに最適化されています。帯域幅をユーザ間でより均等に広げ、さらにデータが無駄に転送されるのを防ぐためです（たとえば、ユーザが480pの映画を10分間視聴した場合一般的なダウンリンクでは、それよりもはるかに多くのものがすでにダウンロードされていますが、ユーザーがビデオの視聴を停止すると無駄になります）。
転送されるデータの量は同じです。しかし、プロバイダはデータ転送をリアルタイムで所定の品質でコンテンツを配信するのに必要なレートにレート制限することができるので、ストリーミングにはもっと時間がかかるかもしれません。
Dailymotionは、接続を制限するプロバイダの1つです。 100Mbit/s以上の対称接続を持つサーバーからは、次のような動作が見られます。
youtube-dl http://www.dailymotion.com/video/xhc3zz_long-distance-calling-into-the-black-wide-open_music
[dailymotion] xhc3zz: Downloading webpage
[dailymotion] xhc3zz: Extracting information
[dailymotion] xhc3zz: Downloading embed page
[download] Destination: LONG DISTANCE CALLING - ' Into The Black Wide Open '-xhc3zz.mp4
[download] 5.8% of 51.99MiB at 203.89KiB/s ETA 04:06
この率は、可能であろうものをはるかに下回っています（そして他のプロバイダでも達成されています）。また、別の素材を試した場合、レートは個々のビデオに大きく依存することがわかります。fullhdビデオは> 1MiB/sで簡単にダウンロードされますが、このようなミュージックビデオは200KiB/s以下のままです。 。
いくつかのプロバイダは、ストリーミング中、クライアントアプリケーション（html5を搭載したyoutube、フラッシュビデオプレーヤーなど）を介して、またはサーバー手段を使用して、ダウンロードをレート制限することがあります。ストリーミング配信中にクライアントアプリケーションによって適用される可能性のあるレート制限が実行されないため、それらがサーバの手段によってレート制限されていない場合、ダウンロードにより多くの帯域幅が消費されます。これは、消費された帯域幅が元の質問に対して異なる場合の主なケースです。
- 私はこれが一種の逸話的証拠であることを知っています - しかし私はこの行動を一貫して観察しました。
同じ品質（つまり、スロットルなし、フレームスキップ、または低品質のストリーム）について話していると仮定すると、せいぜいストリームはダウンロードと同じ量の帯域幅を使用しますが、時間/レートで実行できます。プロバイダにとってより便利です。ビデオの圧縮方法によっては、より多くの帯域幅が必要になることもあります。ほとんどの場合、イメージ全体が送信されるのではなく、フレーム間の変化（またはデルタ）だけです。これは、より多くの履歴がある（すなわち、フレームＹ内のピクセルＸからの青の色相を使用する）ほど、送信する必要が少なくなることを意味する。通常これはあまりポップアップされませんが、何らかの理由でストリームが一時停止または中断されると、この「履歴」が失われて再送信する必要が生じるため、ダウンロード中は再開できます。そして、受信機が既にこの情報を持っていると仮定しました。特に固定レートがない場合（つまり、mp3の代わりにFLAC）、同じことがオーディオにも使用できます。
飛び跳ねること（スキップ、巻き戻しなど）も使用に影響を与える可能性があります。バッファを超えて進むと、ストリームで使用される帯域幅の量が減少しますが、巻き戻しを行うと増加します。また、割り込みが発生して使用量が増加し（上記参照）、YouTubeやNetflixで使用されているような「サムネイルプレビュー」も帯域幅をわずかに増加させます。
最後の注意：圧縮：これはダウンロードでは可能ですが、ストリームではそれほど可能ではありません。ほとんどのビデオはすでに圧縮されているため、ここではあまり得られないでしょう。高解像度/品質部門）。
ストリーミングでは、特にネットワークの状態が悪い場合は、使用する帯域幅が少なくなりますが、代償がかかります。
問題となるのは、送信する必要があるデータです。 ダウンロードモデルでは、すべてのデータが正しい順序で顧客に届く必要があります。ネットワークの状態が悪く、データの一部がクライアントに届かない場合は、それらを再送信する必要があり、これにより帯域幅の使用量が増加します。一部のデータが順不同になった場合は、表示する前に順序を元に戻す必要があるため、応答性が低下します。
ストリーミングモデルでは、データの一部がクライアントに届かなければ問題ありません。映画をストリーミングしていてフレームがそこに到達しない場合は、それをスキップして先に進むことができるので、再送信に追加の帯域幅を使用することはありません。いくつかのフレームが順不同になった場合は、先に進むものだけを再生してください。瞬間的なメッセージは問題にならないので、これは即応性を高めます。しかしながら、それはまた、あなたが必ずしも完全なデータを得るというわけではないことを意味します：あなたが見るものは何でも最初のショットでそこに得たものは何でも。
モデルを選択する必要がある場合は、データで何をしたいのかに基づいて選択します。それをアーカイブしたい場合、および/または表示する場合何度もダウンロードしてからダウンロードし、確実にすべてを入手してください。アーカイブを計画していない場合、またはデータを1回だけ表示することを計画している場合は、先に進んでストリーミングしてください。 1回の表示で違いに気付くことはおそらくないでしょうし、ネットワークの状態が気付かないほど悪い場合、ダウンロードはさらに悪くなります。
「合計データ」（バイト）ではなく「帯域幅」（バイト/秒）を本当に求めている場合、重要な質問は次のとおりです。ユーザーがビデオ全体を視聴し、同じコーデック/品質などが返され、ストリーミング要求/応答の小さなオーバーヘッドを無視すると仮定すると、返されるデータの合計は等しくなります。
さて、帯域幅は何ですか？質問を理解する方法は2つあります。
ダウンロードが完了するまでにかかる時間の帯域幅ストリーミングの場合、（次のチャンクが要求されたときに）戻る高帯域幅のスパイクが表示されますチャンクの終わりに近づくまでそのチャンクを見ながらゼロにすると、帯域幅が再び急上昇します。ダウンロードの場合、ビデオ全体がダウンロードされるとすぐにゼロになる、たとえば10分間の非常に高い帯域幅が表示されます。今すぐ実験を停止すると、ダウンロードする帯域幅が明らかに高くなります。これは、完了するまでダウンリンクが最大になるためです。
ビデオが視聴されている間の帯域幅ビデオが視聴されている時間は、ストリーミングとダウンロードの両方で同じです。合計データサイズも同じです。帯域幅は時間あたりのデータであるため、両方のシナリオで同じです。
以下の例では、常に合計40（データの単位）がダウンロードされます。ただし、「ダウンロード」の場合、最初の時間単位で40であり、「ストリーミング」の場合、最初の時間単位で20（初期の大きなチャンクを取得するため）であり、2つの追加チャンクで10倍です。帯域幅はy軸にプロットされますが、2つのグラフのそれぞれの下の領域はデータ（バイト）に対応することに注意してください。 integrate bytes/time over time、バイトを取得します。
それらは比較できません。
第一に、ローカル視聴のための最適符号化は、ストリーミング視聴のための最適符号化とは異なる。
ビデオエンコーディングについて話しましょう。
ほとんどのビデオエンコード形式では、通常2種類のフレームがあります。
- イントラ符号化フレーム（Ｉフレーム） - これらは完全に転送されるフレームであり、このフレームは他のフレームの知識なしに復号することができる。イントラ符号化フレームは本質的に静止画像である。エンコーダは突然の移行中にこれらを生成します。これらは圧縮するのが効率的ではありません。
- 予測フレーム（Pフレーム）または双予測フレーム（Bフレーム） - これらはフレーム間の差異のみを格納するフレームです。視聴者が前のフレームや後者のフレームも知っている場合にのみデコードできます。これらは圧縮する方がはるかに効率的です。
ローカルビューイング用のエンコードでは、高速ディスクシークを利用してより多くのPおよびBフレームを使用できますが、効率的なストリーミング用にエンコードされたビデオでは、突然の切り替えがない場合でもビデオ全体で冗長なIフレームをエンコードする必要がありますランダムシーク。
また、2種類のストリーミングがあります。録画済みのストリーム（ほとんどのYoutubeビデオ）とライブイベントストリーム（Youtube Liveなど）をストリーミングできます。待ち時間が必要なため、ストリーミングライブイベントでは、長い時間や予測不可能な時間を要する高度なエンコード技術を利用できませんが、録画済みのストリームではエンコードに必要な時間がかかることがあります。
ストリーミングビデオも通常、固定ビットレート（CBR）でエンコードされます。同じターゲットサイズの場合、可変ビットレート（VBR）ビデオは通常、CBRビデオよりも高品質になります。逆に、VBRビデオは、同じ品質のCBRビデオの場合は小さくなります。 DASHのようなアダプティブストリーミングプロトコルは、CBRとVBRの妥協点であるアダプティブビットレート（ABR）を持っています。 ABRは視聴者がネットワーク帯域幅の変化に適応することを可能にします。一定した、一貫した帯域幅を考えると、ABRはCBRとほぼ同じです。
これらすべての意味は、が同じ品質と視聴経験を与えられたであれば、ストリーミングビデオよりも効率的にローカルビューイング用のビデオをエンコードでき、ライブよりも効率的に録画済みストリームのビデオをエンコードできます。ストリーム。
その場合、ストリーミングプロトコルにもオーバーヘッドがあります。通常のHTTPダウンロードでは、チャンク転送エンコードを使用してファイル全体をダウンロードできますが、オーバーヘッドはごくわずかです。ストリーミングダウンロードでは、転送するチャンクとチャンクの品質についてネゴシエートする必要があります。物事の壮大な計画では、転送プロトコルのオーバーヘッドは比較的小さいです。
全体的に見て、同じ量のビデオを視聴するには、ストリーミングビデオはより多くの帯域幅を使用することになります。帯域幅の使用という点では、ストリーミングの主な利点は、ダウンロードしてもビデオを完全には視聴していない人たちにとっては節約できることです。これは非常に大きな節約になります。
答えは「それは違います」です。
一般的にビデオをホストするプロバイダにとって、答えは「いいえ」です。スムーズな再生とできるだけ多くの人々のための最適な帯域幅を保証するために、ビデオをストリーミングする半分まともなプロバイダはレート制御を行います。したがって、たとえあなたがたくさんの帯域幅を持っていても、それはあなたに5Mbitだけを与え、それでもかなりまともに見えるようにするかもしれません。
HTTPダウンロードをすると、TCPレート制御アルゴリズムが起動して、接続の片方または両方の端、あるいはその間の値を確実に飽和させます。あなたが利用可能な100Mbitを持っていたのであれば、それはそれが得ることができるすべてまたは100Mbit近くを使うでしょう。
もちろん、クライアントとサーバーの間のどこにもQoSが発生していないと仮定しています。
あなたの質問はあまりにもゆるいので、私はそれを作ることができたので、いくつかの素朴な設定でも答えは（仮定を使って）はい、帯域幅は同じです。これを行うには、ファイルを基本のWebサーバーにドロップしてブラウザで開き、視聴者がアクセスできるようにします。または基本のWebサーバーにビデオを埋め込むと、ブラウザで再生され、同じ帯域幅が使用されます。次の仮定…他のユーザー、他のユーザーとネットワークを共有していること、帯域幅を変更する他の要因がないこと.
Webサイトからファイルをダウンロードしてから再度ダウンロードすると、1回目と2回目のダウンロードの間の帯域幅が変わる可能性があることに注意してください。これは、単にサーバーの負荷が変わり、ネットワークとネットワークパスの輻輳が変わる可能性があるためです。
それであなたはそれを持っています...それは依存します。
ネットワークの観点からは、「ダウンロード」と「ストリーミング」は異なるサービスであり、「トラフィックプロファイル」と呼ばれます。
ストリーミングサービスの場合、ネットワークは最小の一定のスループット（技術的には「帯域幅」とは異なることを意味します）を提供する必要があり、ストリーミングサービスは中断やジッタに対して敏感です。最大のネットワークスループットを必要としないため、遅延や待ち時間は重要ではありません。
エンドユーザーの視点から見ると、ビデオは中断やドロップなしでスムーズに実行されます。ビデオの開始時間が数秒早くても遅くても構いません。
「ダウンロード」は通常、可能な限り最大のネットワークスループットを必要とし、ダウンロードはできるだけ迅速に終了するものとします。遅延、中断、およびジッタは重要ではありません。
ネットワークは、まったく異なるトラフィックプロファイルをさらに提供することがあります。たとえば、音声サービス（単純な電話）では非常に低いスループットが要求されますが、遅延（200ミリ秒未満）に対しては非常に敏感です。
ストリーミングではダウンロードのスループットが使用されるため、ダウンロードと見なすことができます。あなたの質問はあなたがダウンロードを検討するものに関して少しあいまいです。あなたは彼らがすることができ、そして提供しても構わないと思っているだけのアップロードをダウンロードすることができます。したがって、たとえばHTTPからDASH（まだHTTP）への直接ダウンロードを比較したい場合は、それぞれからどれだけのダウンロードが行われているかを確認する必要があります。
だから私は答えがそれが同じ量を使用している可能性があるということです...またはそれ以下...またはそれ以上。サーバーとそれらがあなたにサービスを提供しているレートに依存します。
他の答えに追加するために、私の答えは：必ずしもそうではありません。
ここで、すべてが等しいと仮定します（自動品質選択、サーバーおよび/またはISPからの調整なし）...
帯域幅は通常、size_of_dataをtotal_timeで割ったものとして定義されます。 （技術的には、「適切な」用語はthroughputですが、私は脱線します）。
60 MBのサイズの2000秒のビデオをストリーミングするとします。
ストリーミングでは、ストリーマープログラムmightは独自のレート制限を行って、バッファーオーバーフローを防ぎます。そのため、そのHTTPリクエストヘッダーには a Rangeフィールド が含まれる場合があります。ストリーミングが開始されてからストリーミングが終了するまでのeffective帯域幅は、約60 MB/2000秒= 30 KB/s = 240 kbpsです。
ただし、ビデオを完全にダウンロードすると、インターネットサービスの最大帯域幅を最大取得できます。もちろん、同時に他の用途に依存します。したがって、6 Mbpsのインターネットサービスと50％の利用可能な帯域幅を想定すると、ビデオのダウンロードに3 Mbpsの帯域幅が得られます。
ストリーミングは本当にダウンロードの方法です。
あなたがストリーミングされた映画を見るとき、あなたのメディアプレーヤーはそれの一部をダウンロードし、あなたにそれらを見せ、そしてその場でファイルの示された部分を捨てます。
通常、ファイルをダウンロードするときは、ダウンロードが終了するのを待ってからファイルの視聴を開始します。しかし、ダウンロードしたファイルの一部を見せて自動的に一時停止して、もう少しダウンロードされるのを待つことができるメディアプレーヤーがあります。 Kindaはストリーミングを好みますが、ファイルを破棄しません。
技術的には、転送されるデータの総量が問題になる場合、ダウンロード方法は関係ありませんが、ダウンロードしたファイルとメディアプレーヤーがストリームとしてダウンロードしたファイルの違いは重要です。これらはまったく同じファイルである可能性があり、どちらの場合も同じ帯域幅を意味します。
ストリーミングメディアサイトは通常、店で購入したディスクよりも低いビットレートを持つようにコンテンツをエンコードします。しかし、あなたはあなたのOSのファイル共有機能を使ってWiFi経由であなたのデスクトップPCからあなたのデスクトップPCから映画を見ることができます、そしてそれはあなたがデスクトップでそれを見ていたのとほぼ同じ量のトラフィックを取りますドライブ）。技術的にはストリーミングです。映画の一部を連続的にダウンロードして破棄している間に映画を見るとします。
だから答えはそれは絶対に2つのファイルのサイズに依存している - メディアプレーヤーを介してストリーミングし、ディスクにダウンロードした。