個人的な動画をaviutlで編集していたら!!
どうしても音がずれる動画が現れました。
色々調べるとVFR(可変フレームレート)が原因のようです。
それまでは奇跡的に?フレームレートが安定していてそこまで気にならないレベルだったようです。
なので過去の動画もよく見るとたぶん音がずれているんだろうか…
怖くて確認していないです(笑)
対策法方は調べたらたくさん出てきました。
私が行き着いた方法をメモ代わりに書いていきます。
まずVFR(可変フレームレート)をCFR(固定フレームレート)変換する事で音ズレが回避できるようです。
HandBrakeというソフトを使う方法がたくさん出てきました。
とりあえず使ってみる。
デフォルト設定だとコーデックがh.264(x264)と表示されるのでソフトエンコードのようです。
フレームレートの設定をCFRにして、fpsは30か60か自分の求めるものに設定。
品質設定があるのでRF クオリティのバーを動かして0にします。
音声の部分は160kbpになっていますが、192kbps以上に私は設定しました。
そして変換をスタートするとCPUの負荷が100%になり…
約42秒ほどの動画で約31秒程度かかります。
短いからいいですけど、長い動画だったら…
元データがビットレート19.5 Mb/s、容量99.6MBだったものが
ビットレート19.7 Mb/s、容量101MBになりました。
次にコーデックをh.264(Nvidia NVEnc)に変えます。
品質設定のバーを0にすると莫大な容量になったので、
私は20~22で元の動画のビットレートと前後するくらいにしました。
始めるとCPU100%とGPU40~50%?と負荷がかかります。
今度は約42秒ほどの動画で約12秒で終わりました。約半分の時間です。
元データビットレート19.5 Mb/s、容量99.6MBだったものが
ビットレート19.3 Mb/s、容量99.4MBになりました。
オリジナルにかなり近い感じになりますね。
というわけで、HandBrakeを使ったVFRをCFRに変換検証した結果でした。
で、です。
ffmpengでやったらどうなるんだろう?と思ったわけです。
for %%a in (%*) do (
ffmpeg -i %%a -r 60 -vsync cfr -af aresample=async=1 -b:a 320k -vcodec nvenc_h264 -vb 22M -bsf:v h264_metadata=colour_primaries=1:transfer_characteristics=1:matrix_coefficients=1 "%%a_cfr.mp4"
)
2022/06/17修正
for %%a in (%*) do (
ffmpeg -i %%a -r 60 -vsync cfr -af aresample=async=1 -b:a 320k -vcodec h264_nvenc -vb 22M -bsf:v h264_metadata=colour_primaries=1:transfer_characteristics=1:matrix_coefficients=1 "%%a_cfr.mp4"
)
私はめんどくさがりなので、まずバッチファイルを作りました。
重要なのはここですね。
ffmpeg -i "変換したいファイル名"-r 60 -vsync cfr -af aresample=async=1 -b:a 320k -vcodec nvenc_h264 -vb 22M -bsf:v h264_metadata=colour_primaries=1:transfer_characteristics=1:matrix_coefficients=1 "変換後のファイル名.mp4"
2022/06/17修正
ffmpeg -i "変換したいファイル名"-r 60 -vsync cfr -af aresample=async=1 -b:a 320k -vcodec h264_nvenc -vb 22M -bsf:v h264_metadata=colour_primaries=1:transfer_characteristics=1:matrix_coefficients=1 "変換後のファイル名.mp4"
あまり詳しくないので使い方を見ながら自分がやりたい部分を書き足していき動いたから使っているので、
きっと詳しい方が見たら酷い物なのでしょう…
まあ動けばいいのですよ(おい)
2022/06/17修正
雑に説明すると
ffmpengさんに
-i "変換したいファイル名"これが元データだよ。
-r 60 フレームレートを60に固定してね。
-vsync cfr フレームレートを固定にしてね。
-af aresample=async=1 音ズレしないように最初だけ合わせたら、後は雰囲気で任せた!(こんな感じ)
-b:a 320k 音声のビットレートは320kbpsにしてね。
-vcodec nvenc_h264 コーデックはNVEncでH.264でやってね。
-vcodec h264_nvenc コーデックはNVEncでH.264でやってね。
-vb 22M ビットレートは22Mbpsで頼むよ。
-bsf:v h264_metadata=colour_primaries=1:transfer_characteristics=1:matrix_coefficients=1
↑Color primaries BT.709 Transfer characteristics BT.709 Matrix coefficients BT.709 にしてちょ。
"変換後のファイル名.mp4" この名前で保存してね。
ざっくりするとこんな感じですかね。
-bsf:vあたりよくわかってないけど、BT.709にしたかった。
この設定でffmpegでVFRからCFRに変換すると…
約42秒ほどの動画で約7秒で終わりました。更に半分になりました。
CPUの負荷は50~60%程度でGPUの負荷が80%前後とGPUを効率よく?使ってる印象です。
元データビットレート19.5 Mb/s、容量99.6MBだったものが
ビットレート20.8 Mb/s、容量106MBになりました。
というわけで、私はffmpegでVFRをCFRに変換するのに落ち着きそうです。
ざっくりまとめると?
HandBrakeのx264を使うと元動画の約75%の時間で終わる。
HandBrakeのNVEncを使うと元動画の約30%の時間で終わる。
ffmpegのNVencを使うと元動画の約20%の時間で終わる。
仮に1時間の動画に置き換えると上から
45分
18分
12分
になりますね。(かなりの誤差があると思われます)
10年以上aviutlを使っていますが…
有料の動画編集ソフトって使ったことないけど、どうなんでしょうね?
追記2020/10/30
https://ameblo.jp/delta920/entry-12620831486.html
追記2021/02/28
再び悩まされました。
追記2022/06/17
久しぶりにこちらのコマンドを使ったところエラーが発生しました。
原因を調べたところ、内部エンコーダーの名前が変更になっていたようです。
旧コマンド nvenc_h264
新コマンド h264_nvenc
上記のように変更されていたようです。
これはffmpegではなくnvenc側の変更のようです。
いつから変わっていたのか知らないけど、こういうこともあるんですね。
興味深いです。
ということで、追記終わり。