ストリーミングはダウンロードと同じ量の帯域幅を使用しますか？

コンテンツが同じ品質（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

この率は、可能であろうものをはるかに下回っています（そして他のプロバイダでも達成されています）。また、別の素材を試した場合、レートは個々の動画に大きく依存していることがわかります。フルHD動画は＆gt;で簡単にダウンロードできます。 1MiB / s、このようなミュージックビデオは約200KiB / s以下のままです。

いくつかのプロバイダは、ストリーミング中、クライアントアプリケーション（html5を搭載したyoutube、フラッシュビデオプレーヤーなど）を介して、またはサーバー手段を使用して、ダウンロードをレート制限することがあります。ストリーミング配信中にクライアントアプリケーションによって適用される可能性のあるレート制限が実行されないため、それらがサーバの手段によってレート制限されていない場合、ダウンロードにより多くの帯域幅が消費されます。これは、消費された帯域幅が元の質問に対して異なる場合の主なケースです。

1. 私はこれが一種の逸話的証拠であることを承知しています - しかし私はこの行動を一貫して観察しました。

同じ品質（つまり、スロットルなし、フレームスキップ、または低品質のストリーム）について話していると仮定すると、せいぜいストリームはダウンロードと同じ量の帯域幅を使用しますが、時間/レートで実行できますプロバイダにとってより便利です。ビデオの圧縮方法によっては、より多くの帯域幅が必要になることもあります。ほとんどの場合、イメージ全体が送信されるのではなく、フレーム間の変化（またはデルタ）だけです。これは、より多くの履歴がある（すなわち、フレームＹ内のピクセルＸからの青の色相を使用する）ほど、送信する必要が少なくなることを意味する。通常これはあまりポップアップされませんが、何らかの理由でストリームが一時停止または中断されると、この「履歴」が失われて再送信する必要が生じるため、ダウンロード中は再開できます。そして、受信機が既にこの情報を持っていると仮定しました。特に固定レートがない場合（つまり、mp3の代わりにFLAC）、同じことがオーディオにも使用できます。

飛び跳ねること（スキップ、巻き戻しなど）も使用に影響を与える可能性があります。バッファを超えて進むと、ストリームで使用される帯域幅の量が減少しますが、巻き戻しを行うと増加します。また、割り込みが発生して使用量が増加し（上記参照）、YouTubeやNetflixで使用されているような「サムネイルプレビュー」も帯域幅をわずかに増加させます。

最後の注意：圧縮：これはダウンロードでは可能ですが、ストリームではそれほど可能ではありません。ほとんどのビデオはすでに圧縮されているため、ここではあまり得られないでしょう。高解像度/品質部門）。

特にネットワークの状態が悪い場合、ストリーミングでは使用する帯域幅が少なくなりますが、これには代償が伴います。 。

問題となるのは、送信する必要があるデータです。 ダウンロードモデルでは、すべてのデータが正しい順序で顧客に届く必要があります。 。ネットワークの状態が悪く、データの一部がクライアントに届かない場合は、それらを再送信する必要があり、これにより帯域幅の使用量が増加します。一部のデータが順不同になった場合は、表示する前に順序を元に戻す必要があるため、応答性が低下します。

ストリーミングモデルでは、データの一部がクライアントに届かなければ問題ありません。 。映画をストリーミングしていてフレームがそこに到達しない場合は、それをスキップして先に進むことができるので、再送信に追加の帯域幅を使用することはありません。いくつかのフレームが順不同になった場合は、先に進むものだけを再生してください。瞬間的なメッセージは問題にならないので、これは即応性を高めます。しかしながら、それはまた、あなたが必ずしも完全なデータを得るというわけではないということを意味します。

モデルを選択する必要がある場合は、データに対して何をしたいのかに基づいて選択します。 あなたがそれをアーカイブするそして/またはおそらくそれを何度も見たいのなら、それをダウンロードしてください。アーカイブを計画していない場合、またはデータを1回だけ表示することを計画している場合は、先に進んでストリーミングしてください。 1回の表示で違いに気付くことはおそらくないでしょうし、ネットワークの状態が気付かないほど悪い場合、ダウンロードはさらに悪くなります。

「合計データ」（バイト）ではなく「帯域幅」（バイト/秒）を本当に要求している場合、最も重要な問題は次のとおりです。ユーザーが動画全体を見て、同じコーデック/品質などが返され、ストリーミング要求/応答のわずかなオーバーヘッドを無視すると仮定した場合、返される合計データは等しくなります。

今、帯域幅は何ですか？あなたの質問を理解するには2つの方法があります。

1. ダウンロードが完了するまでにかかる時間の間の帯域幅。 ストリーミングでは、チャンクの終わりに近づくまでチャンクを見ている間に（次のチャンクが要求されたときに）高帯域幅のスパイクがゼロに戻るのを確認する必要があります。ダウンロードするには、ビデオ全体がダウンロードされるとすぐにゼロになる10分など、非常に高い帯域幅が表示されます。ここで実験を中止すると、ダウンロードの帯域幅は明らかに高くなります。ダウンロードが完了するまでダウンリンクが最大になるからです。

2. ビデオが視聴されている間の帯域幅。 両方がすぐに視聴を開始すると仮定すると、ビデオが視聴されている時間はストリーミングとダウンロードの両方で同じです。合計データサイズも同じです。帯域幅は時間あたりのデータなので、どちらのシナリオでも同じです。

以下の例では、合計40（データの単位）が常にダウンロードされています。しかし、「ダウンロード」の場合は最初の時間単位で40、「ストリーミング」の場合は最初の時間単位で20、その後2つの追加のチャンクで10倍になります。帯域幅はy軸にプロットされていますが、2つのグラフそれぞれの下の領域はデータ（バイト）に対応しています。 統合する 時間をかけてバイト/時間、あなたはバイトを取得します。

それらは比較できません。

第一に、ローカル視聴のための最適符号化は、ストリーミング視聴のための最適符号化とは異なる。

ビデオエンコーディングについて話しましょう。

ほとんどのビデオエンコード形式では、通常2種類のフレームがあります。

1. イントラ符号化フレーム（Ｉフレーム） - これらは完全に転送されるフレームであり、このフレームは他のフレームの知識なしに復号することができる。イントラ符号化フレームは本質的に静止画像である。エンコーダは突然の移行中にこれらを生成します。これらは圧縮するのが効率的ではありません。
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が発生していないと仮定しています。

あなたの質問は非常にゆるいので、私はそれをいくつかの素朴な設定でできるようにすることもできます 答えもYES（仮定）で、帯域幅は同じです。これを行うには、ファイルを基本のWebサーバーにドロップしてブラウザで開き、視聴者がアクセスできるようにします。または基本のWebサーバーにビデオを埋め込むと、ブラウザで再生され、同じ帯域幅が使用されます。次の仮定…他のユーザー、他のユーザーとネットワークを共有していること、帯域幅を変更する他の要因がないこと

Webサイトからファイルをダウンロードしてから再度ダウンロードすると、1回目と2回目のダウンロードの間の帯域幅が変わる可能性があることに注意してください。これは、単にサーバーの負荷が変わり、ネットワークとネットワークパスの輻輳が変わる可能性があるためです。

それであなたはそれを持っています...それは依存します。

ネットワークの観点からは、「ダウンロード」と「ストリーミング」は異なるサービスであり、「トラフィックプロファイル」と呼ばれます。

ストリーミングサービスの場合、ネットワークは最小の一定のスループット（技術的には「帯域幅」とは異なることを意味します）を提供する必要があり、ストリーミングサービスは中断やジッタに対して敏感です。最大のネットワークスループットを必要としないため、遅延や待ち時間は重要ではありません。

エンドユーザーの視点から見ると、ビデオは中断やドロップなしでスムーズに実行されます。ビデオの開始時間が数秒早くても遅くても構いません。

「ダウンロード」は通常最大の可能なネットワークスループットを必要とします、ダウンロードはできるだけ速く終えられるものとします。遅延、中断、およびジッタは重要ではありません。

ネットワークは、まったく異なるトラフィックプロファイルをさらに提供することがあります。たとえば、音声サービス（単純な電話）では非常に低いスループットが要求されますが、遅延（200ミリ秒未満）に対しては非常に敏感です。

他の答えに加えて、私の答えは： 必ずしも 。

さて、すべてが等しいと仮定すると（自動品質選択、サーバーやISPからの調整はありません）...

帯域幅 通常、size_of_dataをtotal_timeで割った値として定義されます。 （技術的には、「適切な」という用語は スループット しかし、私は掘り下げます）。

60 MBのサイズの2000秒のビデオをストリーミングするとしましょう。

ストリーミングでは、ストリーマプログラム たぶん バッファオーバーフローを防ぐために独自のレート制限を行います。そのため、そのHTTPリクエストヘッダには Rangeフィールド 。の 効果的 ストリーミングが開始されてからストリーミングが終了するまでの帯域幅は、約60 MB / 2000秒= 30 KB / s = 240 kbpsです。

しかし、あなたがビデオを完全にダウンロードするならば、あなたは得るでしょう まで インターネットサービスの最大帯域幅もちろん他の使い方にもよりますが。したがって、6 Mbpsのインターネットサービスを50％の使用可能帯域幅で行うと仮定すると、ビデオのダウンロードに3 Mbpsの帯域幅が得られます。

ストリーミングは本当にダウンロードの方法です。

あなたがストリーミングされた映画を見るとき、あなたのメディアプレーヤーはそれの一部をダウンロードし、あなたにそれらを見せ、そしてその場でファイルの示された部分を捨てます。

通常、ファイルをダウンロードするときは、ダウンロードが終了するのを待ってからファイルの視聴を開始します。しかし、ダウンロードしたファイルの一部を見せて自動的に一時停止して、もう少しダウンロードされるのを待つことができるメディアプレーヤーがあります。 Kindaはストリーミングを好みますが、ファイルを破棄しません。

技術的には、転送されるデータの総量が問題になる場合、ダウンロード方法は関係ありませんが、ダウンロードしたファイルとメディアプレーヤーがストリームとしてダウンロードしたファイルの違いは重要です。これらはまったく同じファイルである可能性があり、どちらの場合も同じ帯域幅を意味します。

ストリーミングメディアサイトは通常、店で購入したディスクよりも低いビットレートを持つようにコンテンツをエンコードします。しかし、あなたはあなたのOSのファイル共有機能を使ってWiFi経由であなたのデスクトップPCからあなたのデスクトップPCから映画を見ることができます、そしてそれはあなたがデスクトップでそれを見ていたのとほぼ同じ量のトラフィックを取ります。ドライブ）。技術的にはストリーミングです。映画の一部を連続的にダウンロードして破棄している間に映画を見るとします。

だから答えは それは絶対に2つのファイルのサイズに依存します - メディアプレーヤーを介してストリーミングし、ディスクにダウンロードした。

ストリーミングではダウンロードのスループットが使用されるため、ダウンロードと見なすことができます。あなたの質問はあなたがダウンロードを検討するものに関して少しあいまいです。あなたは彼らがすることができ、そして提供しても構わないと思っているだけアップロードすることができます。したがって、たとえばHTTPからDASH（まだHTTP）への直接ダウンロードを比較したい場合は、それぞれからどれだけのダウンロードが行われているかを確認する必要があります。

だから私は答えがそれが同じ量を使用している可能性があるということです...またはそれ以下...またはそれ以上。サーバーとそれらがあなたにサービスを提供しているレートに依存します。

はい、それは同等です。 ダウンロード=あなたは一度だけそれをダウンロードし、それはあなたのコンピュータに残ります。 Stream =あなたは一時的にあなたのコンピュータに "何か"をダウンロードします。