その１の続き
コーデックにデバッグログを仕込んで出力を眺めていましたが、Ut Video Codec Suite 側には問題はなく、呼び出し方に問題があるという結論に達しました。頻繁に内部バッファをフラッシュする指示を送ってきながら、その直後にデコード済みフレームの取得を行っています。フラッシュされているので当然取得できず、その場合に透明なフレームとして表示されているように見えます。
とはいうものの、使えない状態で放っておくのもどうかと思うので、アプリケーションごとに特定のインターフェースを無効にする機能ぐらいは作ってもいいかと思います。今回の例では、HitFilm では DMO インターフェースを無効にし、VCM インターフェースでのみ Ut Video Codec Suite を使用するように設定すると回避できることが分かっています。なお、今すぐ何とかしたい場合は、 C:\Windows\System32\utv_dmo.dll を削除すると何とかなります（副作用があるかもしれません）。
Twitter をエゴサーチしていると、Windows 10 の Windows Update の後で Ut Video Codec Suite が消える（使えなくなる）、とツイートしている人をそれなりに見かけます。（再インストールすると使えるようになるようです）
最初は Anniversary Update 時特有の現象だと思っていて放っておいた（「ご不便をおかけしております」で済ます）のですが、今月になってもまだツイートがあるので、これはホントに毎月消えるんじゃ？と思って手元でテストしました。結果、そのような現象は確認できませんでした。
全員が勘違いしているとは考えづらく、何が起きているのか分からず気持ち悪いところです。とりあえずこれから毎月確認してみます。
以前書いた記事で intrinsic の欠点をいくつか述べていますが、このうちコンパイラが古いと最近の命令を使えない、という重大な点については、Visual C++ 2015 や Xcode 7 に移行することにより既に解決してしまいました。将来的にも、OSS開発 and/or 個人開発 であれば Visual C++ も無料で Pro 版相当の機能のものが使えるようになってしまいましたし（新しいコンパイラを追いかけるのに費用が掛からない）。
一部の命令が無い点については解決されうるものではなさそうですが、そういうところは相変わらずアセンブラで書いておけば良いかと思います。Ut Video Codec Suite 的に一番重要なハフマン符号処理がこれなのがちょっと残念ですが。
なんで今更こんなこと言っているかと言うと、いい加減「ほとんど同じかと思いきや結構違う2つのアセンブラソース (x86/x64) をメンテする」のはもういやだ、と思ったからです。思うのが遅いという話はあります。
AEオフ2016 で、「Ut Video Codec Suite のご紹介」として LT をやってきました。ご紹介というか宣伝というか。
ところで、発表時間が足りなくてスキップしたスライドの中に「可逆圧縮コーデックのシェアウェアに市場性はあるか」というページがあるんですが、2次会で周りに意見を聞いてみたところ、おおむね「ダメなんじゃね？」という反応でした。むーん。一家言ある方はコメントお願いします。