x264_L-SMASH とは
ffmpeg / Libav 等に実装されている lavf を用いてオーディオの入出力をサポートしたものに x264-audio があり、その GPAC ライブラリを L-SMASH ライブラリに差し替えて開発されていたプロジェクト。端的には、x264 をフォークした x264_audio 、その x264-audio をさらにフォークして誕生したのが x264_L-SMASH とも言えます。

当方のビルド指針
  • 必要だと思われるパッチのみ当て、不具合検出の切り分けを容易にして安定性を重視する
  • Windows 向け x86（32bit）およびx64（64bit）バイナリ、lavfの有無を含めた4種のバイナリをリリース

    • x264 および x264_L-SMASH 最新情報（Rev.2409）
  • x264_L-SMASH の L-SMASH ライブラリは r890 相当
  • ffmpeg git-f7f5370(x264_L-SMASH)
  • r2358からffmpegsource(ffms)のサポートを外しました（lavfで事足りるため）
  • x264_L-SMASH オリジナルの lavf 入力で確認された以下の不具合をすべて修正
  • PCM音声のAVI・WMV コンテナを入力するとチャネルレイアウトが不正でエンコードできない
  • リサンプラーを通すと音が割れるなど音質が極度に劣化する
    テンポがスローになり音程が下がる(例：44.1KHz入力→48KHz出力/8bit→16bit等)
  • ファイル名に Unicode が含まれている場合、出力ファイル名が文字化けする

  • colormatrix未指定時のデフォルト値を「undef」ではなく「bt709」に変更

    • 現在の映像フォーマットは解像度に関係なくBT.709が大半を占める（日本のデジタル放送のSD送信はBT.709。DVDも近ごろはHD制作の影響からBT.709ベースが多い）ため、うっかり指定しなかった場合の救済策。もちろん、colormatrix オプションで指定した場合は、その値が適用されます。しかし、ポストプロセスの色空間変換に colormatrix 設定を渡して正しく処理してくれる環境はあまり無いため、神経質になる必要もなく、「保険」程度に捉えてください。

    # 現状 Android 端末は、colormatrixを見ずBT.601固定であり、Windows系プレイヤ（デコーダ・ポストプロセス処理を含む）もcolormatrixフラグを無視して解像度判定するものが多い（本来、BT.601やBT.709は解像度で決められているものではないため、エンコード時に出力解像度でcolormatrixを変更するものではありません。あくまでデコード時の苦肉の策です）。

    OpenCL について
    lookahead 処理を GPU に渡し、コンピュートタスクとして実行させるOpenCLパッチがr2286付けで公式に取り込まれました。OpenCL 1.1 以降に対応したGPUと対応ドライバが必須となります。

    # AMD製GPUの省電力コントロール技術・スイッチャブルグラフィックス技術を統合した「Enduro」には非対応
    # IvyBridge までの Intel 製 iGPU は非対応（Haswell の iGPU Iris 等の対応状況については不明）

    当方の動作環境下（Windows7 Professional x64 / HD5670 および HD7870 / Catalyst 13.4）において動作確認済みですが、異なる環境（異なるCatalystバージョンやNVIDIA製GPUとGeForce Driverの組み合わせ等）での動作確認はしておりませんので、それら環境での絶対的な動作保証は致しかねます。ご了承ください。

  • OpenCL オプションスイッチについて
    • OpenCLに関するオプションスイッチは以下のとおり。

    --opencl
    OpenCLを有効化します（未指定・デフォルトでは無効）。対応ビデオカードとOpenCL対応ドライバが必須となります。

    --opencl-clbin "カーネルファイル名とそのパス"
    OpenCL有効時にコンパイルされたカーネルを任意ファイルパスへ保存します。ファイル名・拡張子も任意で指定可。

    --opencl-device (integer)
    OpenCLで処理する際に、スキップさせるデバイス（GPU）数を指定します。デフォルトでは検出されたOpenCLデバイス（GPU/CPU）を扱うため、シングルGPU環境では未指定でかまいません。

    動作確認環境
    CPU : Core i5-2500K
    GPU : AMD RADEON HD7870
    主記憶 : 16GB
    Windows10 Pro 64bit
    AviSynth 2.6
    AviSynth+ r1576
    AviUtl version1.00

    動作不具合に関するコメント時のお願い
    基本的に、同じ挙動を再現するための確認を行い、それで再現確認できた場合のみ不具合として当方にできる範囲内での対応をします。そのため「○○できない。フリーズする。」だけでは大雑把すぎて再現することが難しいケースもあり、できる限りで結構ですので「再現の条件・環境」をお伝えいただきたいと思います。

    ダウンロード
    転送量超過を防ぐため現在のところ日本国内のみのアクセスに限定しています

  • x264_l-smash r2409 32bit
  • x264_l-smash r2409 64bit
  • x264_l-smash r2409 diff

    • x264 / x264_L-SMASH 公式・非公式リンク
  • x264公式 VideoLAN - x264, the best H.264/AVC encoder
  • x264_L-SMASH 限りなく公式に近い非公式 猫科研究所 - x264_L-SMASH unofficial repository

    • 　

    1件のコメント

    1. l-smash_r755でUTF-8がベースになっているようですが、
      いくつかのファイル名でremuxerを試してみると文字化けしてしまいます。

      下記コマンドを書いたbat（エンコードUTF-8）を実行すると、結果はすぐその下のようになりました。

      remuxer -i “C:\hoge.mp4” -i “C:\hoge.m4a” -o “C:\結合.mp4”
      remuxer -i “C:\hoge.mp4” -i “C:\hoge.m4a” -o “C:\♢結合.mp4”
      remuxer -i “C:\hoge.mp4” -i “C:\hoge.m4a” -o “C:\結♢合.mp4”
      remuxer -i “C:\hoge.mp4” -i “C:\hoge.m4a” -o “C:\結合♢.mp4”
      remuxer -i “C:\hoge.mp4” -i “C:\hoge.m4a” -o “C:\結合タイトル「第一話サブタイトル」.mp4”

      結合.mp4（正常）
      ♢結合.mp4（正常）
      結♢吁Emp4（文字化け）
      結合♢.mp4（正常）
      結合タイトル「第一話サブタイトル、Emp4（文字化け）

      上から三番目と五番目のパターンでは文字化けしてしまいます。
      これはUTF-8への対応がまだ不完全なのでしょうか？

      hogemi

    2. > hogemi さん

      開発のmuken氏がCLIへの実装はこれからと呟いていたため、それまでは旧revisionをお使いいただければと思います。

      POP

    3. こんにちは、はじめまして。tokと申します。
      いつもL-SMASH Worksを大変便利に使わせていただいております。感謝しております。

      L-SMASHと接関係ないことでしたらすみません。
      丸1週間ほど悩みましたがどうしても解決できないことがあるのでお教えいただけましたら幸いです。

      【作業環境】
      Windows7 64bit Professional
      aviutl 1.00+自動フィールドシフト7.5a+拡張x264guiEx2.01 色変換は”自動”@aviutl標準
      x264 r2358 64bit(L-SMASH)
      L-SMASH Works r679
      MP4box 0.4.6 r3745(wipple)

      にて作成しましたプログレッシブな24fps※自動フィールドシフト使用+60fps※自動フィールドシフト不使用のMP4ファイルを
      aviutlの読み込み(lwinput)＞追加読み込み(lwinput)＞エクスポートからL-SMASH Works Muxerで結合して
      エクスポートしました所、まともに再生できないファイルが出来上がってしまいました。
      24fpsのMP4をA.mp4、60fpsのMP4をB.mp4、結合させたMP4をC.mp4としますと
      具体的には

      GOM　　 ・・・　Aの部分は灰色、Bの部分から正常に再生
      MPC-HC　・・・　Aの部分は正常に再生、Bの部分は直前のAの最後の画が上部から段々モザイク状に崩れて行く
      VLC　　 ・・・　Aの部分は正常に再生、Bの部分に入る直前に500ms程度静止、Bの部分を正常再生

      と、プレーヤーごとに挙動が違います。音声はどのパターンでも正常に再生できていました。
      コマンドラインでMP4Boxを使い、-add A.mp4 -cat B.mp4 -new C.mp4というようにしてみますと

      GOM　　 ・・・　Aの部分は灰色、Bの部分から正常に再生　音声正常
      MPC-HC　・・・　Aの部分はBL（黒一色）かつ上部からモザイク状に崩れ、Bの部分は正常に再生　音声正常
      VLC　　 ・・・　Aの部分は一切なく、Bの部分から開始。しかし音声はAの部分からなので動画が先に終わってしまい、残りの音声は最後のフレームの静止画で楽しむことになります

      また、試しにMP4Boxのnightly buid(GPAC 0.5.1-4738)のmp4box.exeを使ってみました。
      すると
      WARNING: Concatenating track ID 1 with different SPS – result file might be broken
      WARNING: Concatenating track ID 1 with different PPS – result file might be broken
      という警告が・・・もうたぶん壊れてるよと言われてました。
      実際にそれはその通りで、ここからSPSとPPSについて調べましたら、如何にも画の崩れそうな要因に当たりそうでした。
      しかし検索してみますとそれをどう修正すればよいのか、また修正する方法も見つかりませんでした。

      どのようにすればスムーズに再生できる正常なMP4ファイルを作れるでしょうか。
      何か決定的に使い方を間違っていましたら申し訳ございません。。
      どうかお知恵を拝借できましたら幸いです。

      tok

    4. L-SMASH Works File ReaderのLibav+L-SMASHを使用していれば、結合したファイルがきちんと表示できるのは確認できていれば、ファイルとしては問題ありません。正常です。

      問題となるのは、デコーダの初期化に必要な情報のIDが同じなのに内容が異なると、それを格納するための機構が複数必要になって、また、それに対応しているdemuxer/splitterがほとんど存在しないということです。
      libavformat由来のdemuxerは最後の初期化情報をデコーダに渡すので、Bパートだけが正常に再生できるということになります。

      とりあえず、x264エンコーダに渡す際に、フレームレートを含めて、すべて設定を同じにした上で–stitchableオプションをつけてエンコードして下さい。
      テストしていませんが、–sps-idを異なるように設定してエンコードすれば、同じにしなくてもいけるかもしれませんが保証できません。

      muken

    5. ご回答ありがとうございます。
      mukenさんの仰る通り、結合したファイルをaviutlで読み込みましたら映像も音声も正常に結合されているようでした。ファイルとしては正常だったのですね。demuxer/splitterの対応の方がまだされていないと・・・またBパートだけ正常に再生される事由も得心致しました。ご説明有難うございます。

      またフレームレートを含めてAとBをすべて同じ設定にしようとしたのですが、拡張x246出力exをCLIモードで実行しても、aviutlのソース動画から得られたフレームレートを引数の最後に強制的に入れてしまうようで、任意の数値に設定することが出来ませんでした。
      なのでそちらは試せておりませんが、–sps-idをAパートとBパートで変えるという手法を試しましたところ、

      ■ L-SMASH Works Muxerでエクスポート
      Aパートの最後で映像が止まり（モザイク状に壊れず、そのまま）続けてBパートの音声のみ流れ続ける

      ■ GPACのnightly build 32bit版(r4738)同梱のmp4boxで手動結合
      WARNING: Concatenating track ID 1 with different SPS — result file might be broken
      WARNING: Concatenating track ID 1 with different PPS — result file might be broken
      と表示されるものの、再生には問題なし

      という結果になりました。
      ちなみにビットレートが違う状態でもGOM/MPC-HC/VLCで正常再生出来ました。

      警告が気になるところではありますが、–sps-idを変えた上で後者の手段で一旦凌ぎたいと思います。
      最近ずっとこのことばかり考えておりましたので、胸のつかえが取れました。
      本当に、本当にありがとうございました。

      tok

    6. だいぶ、返信が遅れたことになりますが、ちょっと説明不足でした。

      IDが異なる同士の結合は、生ストリームの状態で行うということです。

      cat a.264 b.264 > c.264

      この結合したストリームをL-SMASH muxerに喰わせます。

      muxer -i c.264 -o c.mp4

      一応、規格適合ファイルになりますし、libavformat/libavcodecの組み合わせでは特に問題なく再生できます。

      単純にIDが違うものをMP4の状態で結合しても、デコーダ初期化情報がそのまま2つに分かれたまま結合されてしまうと思います。

      ■ L-SMASH Works Muxerでエクスポート
      Aパートの最後で映像が止まり（モザイク状に壊れず、そのまま）続けてBパートの音声のみ流れ続ける

      となるのは、そういう理由です。

      MP4Boxは… 何やってるんだろうなぁ。
      ずっと触ってないからなんとも言えないですね。触る気もないけど。
      以前 試した時は、デコーダ初期化情報をフレームに埋め込むという安易な実装で、規格違反バリバリやってましたが。

      muken

    8. muken様
      ありがとうございます。
      しかしながら
      > L-SMASH Works Muxerでエクスポート
      この現象に関しましては、納得しました。
      Bパートの初期化情報が存在しない（と見られて）映像が動かないということなんですね。なるほど。。

      しかしながら生ストリームの結合に関しまして、問題が発生してしまいました。
      当方Windows環境なので

      mp4box -raw 1 a.mp4
      mp4box -raw 1 b.mp4

      の後、catコマンドを使う所を

      copy /b a.h264+b.h264 c.h264

      で代用しました。
      そしてmuxer.exeを使って

      muxer -i c.h264 c.mp4

      とすると、

      MP4 muxing mode
      Error: failed to open input file.
      Error: failed to open input files.

      と言われてしまいました。
      muxerのバージョンは
      Built on Sep 6 2013 07:04:42
      です。
      rawストリームを取り出したMP4Boxは
      MP4Box_0.4.6-r3745_x64.exe
      です。

      catコマンドとcopyコマンドの相違を確認するため手持ちのFreeBSD鯖にファイルを飛ばしてcatコマンドから結合したものを用意しましたがcopy /bで結合したものとCRC32が同じでした。

      rawデータを取り出す際のmp4boxもGPACのnightlybuild版を使ってみましたがこちらもrawデータのCRC32が同じでした。

      とするとmuxerの使い方が恐らくおかしいのだと思いますが、、申し訳ありません。自己解決できませんでした。どうすればよいでしょうか・・・

      個人的に解決してしまったこともあり、ご無沙汰しておりました。書き込んでくださったことに長らく気付かず、申し訳ございませんでした。

      tok

    10. >REIさん
      横レスですがGoogle検索で「Gregion　反転」で検索すると解決策が出てきますよ。

      tok

    11. 連投になってしまって申し訳ありません。
      muxer -i c.h264 c.mp4
      は
      muxer -i c.h264 -o c.mp4
      のタイプミスです。失礼しました。

      tok

    12. tok on様
      おっしゃるとおり現在プラグインで反転させて加工しております。

      コーデック判定でどうにかならないかと考えたため
      要望を出させていただきました。

      ありがとうございました。

      REI

    14. > ポンすけ さん

      お知らせありがとうございます。
      遅ればせながら確認しました。

      明日か明後日あたりに更新する時間がとれそうですので、少々お待ちいただけますでしょうか。

      POP

    コメントを残す

    メールアドレスが公開されることはありません。

    × 5 = 10

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