その4の続き

C++ だとどうでしょうか。

Read the rest of this entry

その3の続き

その3ではリンクを Visual C++ 側で行いましたが、GCC 側でも行ってみます。

Read the rest of this entry

朝起きたら ARM 版 Windows 10 が発表されてました。Windows RT とは違ってフル機能の Windows 10 が動くらしいです。ネイティブ環境としては ARM64。しかも x86 エミュレーションあり。お兄さんビックリです。さすがに? x64 エミュレーションは無いようですが。

フル機能の Windows 10 が動くということは、マルチメディアフレームワークである Video for Windows や DirectShow も当然載っていることが期待されます。そうするとコーデック開発勢としては ARM のアセンブラを勉強しなきゃいけないんですが、手持ちの ARM デバイスは Nexus5 しかなくて、これだと Java から呼び出すことになってしまって面倒です。母親の iPhone 6s を使うという手もありますが、これもこれで面倒です。

世の中には Raspberry Pi というものがあり、 Linux が普通に動いて(クロス開発ではなく)ホスト開発できてしまうので、これを使うのが良さそうです。Raspberry Pi 3 なら ARMv8 なので 64bit 開発可能です。これ本体ボードだけなら5000円しないんですね。安いなぁ。

ところで、発表されたので ARM の技術情報を見に ARM のサイトに行ったんですが、サーバが重いせいか昼からずっとアクセスできません。元から重いのか Windows の発表のせいなのかは分かりませんが…

長らく「自分のインストールしたCentOSではvimが構文着色等されないのに、他人のインストールしたCentOSでは構文着色される」のが疑問だったんです。ホストによって自分のドットファイルが違っているとかそういうことは無いです。

で、自分のインストールしたCentOSでは vim-minimal パッケージしか入っていないが、他人のインストールしたCentOSでは vim-enhanced パッケージも入っている、ということに先ほど気が付きました。そういうオチかい。私いつも最小インストールしてからパッケージを足していってるんで。

vim-minimal に入っているのは /bin/vi で vim-enhanced に入っているのは /usr/bin/vim なのですが、私の .bashrc では vim がある場合は alias vi=vim となるようになっていたので気が付かなかったんですね。

その2の続き

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

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

Read the rest of this entry

その1の続き

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

Read the rest of this entry

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

Read the rest of this entry

前の記事で、システム環境変数で 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 って本来そういう効果を持つ環境変数ですし。

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

「Saratoga」「サラトガ」「Commandant」「コマンダン」「Teste」「テスト」「山
風」「朝風」「浦波」「Prinz」「Eugen」「Graf」「Zeppelin」を追加しました。

ダウンロードはこちら / readme

「こまんだんてすと」→「コマンダン・テスト」「Commandant Teste」とか追加した方がいいのかな。

その1の続き

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

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