バグ修正
  • utv_vcm.dll のインストール先が間違っており、VCM インターフェースでコーデックが使えなかった。

readme 日本語 英語 / インストーラ x86 x64 / ソース

ダメダメですが穴掘って埋まったりはしません。

Trackback

4 comments untill now

  1. 8.5.1の際にコメントした者です。

    最新版では問題なく動画を再生することが出来ました。
    早々のご対応ありがとうございます。

  2. 修正お疲れ様です
    過去の記事にutvideoは編集用として開発方針が決まっているというのを拝見しました
    そこで不躾な質問なのですが、キャプチャ(録画)向けとしても使えるという方針は
    作者さんの今後の開発の方向性としてあり得るのでしょうか?
    今のところ自分が動画を作成するときは
    録画(utvideo以外のコーデック)->編集->途中出力(ここでutvideo)->エンコード
    という流れなので録画から最終的なエンコード直前までを
    utvideoで終わらせたいなと考えたのですが
    今現在の開発方針はどのような形を考えているのでしょうか?

  3. 梅澤 威志 @ 2011-03-28 13:43

    何も考えてません!

    …だと話が終わってしまうので、質問の前半部分に関して補足しますと、

    「編集向け」というのは、おおむね「どのフレームに対しても(デコード時に)ランダムアクセスが速い(可能な限り速いほうがよい)」を満たすものです。一方で「キャプチャ向け」というのは、「リアルタイムキャプチャができる範囲でエンコードが速い(ものすごく速い必要はない)」あたりが条件になると思います。

    で、UtVideo の場合ですが、720p/60fps/YUY2->ULY2 でも今時の CPU (といっても Core 2 Duo 程度)と今時の HDD の組み合わせなら既にリアルタイムキャプチャできてしまうので、キャプチャ用としても問題なく使えるはずです。

    これ以上高速とか高圧縮とかいう話だと根本的に異なるアルゴリズムを持ってこなければいけなくなって、素人(画像処理の専門家ではない)には難しいものがありそうです。

  4. 回答ありがとうございます
    >何も考えてません!!
    には不覚にも笑ってしまいましたw
    今後はメンテナンスUPが主体となりそうですね
    これ以上の高速・高圧縮にアルゴリズムが壁になっているのは
    逆に現状で出来る限りの改良を施せたと言えると思います
    アルゴリズムの壁をいつか越えられるのを
    応援しながらのんびりと待つことにします。

Add your comment now