xtatに同意しますが、さらに追加したいと思います。
私のそれほど謙虚な意見では、RTMP(またはUDPベースのストリーミングプロトコル)と「プログレッシブダウンロード」(実際にはHTTPベースのストリーミングのサブセット)の長所と短所は次のとおりです。
- UDPベースのストリーミング
- 長所
- 現在、ストリームを盗むのは非常に困難です
- 現在、ライブをサポートしていますが、HTTPベースではサポートされていません
- イントラネットで望ましいマルチキャスト対応
- 短所
- httpベースのアプローチと比較して劇的に高いリソース使用量
- 専用サーバー(FMS、Red5、Wowzaなど)の必要性
- より顕著なバッファリング
- 特に企業顧客のファイアウォールの問題
- HTTPベースのストリーミング
- 長所
- デッドシンプル
- メディアを探すことができます。FLVとMP4(少し努力して)
- 短所
- ストリームを盗むのは簡単です。例:リアルダウンローダー
- 現在、ライブストリームは利用できませんが、1年は提供してください。Appleはこれを実現しています。
- マルチキャストなし
HTTPベースのアプローチ全体は、および/または/ ifの状況、何が可能で何が不可能かについての多くの誤解、および一般的な定義の欠如で 満たされています。
HTTPベースのストリーミングについて議論するときに人々が注目している2つの基本的な特性があります。それは、シークと規制された帯域幅です。それから、「疑似ストリーミング」、「プログレッシブダウンロード」などのこれらすべての用語を取得します。
これらは、HTTPベースのストリーミングサーバーを説明するために使用する定義です。
- 調整されたビットレート:フラットメディアファイルはサーバーによって解析され、プレーヤーがバッファリングせずにメディアを再生するのに必要な速度でメディアを送信します。
- シーク:メディアをシークし、クライアントが使用するためにオンザフライで新しい「ファイル」を効果的に作成するWebサーバーの機能。ヘッダーとメディアメタデータが追加/変更されることを除いて、httpバイト範囲リクエストに似ています。
- プログレッシブダウンロード:ファイルをできるだけ早く送信するだけです。基本的に、大きな.isoまたは.zipファイルのように、「ダム」方式でクライアントに送信するメディアファイルをWebサーバーに配置します。
- 疑似ストリーミング:調整されたビットレートでメディアファイルをクライアントに送信し、ファイルを検索するWebサーバーの機能。