或るプログラマの一生

Ut Video Codec Suite に DMO コーデックを追加するにあたって、コーデックがちゃんとシステムに認識されているかをチェックするために、VCM コーデックの場合は vcavail を、DMO コーデックの場合は Windows SDK に入っている GraphEdit を使っていたのですが、実装インターフェースによってツールが違ったり、x86 と x64 で違う実行ファイルでチェックしなければいけなかったりと面倒だったので、まとめてチェックするために作ってみました。

バージョン 7.0.0 で x64 環境に対応して以来、x64 版のパッケージには x86 のバイナリと x64 のバイナリが含まれており、x64 Windows においては、x64 版のパッケージのみをインストールすればいいようになっています。また、バージョン 7.0.2 以降では、x86 版のパッケージは x64 Windows にインストールできないようになっています。

で、皆さんにアンケートなのですが、以下のどちらが望ましい（分かりやすい、便利、など）でしょうか？理由とともにお答えください。

1. 今までどおり、x64 版のパッケージには x86 と x64 の両方のバイナリが含まれる。x86 版のパッケージは x64 Windows にはインストールできない。
2. x64 版のパッケージには x64 版のバイナリのみが含まれる。x86 版のパッケージも x64 Windows にインストールできる。

現状 1 の方法になっている理由ですが、バージョン 7.0.0 のパッケージを作る際に、x86 版のパッケージを x64 Windows にうまくインストールできなかったからです。今試したら別に問題なかったのですが、これはバージョン 7.0.4 でコーデックの登録方法を変更したからである可能性があります。本当にそうかどうかは分かりませんが…

現在は DMO 版のエンコーダを実装しています。これにより、64bit の DirectShow 環境で使えない問題と、（うまくいけば）VCM コーデックを DirectShow 環境で使ったときにエンコード設定が期待通り反映されない問題が解消されるはずです。

ちなみに、現時点での最新バージョンは 7.1.1 なので、アイマス民としては次のバージョンは 7.2.0 にしたかったのですが、手ごろな新機能のネタが出てこなかったので諦めました。ひんそーでちんちくりんなこーでっくはあなをほってうまってますー。

以前の記事のコメント欄で、x64 の GraphEdit でもUt Video Codec Suite を選択できるのが期待される動作である、と書きましたが、調べていったらそうではないように思えてきました。あ、もちろん「そう動いていてほしい」という願望の意味では「期待される」のですが。

その他

• DLL をフルパスで登録するようにした。

性能向上

• Athlon 系プロセッサで発生するパフォーマンスの劇的な低下を改善した。

インストール方法をまたいじっていたら自分でもインストールできなくなったんだけど、アンインストールしてある状態でレジストリエディタでゴミを消していった後にインストールしなおしたらうまく行ったので、うまくインストールできないって人はレジストリにゴミが残ってるんじゃないだろうかと思った。

とは言うものの、レジストリエディタでゴミを消すのも簡単にできることじゃないですからねぇ…勇気のある人はお試しください、程度で。

結論から言うと「L1データキャッシュが 2-way セットアソシアティブであり、スラッシングが発生するアクセスの仕方をするから」のようです。データシートを軽く見た限りでは、Athlon 64 以降の CPU は全て L1データキャッシュが 2-way のようなので、この問題に引っかかります。

一方、手元の Intel Core 2 Quad Q6600 だと 8-way なのでスラッシングが発生せず、遅くなりません。おそらく 4-way でもスラッシングが発生しないものと思われます。

以下経過と詳細。

その他

• コーデックをシステムに登録する方法を（試験的に）変更した。

いつもどおり可逆圧縮スレを眺めていたら、「Ut Video が FFmpeg に移植されるかも」という書き込みが。えっ、マジ？