2019年1月26日リサイズの説明を追記した。PM色々と参考にさせていただいております。ありがとうございます。最近libvmafを試していたので、いくつかコメントします。間違いなどあったらすみません。●以下の自動ビルドスクリプトでlibvmafを有効にしたWindows用のffmpegバイナリがビルドできました。他はdisableにしたり消したりして最低限にしたのですが、mpv_options.txtの方も不要なものはここでちゃんと無効にしておかないと、mpvのビルドをNoにした場合でもmpv用ライブラリをビルドしにいってしまい無駄に時間がかかってしまうので注意。ビルドしたのは3/5で、各コミットは以下のとおりです。当面はlibvmafはZeranoe版バイナリには入らない模様です。libvmafは2.8fpsしか出ませんでした。ssimでは実行中のメモリ使用量も200MB以下なのですが、libvmafでは最大6GBくらいになってかなり重くなりました・・・。バグなのか仕様なのかビルドの問題なのか不明ですがもうちょっと軽く動くようになると嬉しいですね。「同じビットレートならどれが一番VMAFスコアが高いか」を調べて、最適な配信用ファイルを決めるといった形で使うものだと思います。●したがって、リサイズしたもののVMAFスコアを測る場合は、リサイズしたものをオリジナル解像度に戻した上でVMAFスコアを測るのが一般的ではないかと思います。–といった形の方が順序的にも意味的にもわかりやすいのではないかと思います。original.yuvといった表現に変えるとわかりやすくなると思います。(referenceって一般的にはあまりなじみが無い表現かなーと)●enable_transformは、「transformを計算する」というより「VMAFスコアの計算でtransformを有効にする」という説明の方がよいかと思います。(どういう処理なのかは自分もよくわかってないですが同一ファイルのVMAFスコアが100.0になったりするようです。PM指摘ありがとうございます。後で文章を直しておきます。メモリリークについては報告されています。PMメモリリークの情報と更新ありがとうございます。メモリリークの件は調べていませんでした。・「リサイズする場合」というタイトルは「解像度が異なる場合」が良いかも。・VMAF計測時のリサイズアルゴリズムは特に縮小時と同じにする必要はなく好きなもの(視聴時に期待できるもの)を選択すればよい。(高性能なアルゴリズムにすればスコアも上がる)・エンコードする前の動画(オリジナル)をリサイズするのではなく、エンコード後の動画をオリジナルサイズにあわせてリサイズする。・VMAF計測時のコマンドでscaleの引数が1280:720になっているが1920:1080のはず。(このままだと解像度違いでエラーになる)ということで、以下のような感じが良いかもしれません。スコアを調べるには、調べたい動画をフィルタでオリジナルの解像度にリサイズしてから調べればよい。する必要がある」という注意書きもあると良いかなと思いました。PMlibvmafのメモリリークの修正、コミットされました。PMコメント確認しました。それどころじゃないくらい遅くて今のところ全く実用的ではないですね。AV1(libaom-av1)で1920×1080の10フレームだけをエンコードしてみた結果。PMAV1はまだ最適化もされてませんから遅すぎてテストもままならないですね・・・。Zeranoe版ffmpegではlibaomのビルドミスがあり、ffmpeg-20180404-53688b6までは本来よりも更に遅い結果(最大で5.7倍くらい)となります。そのため検証するならそれ以降のビルド(このコメントを書いている時点ではまだ未リリース)を使う必要があります。コメントをキャンセルメールアドレスが公開されることはありません。コメント名前メールアドレスサイト次回のコメントで使用するためブラウザーに自分の名前、メールアドレス、サイトを保存する。date*日本語が含まれない投稿は無視されますのでご注意ください。vincentdubroeucq.。