機能追加
  • ULxx: Predict Gradient フレーム内予測方式を追加した。
性能向上
  • ULxx: エンコードを高速化した。

readme 日本語 英語 / ライセンス (GPLv2) 日本語 英語
バイナリ Windows (exe) Mac (zip) / ソース

Huffyuv などにも見られる Predict Gradient を実装しました。ほとんどの場合において Predict Left より圧縮比・エンコード速度・デコード速度ともに良い成績となります。こんなことならもっと早く実装すべきだったし、もっというと Predict Left 要らなかった。

エンコードを高速化した件は readme には書かれていません(単なる書き忘れ)。

いつもベンチマークに使っている crowd_run だと以下のようになります。なお、crowd_run は Predict Left の場合の圧縮比がかなり低くなるクリップらしく、結果として Predict Gradient との差が典型的なケースと比較して大きく出ています。あと、高速化に伴い、速度のグラフは右端が1000fpsから1100fpsになっています。

Trackback

16 comments untill now

  1. hiroshi ito @ 2017-04-09 15:35

    試しに使ってみます

  2. hiroshi ito @ 2017-04-09 15:36

    Thank you

  3. Predict Gradientを使用すると、MPC-BEの環境で正しく再生されなくなりました。Predict medium等では正常に再生できました。上書きインストールでしたので、それが原因かと思いアンインストール後再度インストールを試みましたが症状は改善されませんでした。エンコードに使用したのはAdobeMediaEncoderCC2017とAviutl1.00の二種類試しました。
    完全にコーデック側の原因かどうか判断できていませんがご報告させていただきます。

  4. 原因を探ってみたところコーデック側に問題があるのではなく、MPC-BEに含まれているUtvideoコーデックがPredict Gradientに未対応?なのが影響で正しく再生されないことがわかりました。
    内部フィルター設定のビデオデコーダーからUtVideoのチェックを外すことで解消されました。
    大変お騒がせしました。

  5. ねぎ猫 @ 2017-04-27 00:11

    以前のバージョンから、ありがたく使わせていただいております。
    無駄な長文とせぬため簡潔に発言します。

    RGB, YUV444 以外では、白浮な物となります。
    程度としては PCスケール→TVスケール程度です。

    x264 利用時でも同様なので UtVideo の挙動では無いように思われますが、そのような事なのでしょうか ?

  6. 梅澤 威志 @ 2017-04-27 01:35

    どのような主張をされたいのか分かりません。何かしら問題があると考えているなら再現手順を提示してください。

  7. ねぎ猫 @ 2017-04-27 17:53

    UtVideo 固有ではないかと思いますが
    私よりはるかに、その種の知識を有する方であると思い
    質問させていただいております。
    自分自身、それが問題なのかどうか解らないのです。

    たぶん、気が付かなかっただけなのかもしれません。
    黒帯のある動画を扱って気が付いたのです。
    ディスプレイのいわゆる背景は黒に設定しています。
    黒帯の部分 (全般的にも浮いて見えます) が
    RGB, YUV444 ではディスプレイの背景と同様程度で再生されますが
    YUV422, YUV420 で保存した物は明らかに白浮きとなります。

    最初は、UtVideo の YUV がリミテッドだから…と思いましたが
    YUV444 なら浮かない

    422 や 420 のような色情報を削った物は “そうなる” という
    事なのでしょうか ?

  8. ねぎ猫 @ 2017-04-27 17:58

    すいません、修正します。

    黒帯のある動画

    〇元は 4:3 だが 16:9 とするために黒帯を付加した動画

  9. very nice codec

    thank you

  10. Martynas @ 2017-04-29 18:15

    Thank you!

  11. 梅澤 威志 @ 2017-04-29 23:24

    うーん。

    ULRGやULY4では問題が無くてULY2やULY0では黒浮き&白沈み(?)になるというのは、YUV422でコーデックに渡すときに渡す側の変換処理がおかしい(RGBで渡すときは正しい)、と考えられます。x264ではULY2などと同様だとすると渡す側がYUV420に変換する場合でもおかしいのでしょう。ULY4はRGBかYUV444でしか受け渡しできませんが、渡す側がYUV444で渡す処理を実装していない(結果としてRGBとして渡す)と思われます。

    それぐらいですかね。

  12. UtVideo本体ファイルはどのようにしてダウンロードするのでしょうか?

  13. 申し訳ございません。
    解決いたしました。

  14. いつもお世話になっています。
    1つ質問というか困ったことがありメッセージいたしました。

    エンコードするとき、違うフィルタ処理のAとBを用意し(utvideoでAVI出力)、
    その2つをmergeして出力したC(これもAVI)をmp4等に圧縮出力しています。
    ここで、正しい使い方ではないのかもしれませんが、
    今まで便宜上Aをutvideoで再AVI出力してBを作ってきたのですが(実質utvideoの2重出力)、
    最新版にしましたらmergeする際に「pixel types are not the same」というエラーが出て合成できなくなってしまいました。
    ここまですべてAviutlを使用したAviSynthエンコードです。

    詳しく調べましたら、バージョン 17.3.0以降のutvideoからこのエラーが出るようになったようなので、
    おそらく「ULY4, ULH4, ULY2, ULH2, ULY0, ULH0: ネイティブな planar フォーマットでの入出力を高速化」での影響かと思われます。
    使用しているのは「YUV420 Vt.709 VCM」なので「ULY0」にあたるでしょうか。
    もしくはAviSynthの読込の問題の可能性もあるかもしれません。

    utvideoで出力したAVIをさらにutvideoで出力すること自体が間違いと言われたらどうしようもないのですが、
    入出力の際に、色空間に何らかの良くない影響が起きている可能性も無くは無いので、
    もし問題でしたら改善いただけると大変助かります。
    ご検討よろしくお願いいたします。

  15. 度々すみません。
    上の投稿後すぐに
    試しに同じ出力のAVI同士でmerge処理してみたところ(つまりは2重出力などしていない全く同じAVI)、
    同様に「merge: pixel types are not the same」のエラーが出ました。
    同じものなのに色空間が違うと判断されるのにはいささか疑問あり、
    バージョン 17.3.0で行われたutvideoの変更から起きたことと思われますが、
    そもそもmergeするavisynth・aviutl側の対応の問題かもしれません。
    utvideoの不具合である可能性は低いと思われます、すみません。

  16. 梅澤 威志 @ 2017-05-16 23:08

    え、あ、はい

Add your comment now