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. qaacの設定を何度か変えてみましたが同じでした。
      remuxerのバージョンはもちろんL-SMASH r728です。
      ワーニングが出たりオーディオのnameが空白になることで不具合や不便はありません、ワーニングなので気にはなりますけども。

      バグかも?
    2. > てけすた さん
      avidemuxを使わず、録画したmp4コンテナの映像をそのままL-SMASH Worksで読み込むのはいかがでしょうか。

      > バグかも? さん
      x264_L-SMASHでmuxしたのかと思っていたのですが、L-SMASHでremuxしたというのが今になってわかりました(ここはx264のページですので……)。

      L-SMASH単体の問題はL-SMASH Worksと一緒に別ページを作らねばならないかもしれません。

      本題ですが、warningの件はmuken氏がこちらを見られたのか偶然にも気づいたのか分かりませんが、現revisionでは修正されており、r732はwarningが出ないはずです(qtaacで作成したm4aではありませんが確認しました)。

      nameについては、qtaacで作成したm4aでもHandler Reference Boxのnameが保持される仕様に変更されたと思われるため、現在の挙動が正しいと私は考えています。

      どうしてもL-SMASH Audio Handlerと表示したいということであれば、生aacをL-SMASHのmuxerでmuxするのが確実ではないでしょうか。

      POP
    3. そのままmp4で取り込むと、操作は出来るのですが、再生ウィンドウで流すと重くて止まってしまうんです・・・

      てけすた
    4. __重い__とか比較無しに個人の感想を言われても知らんがな。
      そもそも私個人ではAviUtlのプレビュー再生、重いと思ってますし。
      何と比較して重いのか言ってくれないと…

      __録画した__mp4とか書いてるけど、じゃぁ、録画によって出力してないmp4はどうなのかとかさ。
      オプションは弄ったのか?とかさ。

      ここでエスパーしてみるわー。
      Libav+L-SMASHのチェックを外して、Apply
      repeat flagをチェック。

    5. > POP さん
      L-SMASH r732のremuxerだとあのワーニングは出なくなりました。ありがとうございました。

      バグかも?
    6. 何やら起きているようです。
      ttp://x264.nl/
      ttp://doom10.org/index.php?PHPSESSID=vv96kk9f8l9ahcdgved0rmcud6&topic=2565.0

      匿名希望
    7. 当人の性格や思想、事の経緯をまったく知らないので何とも言えませんが、人が集まればどうしてもね。
      行きすぎた発言が度々あったとのことですが……。

      POP
    8. r2245以降のx264_L-SMASHでアスペクト比を指定して作った動画が、PS3で破損ファイルと表示されるのは仕様なんでしょうか?

      x264_L-SMASH r2245以降でもアスペクト比を指定しなければ再生できます。(AviutlのGuiEXでアスペクト比0を指定。テストファイルの都合?でx264_L-SMASH単体ではsar 0/0にできず未テスト。)

      x264_GPACならr2334でも再生可。
      x264_GPACでエンコードしてL-SMASH(r747)/Mp4Boxでmuxも再生可。
      x264_L-SMASH (r2334)でエンコードしてL-SMASH(r747/rigaya氏r745)/Mp4Boxを使ってmuxしても再生不可。(これらの組み合わせはGuiEX使用)

      テストしたファイルは720×480で↓な感じのパッチでもテストしました。

      x264.r2245_win64.exe –demuxer ffms –crf 20 –sar 32/27 –tff -o test(2245_L-SMASH).mp4 xv.avi

      x264.r2230_win64.exe –demuxer ffms –crf 20 –sar 32/27 –tff -o test(2230_L-SMASH).mp4 xv.avi

      x264.r2334_win64g.exe –demuxer ffms –crf 20 –sar 32/27 –tff -o test(2334_GPAC).mp4 xv.avi

      sar 1/1も試してみましたが、破損ファイルと表示され再生できませんでした。
      なお、私はHDファイルを持ってないので、HDファイルでは確認していません。

      5673@name
    9. > 5673@name さん

      当方、PS3を所持しておらず再現確認はできないのですが、やはり 1280×720 のプログレッシブ映像で –sar 1/1 指定をお試しいただいたり、–level 4.0 指定、 –nal-hrd vbr –bframes 3 –b-pyramid none といったPS3で怪しそうな部分をきっちり指定したうえでどうなるのか知りたいところではありますね。

      あと、x264でmp4コンテナに格納せず、Rawストリームで出力したものを L-SMASH でmuxした場合はどうなるのかもお試しいただければと思います。

      POP
    10. 了解しました。一応GuiEXのPS3オプションをいじくってアスペクト比らしいと見当を付けたのですが、HD動画(作ればよかったのか・・)と合わせて、もう一度実験してみます。

      5673@name
    11. 使ったスクリプトは↓な感じで、解像度が1280×720、856×480、720×480、640×480なファイルを用意して–sarを0/0、1/1、32/27、sarの記述無しにしてみて実験してみました。

      x264.r2334_win64.exe –demuxer ffms –crf 20 –sar 1/1 –level 4.0 –nal-hrd vbr –vbv-maxrate 12000 –vbv-bufsize 12000 –aud –bframes 3 -r 3 –b-pyramid none -o test(r2334_hSD).mp4 hSD-p.avi

      x264.r2334_win64.exe –demuxer ffms –crf 20 –sar 1/1 –level 4.0 –nal-hrd vbr –vbv-maxrate 12000 –vbv-bufsize 12000 –aud –bframes 3 -r 3 –b-pyramid none -o test(r2334_HD-raw).264 HD-p.avi
      muxer.exe -i test(r2334_HD-raw).264 -o test(r2334_HD-raw).mp4

      結果は、rawで出力してL-SMASHでmuxしたファイルは全て再生でき、x264_L-SMASHでMP4にしたものは全て破損ファイルと表示されました。(Levelやaudに関係なく)

      念のため、もう一度x264_LSMASH+L-SMASHを設定したGuiEX(PS3プロファイル使用)でテストすると、アスペクト比0:0を指定したものは再生できますが、アスペクト比を入力した物は破損ファイルと表示されました。(アスペクト比が原因ではないかと思った理由です)

      5673@name
    12. コメント欄をどんどん消費してますが、GuiEXのPS3プロファイルはこんな感じです。

      –qcomp 0.7 –vbv-bufsize 25000 –vbv-maxrate 25000 –keyint -1 –min-keyint 4 –b-pyramid none –ref 3 –weightp 0 –no-fast-pskip –no-dct-decimate –level 4.1 –nal-hrd vbr

      5673@name
    13. > 5673@name さん

      チェックありがとうございます。

      ご報告いただいた内容から、ひとつ気付いた点として ffms(またはlavf)入力において取得したアスペクト比またはフレームレートが適切な値でない場合+x264でアスペクト比指定をした場合、それがx264に渡るとedts他に通常とは異なる値が入るケースが確認されました(aviをffms入力している点が気にかかったもので)。

      これが原因とは断定できませんが、x264_L-SMASH のオプションスイッチで –fps を指定のうえお試しいただけないでしょうか。

      23.976fpsであれば –fps 24000/1001
      29.97fpsであれば –fps 30000/1001
      といった具合です。

      度々お手数をかけますが、よろしくお願いします。

      POP
    14. –fps 30000/1001 は、どこに付けたらいいんでしょうか?
      –demuxer ffmsの後ろ、○○.mp4 の後ろ、x264のコマンドライン中などなど、手当たりしだいに付けてみましたがダメでした。(エンコードログの中では”ffms [info]: 1280x720p 1:1 @ 30000/1001 fps (cfr)”と表示)この状態でsar有り/無しでやってみましたが結果は変わらず。

      ついでにy4mでもエンコードしたところ、sar無しならば再生できました。

      5673@name
    15. boxdumperなりでrev2230以前とrev2245以降の構造の比較してみないことには原因の究明は難しいよ。

      私自身もPS3持ってないから検証のしようが無い状態。

      https://github.com/silverfilain/x264_L-SMASH/commits/lsmash
      ・ Fix possible issues with out-of-spec QP values
      から
      ・ Merge up to “description: Fix memory leak when appending ESDescriptor…
      までの間のL-SMASHまたはx264_L-SMASH側の変更で、sample descriptionのextensionの並び順とか変わったりしているので、そこが影響しているかもという予想はあるが、予想の域を出ていない。

      https://github.com/silverfilain/x264_L-SMASH/commit/4e7458bc02097aebd3621233b13c4892994d1aec

      muken
    16. うーん。
      paspと他のboxとの位置関係でアウトになってるのかなぁ。

      とりあえず、コンテナ側にpaspを書き込まない方法として、
      –no-container-sar
      を提供しているので、試してみてください。

      規格書ではpaspの位置は現在の実装のとおりであるのが最大限の互換性においてbetterとのことなので、これが原因でPS3が破損ファイル扱いするのであれば、Blame Sonyってことになります。
      あー、でもsample descriptionsのextensionの読み込みサイズにPS3側で制限がある、とかもありうるなー…

      muken
    17. –no-container-sarを指定したところ再生できました。
      と、いうことはPS3の問題みたいですね。。

      muken氏&POP氏
      お手数おかけしました。
      ありがとうございました。

      5673@name

    コメントを残す

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

    + 52 = 57

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