x264vfw GUI専用スレ Part9
アマレコTVスレでテストしてたら、x264vfwで気になる点（バグ？）を見つけたので報告。
bm(masternobody)版を可逆で使ってる人は、実は可逆になってないので注意する必要があると思う。
■環境：Win8.1(64ビット)、i7-4702MQ 2.20GHz メモリ8GB
■テスト対象： bm版(x264vfw_38_2274bm_36885)、kMod版(x264vfw.2273kMod.x86）
■テストツール：vctest v2.1.0 x86
■テストソース：以前Yahooにあった秒速5cmのPVをYV12にしたもの。（YV12.avi）
1280x720 24fps 1092フレーム。サイズ1.87 GB (2,012,804,712 バイト)
■テスト方法： vctest-x86_2_1_0.exe -q -c YV12.avi ※-cオプションは可逆性チェック時のみ
■現象：
bm版で「Single-pass lossless」を選んで可逆圧縮する場合、
コマンドラインオプション欄で「--sliced-threads」を指定しないと可逆にならない。
また、「--sliced-threads」を指定せずにvctestを行うと、エンコードfpsが本来の10倍くらいの値になる。
■vctest結果例：
●x264vfw_38_2274bm_36885： 「Keep input colorspace」 「Single pass - lossless」「--sliced-threadsあり」 ※可逆になる
→エンコード55fps、デコード89fps、圧縮率6.709%
●x264vfw_38_2274bm_36885： 「Keep input colorspace」 「Single pass - lossless」「--sliced-threads無し」 ※可逆にならない
→エンコード823fps、デコード78fps、圧縮率6.641%
■備考：
・RGB、YU4:4:4、YUV4:2:2でも、同様に「--sliced-threads」を指定しないと可逆にならない。
・bm版では、crf=23などでも、--sliced-threadsが無いとvctestでのエンコードfpsが10倍くらいになり怪しい。
常時--sliced-threadsを指定したほうがよい？
・１つ前のバージョンであるx264vfw_37_2200bm_33968でも同様の問題が発生した。
・kMod版では--sliced-threadsをつける必要はない。
・今のところ目立つような破綻は確認できていない。
bm(masternobody)版を可逆で使ってる人は、実は可逆になってないので注意する必要があると思う。
■環境：Win8.1(64ビット)、i7-4702MQ 2.20GHz メモリ8GB
■テスト対象： bm版(x264vfw_38_2274bm_36885)、kMod版(x264vfw.2273kMod.x86）
■テストツール：vctest v2.1.0 x86
■テストソース：以前Yahooにあった秒速5cmのPVをYV12にしたもの。（YV12.avi）
1280x720 24fps 1092フレーム。サイズ1.87 GB (2,012,804,712 バイト)
■テスト方法： vctest-x86_2_1_0.exe -q -c YV12.avi ※-cオプションは可逆性チェック時のみ
■現象：
bm版で「Single-pass lossless」を選んで可逆圧縮する場合、
コマンドラインオプション欄で「--sliced-threads」を指定しないと可逆にならない。
また、「--sliced-threads」を指定せずにvctestを行うと、エンコードfpsが本来の10倍くらいの値になる。
■vctest結果例：
●x264vfw_38_2274bm_36885： 「Keep input colorspace」 「Single pass - lossless」「--sliced-threadsあり」 ※可逆になる
→エンコード55fps、デコード89fps、圧縮率6.709%
●x264vfw_38_2274bm_36885： 「Keep input colorspace」 「Single pass - lossless」「--sliced-threads無し」 ※可逆にならない
→エンコード823fps、デコード78fps、圧縮率6.641%
■備考：
・RGB、YU4:4:4、YUV4:2:2でも、同様に「--sliced-threads」を指定しないと可逆にならない。
・bm版では、crf=23などでも、--sliced-threadsが無いとvctestでのエンコードfpsが10倍くらいになり怪しい。
常時--sliced-threadsを指定したほうがよい？
・１つ前のバージョンであるx264vfw_37_2200bm_33968でも同様の問題が発生した。
・kMod版では--sliced-threadsをつける必要はない。
・今のところ目立つような破綻は確認できていない。
|
|
|
調査ついでに、x264vfwのbm(masternobody)版とkMod(komisar)版の違いを軽くまとめてみた。
個人的には色々な色空間での可逆が使えるという点を重視して、
とりあえずbm版を常時「--sliced-threads」つけて使ってみようと思うけど大丈夫だろうか？
■bm(masternobody)版（x264vfw_38_2274bm_36885時点）
・設定画面で設定できる項目が少ない。（設定画面でのコマンドラインオプション指定は可）
・入力色空間を保持してエンコできる。RGB、YUV4:4:4、YUV4:2:2、YUV4:2:0での保存が可能。（可逆も。）
・ただし--output-cspはサポートしていない。内部での色変換は選択肢から選べる「Convert to YUV4:2:0」のみ。
・デフォルト設定（kMod版と差がある部分をある程度抜粋）
me=hex、qpmin=0、qpmax=69、sliced-threads=0、bframes=3、b_pyramid=2、mbtree=1
★コマンドラインオプションで「--sliced-threads」をつけないと可逆にならないうえ、
vctestでのエンコードfpsが10倍くらいになる。何らかのバグ？
■kMod(komisar)版（x264vfw.2273kMod.x86時点）
・設定画面で設定できる項目が多い。（設定画面でのコマンドラインオプション指定も可）
・出力色空間は420固定になっている。RGB、YUV4:4:4、YUV4:2:2、YUV4:2:0が入力できるが保存はYUV4:2:0になる。（可逆も。）
・--output-cspもサポートしていない。
・デフォルト設定（bm版と差がある部分をある程度抜粋）
me=umh、qpmin=10、qpmax=51、sliced-threads=1、bframes=0、、mbtree=0、fade_compensate=0.00
・コマンドで「--sliced-threads 0」をつけると可逆にならないので注意。
個人的には色々な色空間での可逆が使えるという点を重視して、
とりあえずbm版を常時「--sliced-threads」つけて使ってみようと思うけど大丈夫だろうか？
■bm(masternobody)版（x264vfw_38_2274bm_36885時点）
・設定画面で設定できる項目が少ない。（設定画面でのコマンドラインオプション指定は可）
・入力色空間を保持してエンコできる。RGB、YUV4:4:4、YUV4:2:2、YUV4:2:0での保存が可能。（可逆も。）
・ただし--output-cspはサポートしていない。内部での色変換は選択肢から選べる「Convert to YUV4:2:0」のみ。
・デフォルト設定（kMod版と差がある部分をある程度抜粋）
me=hex、qpmin=0、qpmax=69、sliced-threads=0、bframes=3、b_pyramid=2、mbtree=1
★コマンドラインオプションで「--sliced-threads」をつけないと可逆にならないうえ、
vctestでのエンコードfpsが10倍くらいになる。何らかのバグ？
■kMod(komisar)版（x264vfw.2273kMod.x86時点）
・設定画面で設定できる項目が多い。（設定画面でのコマンドラインオプション指定も可）
・出力色空間は420固定になっている。RGB、YUV4:4:4、YUV4:2:2、YUV4:2:0が入力できるが保存はYUV4:2:0になる。（可逆も。）
・--output-cspもサポートしていない。
・デフォルト設定（bm版と差がある部分をある程度抜粋）
me=umh、qpmin=10、qpmax=51、sliced-threads=1、bframes=0、、mbtree=0、fade_compensate=0.00
・コマンドで「--sliced-threads 0」をつけると可逆にならないので注意。