フラッシュ/フレックス:プログレッシブ ダウンロード vs.rtmp
-
20-09-2019 - |
質問
私は、プログレッシブ ダウンロードとプログレッシブ ダウンロードをいつ使用するかを理解し、正確に特定しようとしています。フレックス/フラッシュのrtmp。重要な点は、rtmp が http で提供されないのに対し、プログレッシブ ダウンロードは提供されるということのようです。rtmp ではないため、swf の外部から rtmp サーバーに接続する方法がないため、リソースは保護されます。
たとえユーザーがそのオブジェクトコードを見て場所を把握できたとしても
<object data="http://media.example.com/jw-player/player.swf" >
<param value="streamer=rtmp://sub.example.com/video
&file=1330/title/folder2/theflvresource.flv
&id=FlvPlayer" name="flashvars">
</object>
rtmp に接続できなくなります。ということは、リソースを保護したい場合には rtmp の方が便利だと思われますか?それだけですか?
解決
同意する xtat, しかし、さらに多くのことを追加したいと考えています。
RTMP (または任意の UDP ベースのストリーミング プロトコル) と私の控えめな意見では、「プログレッシブ ダウンロード」(実際には HTTP ベースのストリーミングのサブセットにすぎません):
- UDPベースのストリーミング
- 長所
- 現在、ストリームを盗むのは大幅に困難になっています
- 現在ライブをサポートしていますが、HTTP ベースではサポートされていません
- イントラネットで望ましいマルチキャスト対応
- 短所
- http ベースのアプローチと比較して、リソース使用量が大幅に増加する
- 特殊なサーバー (FMS、Red5、Wowza など) が必要
- より顕著なバッファリング
- ファイアウォールの問題、特に法人顧客における問題
- 長所
- HTTPベースのストリーミング
- 長所
- 極めてシンプル
- できる メディアに探求する。FLV と MP4 (多少の努力が必要)
- 短所
- ストリームを盗むのは簡単です。例えば。:リアルダウンローダー
- ライブ ストリーミングは現在不可能ですが、1 年ほどお待ちください。Apple はこれを現実にしています。
- マルチキャストなし
- 長所
HTTP ベースのアプローチ全体には次のものが含まれます。 そして/でも/場合 状況、何が可能で何が不可能なのかについての多くの誤解、そして共通の定義の欠如。
HTTP ベースのストリーミングについて議論するときに注目される基本的な特徴が 2 つあります。 探しています そして 規制された帯域幅. 。そこから、「疑似ストリーミング」、「プログレッシブ ダウンロード」などの用語が生まれました。
これらは、HTTP ベースのストリーミング サーバーを説明するために使用する定義です。
- 規制されたビットレート:フラット メディア ファイルはサーバーによって解析され、プレーヤーがバッファリングせずにメディアを再生するのに必要な速度でメディアを送信します。
- 探しています:Web サーバーがメディアを探索し、クライアントが使用できる新しい「ファイル」をオンザフライで効果的に作成する機能。http バイト範囲リクエストに似ていますが、ヘッダーとメディア メタ データが追加/変更される点が異なります。
- プログレッシブダウンロード:できるだけ早くファイルを送信してください。基本的に、大きな .iso または .zip ファイルのような「ダム」方法でクライアントに送信するメディア ファイルを Web サーバーに配置します。
- 疑似ストリーミング:Web サーバーが、規制されたビットレートでメディア ファイルをクライアントに送信し、ファイルをシークする機能。
他のヒント
個人的には、プログレッシブダウンロードの上にRTMPを選択する主な理由は、それはあなたのユーザーがファイル全体をダウンロードしなくても、動画の途中にスキップすることができますされます。
、RTMPを使用する任意の時点では、実際に存在しません。 HTTPは、デバッグが容易、簡単で、明らかにはるかに広く支持されており、確かにそれものCDN上で、求めても認めていません。これは私がViddlerに設定しているものです。