或るプログラマの一生

2017年11月にいただいた寄付は以下の2件です。ありがとうございました。

なお、2017年10月には寄付はありませんでした。

現在の Ut Video Codec Suite の圧縮はハフマン符号によって行っているのですが、ハフマン符号だと命令レベルの並列性が低いとかSIMDにやさしくないとかの問題があり、性能は頭打ちとなっています。

ここしばらくSIMDにやさしいアルゴリズムを考えていて、ある程度実装した結果まあまあ満足できる性能を達成できることが分かったので、これを正式に実装しようと考えています。実装した結果は github で見れます。

実際の性能ですが、2k/RGB24 の crowd_run （ここで使っているもの）で圧縮比 1.74、 i7-2600K でエンコード 95fps デコード 150fps、 i7-4770 で 180fps/300fps 程度です（シングルスレッド時）。AMV4 DR3 と比較して圧縮比は少し高く、処理速度は少し低いという感じになります。なお、 AMV4 は時間方向に圧縮する機能があって変化の少ない映像だと高い圧縮比を達成できますが、UtVideo の方では future works ということにしたいと思います（効率よく処理する手法を思い付けていない）。

そういや C++ で算術右シフト (arithmetic right shift) するにはどう書けばいいんだろう、 intrinsic ないよなぁ…と思ってたんですが、「ほとんどのコンパイラでは」符号付き整数を右シフトすれば算術右シフトになるようです。

ただ、（負の）符号付き整数を右シフトした時の動作は処理系定義なので、論理右シフトになる処理系をうっかり踏むかもしれません。以下のような static_assert を書いておけば安心でしょう。

static_assert(-1 >> 1 == -1, "signed right shift is not arithmetic.");

ちなみに負の整数を左シフトした場合は未定義動作らしいです。怖い。

AVI を再生しようとした時に Huffyuv と UtVideo とで挙動（というか、出てくる media type の形態）が違う点について調べていたのですが、 avidemux element が FourCC に応じて自分で設定している、つまり「コンテナを処理するコードがコーデックごとに処理を変えている」ようだ、ということが分かりました。 FourCC が HFYU の場合は「知っている」ので video/x-huffyuv になり、 ULRG の場合は「知らない」ので video/x-avi-unknown; fourcc=(int)0x47524C55 になります。

ドキュメントは一通り読んでいて、ようやく Ubuntu Desktop 上で既存の element の挙動を調べています。

ついでに言うと Linux は今まで RedHat 系 (RHL, Fedora, CentOS) しか使ったことがないんで、Ubuntu のパッケージ命名規則に微妙に戸惑いがあります。だったら Fedora 使えと言われそうですが VM 上でなんか挙動が不審だったんで…

以前こんなことをツイートしてました。

主に Ut Video Codec Suite の開発まわりでの、改行コードが LF の対応状況をメモ代わりに。

JetBrains はオープンソース開発向けに無料ライセンスを用意しています。 Ut Video Codec Suite の開発にこれを適用できないかと思いました。この場合、実際に使うのは CLion になります。

Ut Video Codec Suite を Linux (Unix) でも使える（ビルドできる）ようにすることを考えているわけですが、今時生の Makefile をフルに手書きしたくはありません。

今 Unix でポピュラーな Makefile 生成システムというと autotools (automake/autoconf) と CMake が考えられます。他にも SCons とかいろいろあるようですが、考えないことにします。（ググっても CMake と比較するとだいぶ少ないし）

一般論として、リポジトリ内の改行コードは LF がよい、ということになっているようですが、例えば Ut Video Codec Suite とかのリポジトリでは CRLF で入っています。ついでに src zip も CRLF です。

なんでそうなっているのかというと、昔は Linux 上で svn リポジトリを checkout して samba 経由で Windows から開く、ということをたまにやっていたからです。Visual Studio 2005 だといくつかのファイルは CRLF でないと正常に開けなかった（はず）ため、じゃあってんで全部 CRLF になるようにしていました。今の git リポジトリの状態はそれを踏襲したものになります。 Git for Windows の設定も autocrlf=false にしています。

今後 Linux で使えるようにしようと考えると、改行が CRLF な状態は好ましくない（リポジトリ内が CRLF でチェックアウト状態が LF という設定はできない）かなぁ、と思い始めているのですが、リポジトリ内の改行を CRLF から LF に変更するとそのタイミングで blame での変更追跡が切れる、という問題が発生します。うーん。まあ仕方ないですが…

ちなみに、svn 時代はリポジトリは公開されていなかったのですが、その頃に CRLF になっている src zip を LF に変換して fork (?) している github リポジトリがあるのを見たことがあります。