PC

L-SMASH および Libav ライブラリを使用した AviUtl 入力プラグイン・ライブラリ「lsmashinput」を VFR-maniac（muken）氏が先日公開しました。seraphy氏作の「MP4 File Reader」に代わるMP4(mov等)コンテナファイルリーダーとして注目されるプロジェクトです。

AviUtl Plug-in SDK に MIT License が適用された事をうけ、「lsmashinput」をビルドした「Libav-SMASH File Reader」を公開するに至りましたが、一点だけ改良を加えてあります。

改良点
  • フルレンジの MPEG-4/AVC H.264 ストリームをスケール変換しないようにした
    • これは Libav(ffmpeg) 側の実装であり、オリジナルではフルレンジ（PCスケール）のH.264をTVスケールに問答無用で圧縮変換して渡しますが、AviUtl で「編集する」という用途を考慮すると、映像ストリームのスケールを勝手に変換されるのは芳しくありません。そこで、フルレンジなH.264をスケール無変換でデコード・ポストプロセスするよう修正してあります。

    これにより「ありのまま」の状態で映像データを取得でき──

    ■フルレンジのまま編集・出力
    ■プラグインフィルタ（拡張色調補正など）でTVスケールへ変換して編集・出力
    ■H.264ストリームの格納レンジをチェック

    といった処理手法のフレキシビリティを確保しています。

    もちろん、TVスケールな MPEG-4/AVC H.264 ストリームはスケール無変換で（TVスケールなまま） AviUtl に渡されます。これはオリジナルと同様です。

  • フルレンジアクセスの一例
    • ↑「ましろ色シンフォニー」OPより、このシーン（同一フレーム）をサンプルとして拝借。実際は1280x720の映像で、フルレンジYUV420変換してからエンコードされている（このスクリーンショットはRGBストレート変換されたもの）。
    ↑波形表示プラグインを使い、横1280の波形データを720ラインすべて拾った。白がY、赤がU、青がV成分。縦方向がデータのスケールで、下が0、上が255である。オリジナルのLibavを使うと、Yが16-235の間に圧縮変換されてしまっているのがわかる。
    ↑Libavを修正してスケール変換を無効化したもの。見てのとおり、Y16以下235以上にあるデータがそのままAviUtlに入力されている。このように、フルレンジを無変換で扱える（見られる）ため、映像ストリームの格納状態や画質チェックにも使え、スケール変換による読み込み劣化がない。ただし、AviUtlはTVスケールを基準としてYC48にマッピングしているため、プレビュー表示される映像は白飛び・黒つぶれして見えるが、データがクリップされているわけではない。

    注釈：
    オリジナルの Libav(ffmpeg) の挙動は、視聴といったRGB色空間変換を前提とした処理において間違いではなく、フルレンジをどう処理すべきかは考え方次第です。Libav の実装は「YCbCr/YPbPr(YUV)ならTVスケールに合わせてからRGB色空間変換時にYC伸張すれば良い」という真っ当な考え方ですし、一方で「YCbCr/YPbPr(YUV)がフルレンジなら、それを保持したほうが階調損失しないうえに、データもそのまま見られ、RGB色空間変換するにしてもストレート変換すれば良い」という考え方もあります。AviUtlで編集する用途（意味）を考慮した場合は後者のほうが良いだろうというだけで、Libav(ffmpeg)の実装が間違っているわけではありません。

    なお「Libav-SMASH File Reader」の詳細はアーカイブ内の Readme.txt をご覧ください。

    ダウンロード
    Libav-SMASH File Reader プラグイン(r17)
    Libav-SMASH File Reader ソースコード

  • リンク
    • ・AviUtlのお部屋
    ・VFR-maniac/lsmashinput　- GitHub ・l-smash － A simple tool for mp4.　- Google Project Hosting
    ・Get ffmpeg

    1件のコメント

    1. Libav-SMASH File ReaderでVFR動画を読み込んだ際にfps情報が元の値とかけ離れた数値になります。
      タイムコードを読み込めば映像の方は問題なくエンコ出来るのですが、音声の方はUtlで表示されている記録時間(正常でない)しかエンコ出来ません。
      これはLibav-SMASH File Readerの仕様ということで諦めるしか無いでしょうか？

      タチウオ

    2. MP4/MOVコンテナにfpsなんて概念はありません。
      そもそもVFRな動画の映像と音声がAviUtl上で同期する等ということはありえないので、VFRなMP4(とか)においてはfpsはtrivialな概念であり、従って、そのようなケースにおいては映像と音声は別々にエンコードされ、多重化されるべきです。

      muken

    3. x264guiEx.auoユーザーか何かかな。

      一応、平均フレームレートを計算して渡すという実装はできなくはないです。
      これによって、まぁ、AviUtlは映像の総再生時間を正確に近く取得することは出来ると思います。

      こちらとしては、音声を含めてVFRな動画をAviUtlで編集すると言う時点でカット編集は考慮していない(始点と終点しか一致しないので) -> 映像に対する音声の選択範囲の問題は？について判断しがたいところがあるのですがね。
      (例えば、読み込みソースに映像の2倍の長さの音声があったとする。この時渡すべきなのは、この2倍の全体なのか、それとも映像フレームが存在する範囲の時間までなのか)

      muken

    4. muken氏自ら返答していただいてありがとうございます。
      書いていただいたように、映像と音声を別々にエンコする方法が一番良いと私も思いました。
      平均フレームレートを算出するということも出来るのですね。
      ただ、私一人が苦になっていることで、それを実装していただくのは大丈夫でしょうか？
      私としては映像フレームが存在する範囲の時間までが一番好ましいと考えます。

      タチウオ

    6. とりあえず、タイムスケール/タイムベースではなく、 平均fpsを送るようにしました。
      ご自分でビルドなさるか、誰かがビルドして公開するのを待っていただければ、と思います。

      ※ 平均fpsは復号fpsからでも表示fpsからでもありません。
      復号基準では映像の有効範囲と、音声の有効範囲がだいぶずれる可能性がありますし、MP4やMOVにおいてメディア(復号および合成)とプレゼンテーション(表示)は切り離されており、lsmashinputがAviUtlに送るフレームはプレゼンテーションのものではなくメディアのものだからです。
      (プレゼンテーションはメディアから任意の場所を切り取り、組み合わせることが出来るので、これを基準にAvitUtlにメディアを送ると、見えない部分や重複する部分が出てくる -> 編集に不向き)
      従って、どのタイミングでメディアを合成するか？の合成fps(勝手な造語)で平均フレームレートを算出しています。
      そのため、元々のソースがプレゼンテーションを巧みに駆使して映像と音声の同期を計っている場合、映像の有効範囲外の遙か先に音声の有効範囲があったり、映像の有効範囲のかなり内側の部分が音声の有効範囲だったりする場合があります。(そんなソース、普通は先ずないとは思いますが、まぁ、最新のExporterだとキーフレームで切り取らなければ出来なくはないか…)

      muken

    7. 平均fps実装での更新ありがとうございます。
      私はビルドの知識が無いので、他の方の公開を待ちたいと思います。
      ソースによってはそのようなことが起こる可能性があるのですね。
      ご忠告ありがとうございます。
      一つ聞きたいのですが、L-SMASH File ReaderとL-SMASH Exporterのコードをビルドして公開している方はPOP氏の他にも居るでしょうか？

      タチウオ

    9. AviUtl上で異なるタイミングのレート（VFR相当のもの）を正しく表示するアイディアとしては、タイムスタンプやタイムコードを読み込み、タイムスケールの最小公倍数に合わせてnullやコピーといった疑似フレームを挿入して同期させる手はあると思います（面倒そうですが）。

      VFRは、AviUtlに限らず編集系ソフトにおいて少々厄介ではあるので、それを擬似的にCFR扱いで編集できるアイディアがどうしても必要かもしれませんが、そこまでやらなくてもいいのでは……とも思ったり。

      Libav L-SMASH File Reader と L-SMASH Exporter のバイナリを更新しましたが、コミットされる度に実行する時間はないため、大きな更新などがあったときにまとめてビルドしようかと思っています。

      個人的には、非公式ながらも lsmashinput/export　のビルドは続け、muken氏に情報フィードバックができる場として保っていければ、とは考えています。本当は、テキストをしっかり書いてあげたいくらい。

      POP

    10. ひとつだけ。
      関連リンクに”Get ffmpeg”が載っていますが、L－SMASH-Worksはいまのところ(おそらくは今後も)Libavのライブラリの使用のみ考慮しています。
      ffmpegのライブラリの使用は非推奨です。

      Chikuzen

    11. Libav が使用すべきライブラリであることは本文で触れているため、それをふまえた上で ffmpeg には様々なレポジトリがある事を意図的に見せるため get ffmpeg にリンクをしてあります。

      観点は色々あると思いますが、OSS の精神からすれば「ある人がLibav以外の何か」を用いてビルドしたり独自に改良を加えることは歓迎すべきですし、縛るものではないと考えているため、「狭く見せる」事は個人的に避けたいのです。

      もちろん、Chikuzen氏からすればトラブルの種は無いほうが望ましいとの考えからコメント下さったのは察しています。

      ただし、意を考慮して次回からは「推奨ライブラリは Libav」である旨を追記したいと思います。

      POP

    コメントを残す

    メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

    ÷ 5 = 2

    このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください。