内蔵AACエンコーダは、まだ実験段階のため、以前使用していたlibfaacや、neroAacEncに比べると音質は良くないです。
まともに動作するようになるまでは、neroAacEncを使用した音声AAC動画の作成方法を、こちらの記事に書きましたので、参考にしてください。
また、x264について、一番多く質問が寄せられるエラーの説明を記事にしましたので、思い当たる方は、ぜひご一読ください。
x264のエンコードでエラー（Error while opening encoder for output stream #0.0）
ffmpeg_bin-42106.zip
ffmpeg_bin_pentium4-42106.zip (Pentium4最適化版)
ffmpeg_bin_core2-42106.zip (Core2最適化版)
ffmpeg_bin_athlon64-42106.zip (Athlon64最適化版)
ffmpeg_bin_phenom-42106.zip (Phenom最適化版)
以下のライブラリをアップデートしました。
nasm-2.10.01
polarssl-1.1.4
libvpx-v1.1.0-122-gacd147c
freetype-2.4.10
fontconfig-2.9.92
今回より、gcc-4.7.1とmingw-w64-v1.0.4の組み合わせで、全部コンパイルし直しています。
バイナリはどれを使っても大丈夫だと思いますが、SSE2に対応していないCPU(Duron、Sempronの一部、Pentium3など)をお使いの方は、最適化無し版を使ってみてください。
最適化無し版でもエラーが出る場合は、サポート外とします。
zipファイルを解凍すると、ffmpeg.exeが出てきますので、携帯動画変換君のcoresフォルダに置くなり、単体で使うなりしてください。
携帯動画変換君のffmpeg.exeとは、オプションの互換性がありませんので、上書きする際はご注意ください。
FFmpegのコンパイルは、以下の記事を参考にしてください。
FFmpegのコンパイル (2011/07/31) w32threads
コンパイル環境：MinGW gcc-4.7.1
binutils-2.22
mingw-w64-v1.0.4 (sezero_20111101-w32-update-rev.5151)
各ライブラリのバージョンは、以下の通りです。
nasm-2.10.01
yasm-1.2.0
zlib-1.2.7
bzip2-1.0.6
libbluray-0.2.2
libcdio-0.90git-8ed1004
gsm-1.0.13
libmodplug-0.8.8.4
lame-3.99.5
opencore-amr-0.1.3
vo-aacenc-0.1.2
vo-amrwbenc-0.1.2
polarssl-1.1.4
rtmpdump-2.4-20120309 PolarSSL版
libogg-1.3.0
aoTuV Beta6.03 (libvorbis-1.3.3パッチ)
libtheora-1.1.1
speex-1.2rc1
libvpx-v1.1.0-122-gacd147c
x264 rev.2200 (make fprofiled)
xvidcore-1.3.2
libiconv-1.13.1
freetype-2.4.10
expat-2.1.0
fontconfig-2.9.92
fribidi-0.19.2
libass-0.10.0
最適化オプションは、以下のようにしています。
最適化無し版
--extra-cflags="-march=i686 -mtune=generic"
Pentium4最適化版
--extra-cflags="-mtune=pentium4 -mfpmath=sse -msse" --cpu=pentium4
Core2最適化版
--extra-cflags="-mtune=core2 -mfpmath=sse -msse" --cpu=i686
Athlon64最適化版
--extra-cflags="-mtune=athlon64 -mfpmath=sse -msse" --cpu=i686
Phenom最適化版
--extra-cflags="-mtune=amdfam10 -mfpmath=sse -msse" --cpu=i686
configureオプションは以下の通りです。
$ ./configure --enable-gpl --enable-version3 --enable-avisynth --enable-fontconfig --enable-libass --enable-libbluray --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libcdio --enable-libfreetype --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-librtmp --enable-libspeex --enable-libvorbis --enable-libtheora --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvpx --enable-libx264 --enable-libxvid --disable-ffplay --disable-ffprobe --disable-ffserver --enable-w32threads --extra-ldflags=-static --extra-cflags="-mtune=athlon64 -mfpmath=sse -msse" --cpu=i686 --optflags="-O2 -finline-functions"
※--extra-cflagsは、最適化の種類により異なります。
ありがとうございました。
コメントありがとうございます。
探すのに苦労しましたが、これのことでしょうか。
https://github.com/mstorsjo/fdk-aac
面白そうですが、ライセンス的にはどうなんでしょう？
Fraunhoferなどと書かれていますね。
本家でも採用されたら試してみます。
コメントありがとうございます。
-padとか-cropは、だいぶ前に-vfオプションに統合されて、単体のオプションはなくなりました。
padやcropについて、以前書いた記事がありますので、サイドバーの検索ボックスから「crop」で検索してみてください。
42106に置き換えたところエンコード失敗するようになってしまいました。
DVDからリッピングしたVOBファイルを以下のようなコマンドでiPod用のMP4ファイルにエンコードしています。
※メッセージに従い、41062まで-profileだった部分を、42106で-profile:vに変更しています。
ffmpeg.exe -y -i "ABC.vob" -pass 1 -passlogfile "FFmpeg-Log" -vcodec libx264 -fpre libx264-default.ffpreset -preset placebo -tune film -profile:v baseline -level 30 -coder 0 -sws_flags lanczos -s 640x360 -vf "pad=640:480:0:60:black, setdar=4:3" -b:v 2400k -minrate 2300k -maxrate 2500k -bt 1200k -bufsize 5120k -qmin 2 -qmax 51 -flags +bitexact -mbtree 1 -g 30 -sc_threshold 50 -mbd 2 -me_method umh -me_range 32 -refs 3 -partitions pi4x4,pp4x4,pp8x8 -an "XYZ.mp4"
41062ではエンコードできますが、42106ではエンコードに失敗してしまいます。
以下はその際のメッセージです。
Guessed Channel Layout for Input Stream #0.1 : stereo
Input #0, mpeg, from 'ABC.vob':
Duration: 00:04:19.86, start: 1.036644, bitrate: 9517 kb/s
Stream #0:0[0x1e0]: Video: mpeg2video (Main), yuv420p, 720x480 [SAR 32:27 DAR 16:9], 9800 kb/s, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
Stream #0:1[0xa0]: Audio: pcm_s16be, 48000 Hz, stereo, s16, 1536 kb/s
[graph 0 input from stream 0:0 @ 02455B00] w:720 h:480 pixfmt:yuv420p tb:1/90000 fr:30000/1001 sar:32/27 sws_param:flags=2
[output stream 0:0 @ 02672F20] No opaque field provided
[Parsed_pad_0 @ 02469860] Input area 0:60:720:540 not within the padded area 0:0:640:480 or zero-sized
[graph 0 input from stream 0:0 @ 02455B00] Failed to configure input pad on Parsed_pad_0
Error opening filters!
＞Input area 0:60:720:540 not within the padded area 0:0:640:480 or zero-sized
というエラーを調べてみると、パディング前のサイズがパディング後のサイズより大きい場合に発生するエラーのようなので、「-s 640x360」が正しく機能していないか、以前と動作が変わったのではないかと思っています。
このエラーへの対処法が分かれば教えていただけないでしょうか？
コメントありがとうございます
-sオプションと-vfオプションの組み合わせは、試していなかったので、気が付きませんでした。
何か変わってしまったのかもしれませんね。
「-s 640x360」を削除して、代わりに、-vfにscaleオプションを追加してみてください。
-vf "scale=640:360, pad=640:480:0:60:black, setdar=4:3"
これで、たぶん大丈夫だと思います。
アドバイスありがとうございます。scaleオプションを使用することで希望通りの結果を得られました。
ソース動画の最初からエンコードして(-ss 0 -t 30)して fade=out:ほげ とした場合は良いのですが、途中からエンコード(-ss 20 -t 30)などにすると途中でフェードアウトしてしまいます。
以前は実際にエンコードされるフレーム数(-t の秒数*フレームレート)だったものが、元動画の最初から数えた( -ss + -t にフレーム数を掛ける)フレーム数を指定しないといけないようになりました。
今後はずっとこの仕様ってことになりますかね？
私は開発に携わっているわけでもありませんし、すべての機能を確認しているわけでもありませんので、変わってしまったんでしょうね。
今後、仕様が変わらないかどうかも分かりません。
利用する側で、仕様に合わせて変更するか、以前のものを使い続けるかしかないと思います。
しばらく様子をみて、変更されないか注意します。
変わらないならバージョンをあげてみたいと思います。
7/15にもパッチ更新されていたんですね。
それを適用してfdk_aac込のffmpegビルド出来ました。
fdk_aac本体は以下の場所から、
http://sourceforge.net/projects/opencore-amr/files/fdk-aac/
fdk-aac-0.1.0.tar.gz
をDLしてビルドしました。
設定上の数値は下げることは出来るんですが、
実際でているビットレートには下限がありますね。
AAC_LC(-profile:a aac_low)で、64kbpsが下限
HE-AAC v1(-profile:a aac_he)で、28kbpsが下限
HE-AAC v2(-profile:a aac_he_v2)も、28kbpsが下限
同一ビットレート(64kbps)のlibfaacと比較すると、
かなりの高音質で聞けました。
HE-AAC v1 に関しては、libaacplusよりも、
さらに低いビットレートで使えるのも良いですね。
上記は、44.1kHz ステレオでの設定の場合です。
モノラルだと多分その半分になるでしょうし、
サンプリングレートでも変わるかもです。
情報ありがとうございます。
fdk-aacは、ビルドできるのを確認しただけで、エンコードはしていなかったのですが、libfaacより高音質なんですね。
試していないので分かりませんが、ビットーレートの下限があるということは、上限もあるのでしょうか？
libfaacの代わりになるかと期待していたのですが、fdk-aacも、ライセンスがらみで、バイナリは再配布できないようです。
残念！
時間がある時に、他のエンコーダーなどとも聞き比べてみます。
上限側のほうはまだ完全にサーチしてはいませんが、
おそらく上限もあるものと思われます。
チャンネルやサンプリングレートの組み合わせで、
結構変わってくるかもしれません。
添付のPDFはありますが、実際どうなのかは測定で。
映像カットした状態のFFmpegのビットレート表記や、
リソースモニタでのffmpeg.exeのプロセス指定での、
通信量をバイト/sからビット/sに換算で測定で、
そこまで正確ではないけどほぼ把握できるかと。
-x264opts "no-asm"以外に、SSE4.1やCache64などを意図的に使わせない方法がありますか？
(経緯)
iriver S100でmp4で見るためImageMagikソースに同梱されているffmpegを使っていましたが、2年ほど前のものなので、最新版を使いたいなぁと探しているときにpentium4-38811版を見つけ、これを使っていました。
移ってからでS100で見てると、稀に画面が止まるようになって、ずっと気になっていました。PCで見ると、その部分で止まったりしないのになぁと思いながら・・・。
時間が出来たのでセマフォのツール作って、同時に4個のidleプライオリティのffmpegが実行できるようにして、約10秒のtsを1.mp4～500.mp4にエンコードし、できたmp4バイナリをMD5でチェックしてみると、数個違うものができていました。
PCでそれらを再生してみると、ブロックノイズが盛大に出てたり、ぱっと見ではわからない程度のブロックノイズがあったりと、それぞれのmp4の壊れ方はさまざまでした。
pentium4-38811版より遅いので使ってなかったcore2-38811版で試してみても、やはり数個壊れるていました。最新のpentium4-42106版を使ってみましたが、やはり数個壊れました。残念。
ffmpegのオプションをひーこらいいながら新形式にした関係で、あまり古いのは使えないため、使えそうで一番古いpentium4-37402版で試してみましたが、やはり数個壊れてました。
音声のaacには問題がなく映像のlibx264が壊れるので、スレッドの競合かSSE4.1とかの最適化部分が問題だろうなぁと思い、まずは怪しそうな最適化部分を切っていきたいと思ったけど、-x264opts "no-asm"しかなさそう。pentium4-42106版で-x264opts "no-asm"をつけてやってみると、処理速度がガタ落ちしたかわりに、すべてのmp4のMD5は一致しました。
ということで、スレッドは無罪、libx264のどこかの最適化asm処理に問題があるっぽい。
ソースに添付されているaacEncoder.pdfには、
44100Hz、2chanで、
AAC-LC BR min 5900bps BR max 529152bps
HE-AAC BR min 16000bps BR max 128000bps
HE-AACv2 BR min 8000bps BR max 64000bps
と書いてありますが、下限は少し高めに制限されているんですね。
試しに、-ab 1000k とビットーレートを大きめに設定してエンコードしたものを、VLCで再生してメディア情報を見たら、HE-AACは127kbps位、HE-AACv2は63kbps位でした。
上限は規格どおりになっているようです。
そんな不具合があるとは知りませんでした。
他にも困っている人がいるのかもしれませんね。
no-asmなどのオプションは設定したことが無かったので、調べてみたら、asmというオプションがありました。
libx264のエンコードの時、
using cpu capabilities:
という所に表示されているもののうち、有効にしたいものだけ指定すれば、それ以外は無効にできるようです。
-x264opts asm=MMX2,SSE3,FastShuffle
など、コンマで区切って列挙します。
自動判定でSSE4.1となっていたら、SSE3か、SSSE3などを指定すれば、SSE4.1が無効になると思います。
指定できる値は、ソースコードcommon/cpu.cの48行目辺りからを参照してみてください。
http://git.videolan.org/gitweb.cgi?p=x264.git;a=blob;f=common/cpu.c;h=fa57407be09749dc48955c916a5700f8f9ae74b2;hb=HEAD
ありがとうございます。
テストしてみたところ、-x264opts "asm=MMX2"だけでも、いくつか壊れました。
SSE2とか指定すると自動的にMMX2が有効化されてしまうので、どうしようもないです。
ImageMagicのソースに同梱のffmpegではMMXやSSE、-threads多めでも問題なかったのでconfigureオプションを比べてみると、影響ありそうなのが--enable-pthreadsと--enable-w32threadsの違い、ImageMagicのソースに同梱するffmpegのみにある--enable-memalign-hack、ぐらいかなぁ。
win32環境のpthreadsは、内部でw32threadsを呼び出しているだけなので、--enable-w32threadsでダメなら--enable-pthreadsでもダメなのではないかと思います。
以前は、--enable-memalign-hackオプションを付けていたのですが、今は付けなくても自動で有効になっています。
あと何か試すとすれば、アンチウイルスソフトを止めてみるなど、動画のエンコード以外のソフトを動作させないとか、保存先を変えてみるとか。
もしかして、他の人で、動画が壊れていても気づいていないとうこともあるのかもしれませんね。
こっちの方が普段使っているWin xp SP3(Core2 Quad)より速いので色々試してみました。
私が指定しているx264のオプションのどれかが悪さしているのかと思い、できるだけ少なくしてみました。
ffmpeg.exe -y -i "..\test.ts" -threads 0 -ac 2 -ab 112k -ar 48000 -cutoff 17k -vcodec libx264 -acodec aac -strict experimental -profile:v baseline -level:v 1.3 "%%i.mp4"
を4つ同時(%%iはfor /lでカウントアップ)実行するだけで2/500個のmp4が壊れていました。
-r 29.97をつけると、数十/500個も壊れました。
壊れた部分はVLCやGOM PLAYERなどでは止まることなく再生できるので、盛大にブロックノイズが出たりしない限り、壊れたと気づかないと思います。
オプションが少なくても壊れる、-r 29.97をつけると、より壊れやすくなることがわかったので、携帯機で見るのに使っているオプションを使って320x180にリサイズやyadif=0でデインターレースや-r 29.97などのオプションにつけた状態でやってみると、
-r 29.97をつけてない場合は0/500～1/1000ぐらいの確率で壊れ、-r 29.97をつけると22/50も壊れました。
-r 29.97 -anで音声なしにしてみても、10/500個が壊れました。-anなしに比べると壊れは約半分になりました。
-threads 0を-threads 1にしてみると、-r 29.97の有無にかからわず、全く壊れませんでした。
16個のffmpeg.exeプロセスを同時実行させるようにしても、32個のffmpeg.exeプロセスを同時実行させても全く壊れませんでした。
あべちんさんのバイナリ以外でも試されましたか？
http://ffmpeg.zeranoe.com/builds/
こんな所のバイナリだとか...
色んなバイナリでも同じ症状であれば、x264-dev,ffmpeg-dev等に報告すると良いかもしれません。
これを使わなかったのは、あまりにも遅すぎたためです。
ここのと比較のため、これでのテストもやりましたが、1時間ほどで100個ぐらいしかできないほど遅いので中断。しかしそこまででできていたものは壊れていませんでした。
3ヶ月も経ってるから遅すぎる状態が解消しているかもしれませんね。
Latestのffmpeg-20120726-git-236ecc3-win32-static.7zでテストしてみます。
4つ異なりましたが、差異のあったファイルは、S100でも止まったり、ノイズが出たりすることはなかったように見えました。
9フレームや1フレームしか違わなかったので、これはスレッド利用による処理差しかなかったと思われます。
S100で止まったり映像の乱れに気づくのは、1時間あたり1回もない程度(最近1時間に3回気づくのが出来たけど)で、もう一度エンコードしなおしてみるとその部分は正常に再生できたり、動きの非常に少ないところで発生したりと、-threads 0や-threads 2以上に不安があります。
やはり予想通り動作は普通に軽かったです。
これなら何度か試せると思ってやってみると、ストレス1回目で何個か差異があり、Win7x64添付のWindows Media Playerで見てみると、ブロックノイズが出るものがあったので、S100で見ずとも壊れています。
つまり-threads 1以外かつMMX2以上のasm利用状態ではオリジナルでも壊れるということがわかりました。
どうしようもないですね。
結果、差異はいくつかありました。差異のあったファイルをWindows Media Playerで見てみると、ブロックノイズを確認できたので、Win32版と同じように不定期に壊れるようです。
コメントありがとうございます。
なるほど、他の方がビルドしたバイナリでも試すというのは、気が付きませんでした。
ろーみんさんのご報告では、ビルド環境などの問題ではなさそうですね。
詳しいご報告、ありがとうございます。
動画が壊れていても気が付かない程度なので、バグとして認識されていないということなのでしょうかね。
動画が壊れる時の規則性が分かればいいのですが、なかなか難しそうです。