ADSL技術を使ったテレビサービスがあります。これは、私のテレビが基本的にすべてをインターネット経由でストリーミングしていることを意味します。
私は今日、これが機能するためには少なくとも1MB /秒のアップリンクが必要であると言われました。あれは正しいですか?
注意してください、私は帯域幅のダウンについて話していません、それははるかに高いでしょう。これはpです。言い換えると、私のTVプロバイダーのセットトップボックスは、2〜3MB /秒のストリームをストリーミングするために少なくとも1MB /秒のアップロード容量が必要です(私はそれを推測しています)。
何を送っていますか? ACK?
ストリーミングプロトコルによって異なりますが、ackの送信、再送信要求、クライアント品質レポート、再生コマンド(再生/一時停止/巻き戻し)、およびネットワークの状態に合わせてストリームビットレートを変更する要求が発生する可能性があります。
これらはいずれも持続的な1Mbpsのデータレートに近づくことはないため、ヘッドルームが増えると、他のトラフィックが輻輳やバッファブロートを引き起こして干渉する可能性があることを期待して、実際に必要な以上のものを求めている可能性があります。ストリーミングサービスのスムーズな再生と操作。
セットトップボックスの正確なモデルと、TVプロバイダーとのインターフェイスに使用しているプロトコルを知らなければ、正確に何であるかを知ることは不可能です。その帯域幅をに使用します。ただし、お客様が受けたサービスに基づいて、知識に基づいた推測を行うことができます。
まず、 any デジタルビデオプロトコルには、ご想像のとおり、データの受信が成功したことを示す何らかの形式の「ACK」があります。デジタルビデオは一方向のプロトコルではありません。パケットを整理し、ビデオストリームの同期を維持するために(ビデオプレーヤーがビデオの再生速度が速すぎたり遅すぎたりしないようにするため)、双方がタイミングデータを相互に頻繁に送信します。ドロップされたパケットは、パケットを再送信する時間があるかどうかを判断するためのアルゴリズムに基づいて処理されます。または、ビデオをカットして続行します。また、不完全なデータをデコードして再生し、その結果として発生する可能性のある破損を受け入れることもできます(これが、無線のデジタルTVでこの問題が発生する場合がある理由です)。
加入者ベースのTVサービスも提供する必要があるその他の事項には、次のものがあります。
1 Mbit/sはかなりのように聞こえるかもしれませんが、通常のHTTPリクエスト(このサービスが使用する場合と使用しない場合があります)の公称オーバーヘッドは約 2% です。 1 Mbit/sの見積もりは、おそらく以下に基づいています。
ビデオプロトコルのオーバーヘッドは、実際には2%よりはるかに高い可能性があります。暗号化(両方向)により、数パーセント追加される場合があります。おそらく、各データパケットのサイズが非常に小さいため、合計パケット数が多くなり、各パケットにメタデータが関連付けられるため、全体的なオーバーヘッドが増加します。そのすべてが少し上流を含み、最終的にはそれが合計されます。
全体として、TVSTBに1Mbit/sのアップストリームが必要であると彼らが考える理由を確実に知る方法はありませんが、それはおそらく単なる推測であるか、特定の操作がアップストリームの少しのバーストを必要とし、それが必要であることを示したテストに基づいています適切なパフォーマンスを得るには一定の速度である必要があります(たとえば、STBを認証するための最初のハンドシェイクでは、ボックスがプロバイダーのセントラルオフィスと暗号化レイヤーを再ネゴシエートする必要があるたびにバーストが必要になる場合があります)。
ただし、通常はビデオをストリーミングしている間、安定した1 Mbit/sを使用しているとは思えません。ビデオの品質とビットレートは、合理的に効率的なビデオストリーミングプロトコルが継続的にそれだけのアップストリームを要求するためには、非常に高くなければなりません。
イーサネット上のAckパケットのサイズは最低64バイトであり、一般的なPPPoADSL展開の「ロードされた」ダウンストリームパケットのサイズは通常1492バイトです。
RFC1122は、「フルサイズのセグメントのストリームには、少なくとも2番目のセグメントごとにACKが存在する必要がある」と指定しています。
したがって、最小ack帯域幅比は64 /(1492 * 2)= 2.15%、つまり受信1MBあたり22,490バイトの確認応答が必要、またはビットレートとして5Mbpsダウンあたり約110kbps(0.1Mbps)アップです。
どういうわけか、彼らはあなたのアップストリーム帯域幅を望んでいると思います。
それらの「ストリーム」が一意に識別されたデータのブロックとして配信された場合、デバイスにダウンロードされたすべてのブロックをキャッシュさせ、分散ストレージとして機能させるのは簡単です。ライブストリームの場合、データブロックの起点が1つしかないため困難ですが、各ストリーム表示クライアントにランダムな「ブロックオフセット」の開始点(0〜30秒の配信遅延に相当)を与えることで、クライアントの要求を分散させることができます。さまざまなブロックとクライアントを利用して、ブロックを他のクライアントに再配布できます。ブロックの可用性は、制御サーバーによってインテリジェントに管理できます。新しいブロックは、アップロード帯域幅が最も高いクライアントに最初にプッシュされ、それらのクライアントは、クライアントの別の層にデータをプッシュするように指示されます。
デバイスに中程度のローカルストレージ(64GB)がある場合、最近表示されたコンテンツのVoD/PVRサービスは、プロバイダーにとってほぼゼロの帯域幅コストで実装するのは簡単です。個々のデバイスは、予測/測定された需要に応じて、分散ストレージネットワーク全体で十分なブロックの可用性を維持するために、必要に応じてストリームブロックを保持または削除するように指示されます。再生は、関連するブロックを要求し、ローカルキャッシュを実行するだけで実行され、必要に応じて可用性を保証するために中央サーバーを利用できます。