H.264ビデオがMP4コンテナよりもFLVコンテナの方がはるかに高速なのはなぜですか？
チューブサイトを開発していますが、現在H.264形式で問題が発生しています。 YouTubeが高解像度の動画をMP4コンテナに入れていることに気づいたので、論理的には同じことをしました。
次に、lighttpdにmod_h264_streamingをインストールして、ストリーミングとタイムラインスクラビングを機能させました。
問題は、大きなファイル（やや高解像度で> 500MB）がバッファリングを開始するのに永遠にかかることです（Flowplayerや他のFlashプレーヤーは最初にメタデータをダウンロードする必要があることを読みました）。 xmov atomをMP4Boxでファイルの先頭に移動しました（Qt QuickStartも試しました）が、それは役に立ちませんでした。
次に、オーディオトラックをインターリーブする必要があることを読んだので、それも行いました。これは変化を引き起こしませんでした：ビデオはまだ遅いです。
そこで、まったく同じH.264ムービーをFLVコンテナーに入れてみたところ、再生のバッファリングがほぼ瞬時に開始されました。速度は低下しませんでした。
だから私はここで何が欠けていますか？ lighttpdの組み込みmod_264_streamingを備えた通常のFLVコンテナよりも、モジュールmod_flv_streamingを備えたMP4コンテナを選択するのはなぜですか？明らかに、多くのWebサイトがMP4コンテナーを選択していますが、その理由がわかりません。
副次的な質問として、HTML5 <video>タグを使用して同じH.264MP4ムービーを試してみましたが、スクラブは超高速！ lighttpdのログファイルを調べたところ、Flashプレーヤーはタイムラインがスクラブされるたびにvideo.mp4?start=234を追加しますが、ネイティブHTML5 <video>タグを使用するブラウザはそのようなことをしません。これはFlashのある種の制限ですか？ FlashストリーミングがHTML5ストリーミングほど高速にならないのはなぜですか？
TL; DR：MP4は、ビデオサイトがFLVがサポートするよりも多くのメタデータをビデオに保存する場合、またはFLVがサポートしないオーディオコーデックを使用する場合に使用されます。 FLVのシンプルさとストリーミング用の設計は、MP4を使用する正当な理由がない場合に適しています。
フラッシュのタイムラインスクラビングについては、フラッシュをコーディングしたことがないのでなぜそうなるのかわかりませんが、フラッシュが使用するノブ、またはファイルを検索するためにAdobeのストリーミングサーバーで特に機能するものである可能性があります。また、厄介なユーザーがファイルをディスクに保持するのを防ぐ方法としても機能します。
あなたがすでに知っているいくつかのもの：
FLVコンテナとMP4（別名isomedia）コンテナには基本的な違いがあります。 FLVは最初からAdobeによってストリーミングコンテナとして考案されたもので、本当にシンプルです。ビデオパケット、オーディオパケット、ビデオパケットの順に送信するだけです...ただし、サポートするコーデックはごくわずかであり、ミリ秒単位のタイムスタンプ以外のメタデータはサポートしていません。 MP4固有の機能が必要でない限り、FLVで問題なく動作します。
一方、ISOメディアは、AppleのMOVコンテナに基づいています。アトムに分かれており、他のアトムを読み取る前にデコードする必要がある特定のアトムmoovがあります。 MP4で発生している問題は、moov atomがファイルの最後に書き込まれるためです。これは、プログラムのエンコードに非常に簡単です。ツールがあります。 qtfaststart のように、ファイルの先頭にmoov atomを配置するために必要な変更を行います。したがって、ファイルは再生を開始します。開始する前に完全にダウンロードする必要はなく、データがあればすぐに。
Movコンテナーを使用する場合は、モジュールをインストールしたり、flvコンテナーに配置してモジュールを使用したりすることなく、箱から出してストリーミングします。ただ私の考え。 movを使用して、適切なmimeタイプを追加します-完了。