或るプログラマの一生

その２の続き

細かいことは置いといて、とりあえず一番簡単な条件を試してみましょう。処理系は以下の通り。

• Windows 7 64bit
• Visual Studio 2015 / MS-C for x86
• Cygwin 32bit + gcc-core 5.4.0-1

その１の続き

そもそも相互運用するとして、どの点に互換性が必要かを考えると、おおむね以下のようになると思います。

Windows で使える GCC/Clang のバイナリでメジャーなものには、おおむね4つの「リリース元」があると思います。

前の記事で、システム環境変数で JAVA_TOOL_OPTIONS を -Dfile.encoding=UTF-8 -Dsun.jnu.encoding=UTF-8 に設定するととりあえず回避できる、と書きました。しかし、よくよく考えてみると、Jenkins slave をインストールしているディレクトリにある jenkins-slave.xml の <arguments> 要素に -Dfile.encoding=UTF-8 -Dsun.jnu.encoding=UTF-8 を追加すればそれで済むことに気が付きました。JAVA_TOOL_OPTIONS って本来そういう効果を持つ環境変数ですし。

これで他のプログラムに影響することを避けられます。

その１の続き

コーデックにデバッグログを仕込んで出力を眺めていましたが、Ut Video Codec Suite 側には問題はなく、呼び出し方に問題があるという結論に達しました。頻繁に内部バッファをフラッシュする指示を送ってきながら、その直後にデコード済みフレームの取得を行っています。フラッシュされているので当然取得できず、その場合に透明なフレームとして表示されているように見えます。

とはいうものの、使えない状態で放っておくのもどうかと思うので、アプリケーションごとに特定のインターフェースを無効にする機能ぐらいは作ってもいいかと思います。今回の例では、HitFilm では DMO インターフェースを無効にし、VCM インターフェースでのみ Ut Video Codec Suite を使用するように設定すると回避できることが分かっています。なお、今すぐ何とかしたい場合は、 C:\Windows\System32\utv_dmo.dll を削除すると何とかなります（副作用があるかもしれません）。

性能向上

• ULY4,ULH4: RGB 系フォーマットからのエンコードを高速化した。
• ULY4,ULH4: RGB 系フォーマットへのデコードを高速化した。

CentOS7 で EPEL 由来の Clang (3.4.2) を使って std::enable_shared_from_this を使った以下のようなコードをコンパイルすると、何故かリンクエラーになります。（要 -std=c++11）

ESXi 上に VM の Windows 7 があって、その仮想ディスクが容量不足になりました。この VM では Windows の機能でミラーボリュームを構成しています。

Twitter をエゴサーチしていると、Windows 10 の Windows Update の後で Ut Video Codec Suite が消える（使えなくなる）、とツイートしている人をそれなりに見かけます。（再インストールすると使えるようになるようです）

最初は Anniversary Update 時特有の現象だと思っていて放っておいた（「ご不便をおかけしております」で済ます）のですが、今月になってもまだツイートがあるので、これはホントに毎月消えるんじゃ？と思って手元でテストしました。結果、そのような現象は確認できませんでした。

全員が勘違いしているとは考えづらく、何が起きているのか分からず気持ち悪いところです。とりあえずこれから毎月確認してみます。

[umezawa@dev-cent6:pts/0 ~]$ rpm -q cmake
cmake-2.8.12.2-4.el6.x86_64

[umezawa@dev-cent7:pts/0 ~]$ rpm -q cmake
cmake-2.8.11-5.el7.x86_64

OS をアップグレードすると CMake のバージョンが下がる… ﾅﾝﾃﾞﾔﾈﾝ