ソケットを使用してデータを他のデバイスに送信するアプリを作成しています。HTTP プロトコルを使用してデータを送受信しています。問題は、ビデオをストリーミングする必要があり、ビデオを送信する方法（またはビデオをストリーミングする方法）がわからないことです。
ユーザーがビデオの途中に直接ジャンプした場合、どのようにデータを送信すればよいですか。
ありがとう...
13494 次
1 に答える
18
HTTP は、ストリーミングを念頭に置いて設計されたわけではありません。正直なところ、最良のプロトコルは UDP ベースのものです ( SCTPはいくつかの点でさらに優れていますが、サポートは不完全です)。ただし、HTTP に制限される可能性があることを承知しておりますので、記載されているとおりに質問にお答えします。
また、ストリーミング ビデオは実際には非常に深いトピックであることも指摘しておく必要があります。エンド ツー エンド ソリューションを制御できる場合は、いくつかの選択肢があります。一方のエンドのみを制御する場合、選択は多かれ少なかれ、もう一方のエンドで利用可能なものによって決定されます。
ファイルの先頭からのみ再生したい場合は、かなり簡単です。標準の HTTP リクエストを作成し、ダウンロードに追いつく前にファイルのダウンロードを完了するのに十分なビデオをバッファリングしたらすぐに再生を開始します。レート。これには特別なサーバー サポートは必要なく、どのビデオ形式でも機能します。
シークはよりトリッキーです。YouTube のようなサイトが取っていたアプローチを取ることができます。これは、ビデオのそのポイントに到達するのに十分なファイルがダウンロードされるまで、ユーザーがシークすることを許可しない (または、そのポイントに到達するまでスピナーを見たままにしておく) ことです。 . ただし、これは、最近ほとんどの人が期待するユーザー エクスペリエンスではありません。
より適切に行うには、ストリーミング クライアントを制御する必要があります。ファイルをチャンクで扱い、一度に 1 つのチャンクに対してバイト範囲リクエストを行うことをお勧めします。ユーザーがファイルの途中までシークすると、ファイルへのバイト オフセットを計算し、その時点からバイト範囲リクエストを開始できます。
ビデオ形式の最初に何らかのインデックスが含まれている場合、これを使用してファイル オフセットを計算できます。そのため、ビデオ クライアントはシークを行う前に、少なくともインデックスを取得するのに十分な数を要求する必要があります。
形式にインデックスの形式がなく、固定ビット レート (CBR) でエンコードされている場合は、最初のHEAD要求を実行し、Content-Lengthヘッダーを調べてファイルのサイズを確認できます。次に、たとえば、使用がビデオの 40% をシークする場合、エンコードされたフレームの 40% をシークするだけです。これは、フレーミング情報などを特定できるように、適切なシーク ポイントを計算できるファイル形式について十分に理解している必要があります (または、少なくとも、ジャンプしてもオーディオ ストリームとビデオ ストリームの両方と再同期できるエンコード形式)。ファイル内の任意のポイントで)。このアプローチは、任意のシークから回復できる形式である限り、可変ビット レート (VBR) でも機能する可能性があります。
理想的ではありませんが、先ほど述べたように、HTTP は実際にはストリーミング用に設計されていません。
ファイル形式とサーバーを制御できる場合は、各チャンクを個別のリソースにすることで作業を楽にすることができます。これが、Apple HTTP ライブ ストリーミングとMicrosoft スムーズ ストリーミングの両方のしくみです。彼らはビデオを前処理するためのツール サポートを必要としており、サーバー エンドを制御できるかどうかはわかりません。ただし、検討する価値があるかもしれません。これらは、帯域幅の違いに対処するために、クライアントが異なるビット レートでエンコードされた複数のバージョンのストリームを切り替えることを可能にするなど、より巧妙なトリックも行います。
于 2013-01-16T09:24:25.893 に答える