後でブラウザで使用できるように、ライブH.264ビデオストリームをMP4として保存するサーバーアプリケーションを設計しています。サーバーはできるだけ多くの同時ストリームを処理する必要があるため、I / Oが自然なボトルネックになると思います。また、I/Oを最小限に抑えたいと思います。私は古典的なMP4moov/ mdatの順序付けの問題に直面しています：MP4ジェネレーターは最初にmdatボックス（実際のメディアフレームを含む）を書き込み、次に実際の後にmoovボックス（ファイルオフセットやその他の構造情報を含む）を書き込むことを好みますmdatファイルのオフセットが何であるかを知っています。MP4の消費者は、プログレッシブストリーミングの反対を好みます。つまり、最初にmoovボックスを読み取るため、mdat構造がわかっており、ファイル全体をダウンロードしなくてもビデオの再生をすばやく開始できます。
通常の解決策は、MP4ファイルを後処理してmoovボックスをmdatボックスの前に移動し、それに応じてファイルオフセットを書き換えることです。ただし、大量のアプリケーションの場合、着信ビデオデータをディスクに書き込み、すべてを読み戻し、新しい配置で再度書き込むというI/Oペナルティを回避したいと思います。
いくつかのアプローチが思い浮かびます。
- 通常どおりMP4を後処理し、I / Oペナルティが発生し、ビデオの可用性が遅れる可能性があります。（良くない。）
- フラグメント化されたMP4と、メモリに収まるのに適した小さなフラグメントサイズを使用します。（これは、ファイル全体のシーク性に悪影響を与える可能性があると思います。）
- ファイルシステムが、ファイルのブロックチェーンの先頭に新しいブロックを追加するための高速な「追加」オプションを提供していれば素晴らしいでしょう。（これはまだ発明されていないと思います。）
- MP4を2つのファイルとして生成します。「mdat」ファイル（実際のメディアフレームを含む）と「moov」ファイル（ftypヘッダーとmoovデータを含む）です。これらの2つのファイルを連結すると、有効なmoov-firstMP4ファイルが生成されます。単純なWebサーバーモジュールは、仮想.mp4ファイルをユーザーに提示できますが、.moovファイルと.mdatファイルを舞台裏で読み取ります。
今のところ＃4に傾いています。この問題を解決するためのより実用的な方法はありますか？