機能追加
  • 診断用ログを出力する機能を追加した。
バグ修正
  • ULRA, ULRG: 「圧縮率優先」かつインターレースでエンコードした映像を RGBA/RGB32 で出力すると壊れていた。

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

Macユーザ向けの注意: 今回から QuickTime コンポーネントのファイル名が utvideo.component から utv_qt.component に変わっています。単にファイルをコピーするだけだと古い方が残ったままになるので、必ず削除してください。

インストール物に含まれている utv_logc を実行すると、その後に起動したコーデックのログ出力がずらずらと表示されます。ログ出力中に utv_logc を終了させても問題ありません。なお、やってみればわかりますが、QuickTime コンポーネントの場合は処理上の関係でログが超出力されます。何とかしたい。

バグの方はデコーダの問題なので、再エンコードは不要です。

Trackback

35 comments untill now

  1. 使わせてもらいたいです、

  2. でいじー @ 2015-05-10 15:42

    使わせてほしいです!

  3. でいじー @ 2015-05-10 15:42

    使わせてもらいたいです!

  4. さくら @ 2015-05-13 17:23

    使わせていただきたいです!

  5. 使わせていただきたいです!

  6. 果実工房 @ 2015-05-21 15:13

    使わさせて頂きますm(_ _)m

  7. すいすい @ 2015-05-29 02:15

    梅澤さん、お久しぶりです。

    ふとテストして気づいたことですが、Mac版でフレームレートが30fps(29.97)以上の設定で書き出すと、
    QuickTimePlayerなどでの再生でフレームレートが極端に落ちるようです。
    データ的には問題なく30fps以上で書き出されていると思います。

    Youtubeとかで高画質で上がっている様な60fps(59.94)の動画を作ってみて試しましたが、
    512x288pxのようなサイズでもフレームレート落ちが発生しました。
    これはYUV420でもRGBでも全てで同じ現象でした。

    他のCodecであるProresやHQXなどでは60fpsが保てていたので、恐らくUtVideoだと起きているようです。

    まぁ、そこまでMac版のUtVideoに作業させて良いのかと思う部分はありますが、一度ご確認しただけると幸いです。

  8. すいすい @ 2015-05-29 02:22

    梅澤さん、すいすいです。

    上の話の追記ですが、フレームレートが落ちている時の再生FPSは6とか1とかまで落ちます。

  9. 梅澤 威志 @ 2015-05-29 14:26

    すいすいさん、お久しぶりです

    これは30fps(あるいは 29.97fps?)ちょうどの場合は特に問題なく、それを超えると映像サイズ(ピクセル数)に関わらず再生時フレームレートが下がる(カクつく)、ということでよいでしょうか。(Mac だと手元では 30fps でしか出力したことが無い)

    コード上は fps に依存するような処理は Win/Mac 問わず書いてないのですが、見てみます。

    ところで、Windows 上で出力した 60fps な AVI を QT Player で再生した場合だとどうなりますか?

  10. すいすい @ 2015-05-29 16:21

    梅澤さん、コメントありがとうございます。

    今しがたWinでも最新版を入れて色々と試してみました。

    結論はMac版と同じでQTPlayerでは30fps以上で著しいコマ落ちしますね。

    コマ落ち率はMacの時と同じで1~6fpsくらいまで一気に落ちます。
    ただ、再生が保つ時はなんとかFPSを保持しようとしているみたいですがどこかで一気に落ちてきます。

    そして、30FPS(29.97)に間引いた方はWin/Mac共にQTPlayerでコマ落ち無く再生されました。

    テストのデータをwebストレージに上げましたのでご確認にお使い下さい。
    https://srv01.bitsend.jp/download/dc42727e92244d0514efe86ca13b9aa8.html

    「After Effects CS5.5.avi」が無圧縮60fps(59.94)のマスターです。
    これから、
    ・AVIで60FPSなUT Video YUV420 601
    ・MOVで60FPSなUT Video YUV420 601
    ・MOVで60FPSなGV HQX
    ・MOVで30FPSなUT Video YUV420 601
    を生成しました。

    もちろん、Windows上でのMediaPlayerでのUT Videoは全く問題有りません。

  11. すいすい @ 2015-05-30 22:55

    梅澤さん、すいすいです。

    その後自分のWin8.1ノートでも試してみました。
    こっちだとWin版QTPlayerでもほぼ問題なく60FPS再生できている感じでした。

    実験したPCは、
    Win7デスクトップ(HDD)-> コマ落ち
    MacBook(SSD)-> コマ落ち
    Win8.1ノート(SSD)-> コマ落ちほぼなし

    なので、単純にPCのHDD/SSDの転送レートが低かったためかもしれません。
    それでもWni8.1だと大丈夫だったのは不思議です。

  12. 今日初めてUtVideoを知りました!
    本当に今まで使っていたコーデックが馬鹿みたいです。
    今後の動画にぜひ使わせてもらいます!
    あと、製作頑張ってください!

  13. 是非使わせて頂きたいですm(_ _)m

  14. すいすい @ 2015-06-02 21:04

    梅澤さん、すいすいです。

    その後ですが、大丈夫だったとお伝えしたWin8.1ノートでも試しにHD素材で60FPSなものをutvideo圧縮にしてQTplayerで再生した所、激しくコマ落ちしました。

    そのmovファイルをLAVFilterを使うMPC-HC等で再生してみると、問題なく60FPS出ていたので、QTPlayerでの再生時のみそのような状況が起きるみたいです。

    以上、追加情報までに。

  15. 梅澤 威志 @ 2015-06-03 18:53

    >>すいすいさん

    結局のところ QuickTime コンポーネントが使われると Win/Mac 問わずカクつくということでしょうか。

    QuickTime コンポーネントは他のインターフェースのものと比べてかなり効率が悪い書き方になっているのでそういうこともあるかもしれない、という感じです。

  16. すいすい @ 2015-06-04 14:00

    梅澤さん、すいすいです。

    そうですね、結局のところQuickTimeコンポーネントでの再生でのみカクつく現象が発生します。
    AfterEffectsなどでも再生確認してみましたがこちらはメモリキャシュ再生なので問題はないです。
    *当たり前といえば当たり前ですが。

    現状でUTVideoCodedを利用しているユーザは圧倒的にWinユーザーが多いと思いますから、懸念になる事柄ではないかもしれませんね。

    >>QuickTime コンポーネントは他のインターフェースのものと比べてかなり効率が悪い書き方になっているのでそういうこともあるかもしれない、という感じです。

    原因の起因っぽいのが理解出来ましたので、また安心して利用できます。
    ありがとうございました。

  17. 梅澤 威志 @ 2015-06-04 20:57

    QuickTimeコンポーネントのやつの書き方が良くないのは、パフォーマンスの点の他に、最近追加した診断ログ機能が使い物にならないという問題点があり、次のバージョンで対応しようと考えています。ただ、これはコーデックエンジン側に影響のある(そしてそれを介して他のコーデックインターフェース版にも影響のある)修正となります。

    で、例によっていつやるの?というのは約束しないわけですが…

  18. だっく @ 2015-06-08 21:36

    使わせてほしいです!

  19. えだまめ @ 2015-06-08 21:54

    動画製作時に使わせていただきます。

  20. 初めまして。
    スレッドのプライオリティを設定できる機能を追加していただけませんでしょうか。
    ゲームキャプチャのエンコード等の場合、ゲーム側でスレッドをぶん回している状況があるのですが、
    そうするとマルチスレッド時にスレッドの取り合いが発生して、
    同じプライオリティ同士だと1スレッドあたり50%しか利用できません。
    リアルタイムエンコード時コーデック側が50%以下の負荷ならば問題は無いのですが、
    50%以上のCPUリソースを必要する場合、当然リソースが足りなくなるのでフレーム落ちとして処理するしかなくなります。
    コーデック側のスレッド数を減らして、衝突回避をOSに期待するように設定すると若干パフォーマンスは上がりますが、
    本来の性能上限には届きません。

    CThreadManager::CThreadManager(void)
    内で、
    SetThreadPriority(m_hThread[m_nNumThreads], THREAD_PRIORITY_HIGHEST);
    の様に、プライオリティ高めに設定するとコーデックの処理が優先されて、上記の問題は発生しない事を確認済みです。

    例では、THREAD_PRIORITY_HIGHEST ですが、色々選べる仕様だと嬉しいです。

  21. 梅澤 威志 @ 2015-06-16 20:53

    いいですね。やりましょう。

  22. 使わせていただきたいです

  23. ぜひ使わせていただきたいです!

  24. Jean-Philippe @ 2015-07-19 17:19

    Hello.

    Is there any chance (by luck), that YV24 support will be implemented in the future ?
    I’m personnaly working with YV12 or YV24 videos, and i’m using UT Video for YV12 and Magic YUV for YV24, but if i had the possibility to use only UT Video (i found it better thant Magic YUV) for both YV12 and YV24, it would be great.

    Anyway, thanks for your codec.

  25. 梅澤 威志 @ 2015-07-20 11:58

    Currently, I have no plan to implement YUV444 variant (ULY4?). But implementing it does not seem to be difficult, if I write YUV< ->RGB conversion in C++ (i.e. not in assembly language).

    Are there any popular NLE software that support YUV444 colorspace (e.g. YV24) as exchange format to/from video codecs?

  26. Jean-Philippe @ 2015-07-20 16:57

    The idea of supporting natively YV24 is to avoid YUVRGB conversion. If you’re doing this internaly, the double conversion YUV->RGB->YUV may affect the picture (and so sligthy decrease its quality), and that’s what to be avoided.
    As you’re already supporting YV12 and YV16, which are planar modes, i thought YV24 will be “easy”.
    Unless i misunderstood your comment, and you talked about an YUVRGB conversion only in the purpose of allowing the YV24 of your codec to be decoded in RGB if user wanted it, and not with the idea of storing the YV24 in RGB.

    Don’t know what “NLE” means, but i’m using avisynth and VirtualDub, and both support YV24 colorspace.
    … “Non Linear Editing” maybe, after a little tought ?

  27. 使わせていただきます。

  28. 上記の者です。実を言うと、このサイトは初めてでダウンロードは何処を押せば良いのか分かりません。教えて下さい。

  29. 使わせていただきます!

  30. 使わせていただきます

  31. sakuraruruka @ 2015-12-13 10:45

    使わせていただきます

  32. ULH0 1920×1080 23.976fpsのAVIファイルを、
    Windows 10 Pro 64bit (version 1511 build 10586)
    のWindows Media Playerで再生すると、途中でダイアログを出して再生停止することがあります。

    ダイアログにWebヘルプを参照するボタンが出るので押してみると、
    http://windows.microsoft.com/ja-jp/windows7/c00d11b1
    へ飛ばされます。

    他の内容・フォーマットの動画では確認していません。暇があれば確認してみます。確認したファイルでは、大体同じ再生時間で停止するようです。

    バージョン15.2.0で作成した動画をバージョン14.2.1で再生しても、目立った問題はないように見えますのでデコード時の問題でしょうか?
    また、VirtualDub 1.10.4ではバージョン15.2.0でも問題なく再生できています。

    バージョン14.2.1へのダウングレードで回避していますので困ってませんが、とりあえず報告だけでも。

  33. 梅澤 威志 @ 2015-12-29 15:58

    ご報告ありがとうございます。

    「途中でダイアログを出して~」ということですが、不正な処理等で停止するわけではないのですよね(「○○は動作を停止しました」みたいなダイアログ)

    問題なければ当該動画ファイルをください。停止するあたりを切り出してもやっぱり停止するようであれば切り出したものでも構いません。

    リンク先を見ると音声側の問題のように見えますが、そもそも提示されたWebヘルプが信用できるかどうか(見当はずれのモノを提示されることがある)という話もあります。

  34. 使わせていただきます

  35. kiyoshi hara @ 2017-11-23 15:52

    使わせていただきます。

Add your comment now