Q. L-SMASHって何ですか？ A. 暫定・準公式ページがあるので、そこを参照して下さい。 http://up-cat.net/L%252DSMASH.html Q. ファイルフォーマットを指定するには？ A. muxerでは--file-formatを使います。コンマ(,)で区切ることで、複数のファイルフォーマットを指定出来ます。 (--file-format mp4,3gp とした場合、MP4と3GPPのハイブリッドなファイルが出来ます。) remuxerではファイルフォーマットを指定、すなわち変更することはできません。 ファイルフォーマットに依って、使用できるコーデックや機能が異なり、 各々のファイルフォーマットの仕様に合わせて情報を変換するといったことは、 複雑且つ高度になりますし、ユーザーの意図しない結果になりうるので、そのような機能は提供していません。 複数の入力ファイルに対して、異なるブランド(ファイルフォーマットの記述子)が存在する場合には、 その全てを出力ファイルへと継承させるようにしています。 Q. チャプターを付けるには？ A. --chapterを使用して下さい。引数にはチャプターの内容を記述したテキストファイルのパスを与えて下さい。 チャプターの形式にはNero形式(チャプターリスト)とApple形式(参照チャプタートラック)の二種類が実装されていますが、 Nero形式は全てのファイルフォーマットに対して書き込みを行う一方、 Apple形式はApple MP4(M4A, M4B, M4P, M4V)またはMOVに対してのみ書き込みを行います。 muxerでは--file-format m4aとすれば十分です。 Q. alternate-groupとはなんですか？ A. 0以外の同じ値を持つトラックを一つの代替グループに纏めるものです。 代替グループの中のトラック同士は再生時にお互い排反であり、いずれか一つのみを再生に使用することを意図しています。 但し、同じ代替グループのトラックは、お互いに異なる属性(attribute)を持たないといけません。 代表的な属性として言語(language)があります。 他にもコーデックやビットレート、解像度、フレームレート、サンプリングレートがありますが、これらを使って区別する処理系は少ないと思います。 残念ながら、アニメのコメンタリーに関しては、言語を騙るといったことくらいしか、alternate-groupを機能させる汎用的な方法はないように思われます。 alternate-groupはMP4コンテナでは規格上 無視されます。 これは、MP4では全てのオブジェクト(映像・音声・字幕など)の合成は、 Object DescriptorとBIFSというものを通してシーン記述(オブジェクトをどんな位置、形で表現するか)を行い、再生させるものだからです。 Apple MP4はMP4を冠しながらも、Object DescriptorとBIFSを使わずに再生可能なのでalternate-groupは有効です。 なお、alternate-groupは代替グループを形成するためのものであり、デフォルトで使用するトラックを指定する機能は備えていません。 Q. handler nameってなんですか？ A. トラックの種類を人間が読める形に格納したモノです。 Video, Audio, Subtitleっといった記述がここには格納されます。 本来の用途から外れて、ムービーのタイトル名をここに入れる方が居られるようですが、 ムービーのタイトル名はトラックレベルのモノではないので、ここにはふさわしくありません。 主音声(Main Audio)、副音声(Supplementary Audio)といった区分を記述する程度なら適当かもしれません。 なお、MOVとそれ以外とでは、ファイルフォーマットとしての文字列データの扱い方が異なります。 MOVではパスカル文字列(最初の1バイトが続く文字列の長さを表す。その為、0～255文字まで格納可能。)として扱いますが、 それ以外ではNULL終端文字列(文字列の最後の文字の直後の1バイトにNULL(0x00)を置きます。文字列長は実質無制限です。)を使用します。 その為、片方の文字列フォーマットしかサポートしていないdemuxerやプレイヤーでは、意図した通りに表示されないかもしれません。 Q. プログレッシヴダウンロード可能なファイルを作るには？ A. プログレッシヴダウンロードにはmoovというものがファイルのできるだけ先頭に置くようにする必要があるのですが、 remuxerでは強制的にこの処理を行うので気にする必要はありません。 muxerの方では--optimize-pdをオプションとして与えることで、これが機能します。 Q. muxerのトラックオプション encoder delay (priming samples)ってなんですか？ A. MDCTという技術を使う音声コーデックでは、二つの隣り合った音声フレームが意図した音を出すのに必要なデータを共有しています。 これにより、最初の音声フレームからは完全な音を出すことができません。 そのために、余白的なデータを最初の音声フレームとして付加してデコーダに復号させ、 次の音声フレーム以降に完全な音を出すことを実現しています。 この時に付加した余分なデータの長さを表すのがencoder delayです。 これをファイルに記述することで、再生時にこの部分の音をスキップすることを明示でき、ギャップレスを実現します。 iTunes/QuickTimeのAACエンコーダでは2112サンプル分がencoder delayとなっています。 他にもNero AACエンコーダでは2624サンプル分といったように、エンコーダや設定によってその大きさが異なります。 これとは別に、ランダムアクセス(シーク)においてもMDCTによる不完全な音声は構築されるので、 ランダムアクセスのたびに実際に再生したい音声フレームより1つ前のフレームからデコードしておく必要があります。 その明示方法はiso2以降のISO Base MediaまたはMOVで定義されているので、プレイヤーまたはdemuxerに伝えるには, --isom-version 2または--file-format movが必要です。 Q. muxerの--isom-versionは何の為にあるの？ A. ISO Base Mediaの仕様書の改正によってファイルフォーマットのバーションが定められています。 そして、そのバージョンによって使用できる機能を付加されたり、削除されたりしています。 ここでは主にランダムアクセスの記述方法に対応するために存在しています。 Open-GOP用のランダムアクセスの記述方法はversion 6で定義されています。 Open-GOPをMOV以外で使いたい方は--isom-version 6を指定して下さい。 --shift-timelineをMOV以外で使う場合には--isom-version 4以上が必要です。 ランダムアクセス時に、完全なデータの構築に必要なデコードするべきフレーム数を明示するには--isom-version 2以上が必要です。 Q: H.264ストリームをmuxerでインポートする場合、フレームレートが自動で適切に設定されないのですが？ A. H.264のストリームにはフレームレートを記述する機能を備えていません。 SEIを使用してタイムスタンプを記述することはできますが、任意であり、記述されるかどうかはエンコーダ依存となります。 従って、自動でフレームレートを「確実且つ適切」に設定することなど、SEIで記述されでもしない限り、またはソフトウェアがストリームに込められた思念波を読み取れでもしない限り不可能です。 そして、L-SMASHのmuxerはたとえ記述されていても、これを無視します。 H.264ではタイムスタンプを記述するSEIが無い場合、ストリームの時間軸の刻み幅を定義するのみとなります。これはHRDといったものに使用されます。 時間軸の刻み幅を記述するので、ここではフレームレベルでのその分子・分母をタイムベース・タイムスケールとそれぞれ呼ぶことにすると、 例えば、24000/1001 fpsは既約の形でタイムベースが1001でタイムスケールが24000と表すこともできます。 しかし、それと同時に、タイムベースが1でタイムスケールが24000とも表すことができるのです。 従って、タイムベースとタイムスケールからフレームレートを「確実且つ適切」に導き出すことは不可能です。 その為、L-SMASHのmuxerでは現在 {24000,1001}, {30000,1001}, {60000,1001}, {120000,1001}, {72000,1001}, {25,1}, {50,1}, {24,1}, {30,1}, {60,1}, {120,1}, {72,1} の { タイムスケール, タイムベース } の組に対してのみ フレームレート = タイムスケール / タイムベース frames per second としてみなすことにしています。 これ以外のタイムスケールとタイムベースの組がH.264ストリーム中に使用されていた場合には、これらを無視し、25/1 fpsとして扱うことにしてます。 当然のことながら、この検出方法も確実ではなく、{24000,1001}でも、ストリーム作成者の意図したものは12000/1001 fpsかもしれません。 従って、自動であなたの意図したフレームレートに設定されなくても、これはバグではありません。 このように、CODECによっては、自動での確実なフレームレートの検出方法は存在しないということを認識しておく必要があります。