或るプログラマの一生

(This article is English translation of Japanese version)

I found that the video clips that I generated are not compressed very much. The compression ratio is 1.06 in case of AMV4/DR2. I think it is not good and have to search other clips.

クリップを作ってみたけど圧縮してみたら全然圧縮できないことに気づいたわけです。ちなみにこのあと AMV4 の DR2 で圧縮してみたら圧縮比 1.06 になってしまい、いやこれはさすがにダメでしょと思い、ちゃんと圧縮できるクリップを別途用意することにしました。圧縮できないクリップもそれはそれで計測価値があるので crowd_run も使います。

先日の記事で作った4Kのクリップをザックリ圧縮してみました。

その他

• UQxx: フレーム分割数のデフォルトが論理プロセッサ数と同じになるようにした。

(This article is English translation of Japanese version)

I use full HD video clips to benchmark Ut Video Codec Suite and other video codecs. When I began to benchmark codecs, using full HD video clips is a reasonable choice. However, measurement error is not ignorable nowadays because recent codecs including UtVideo are very fast and they take only 1ms to process one frame in case of YUV420. Because so, I’m planning to switch to 4K video clips. (The author of MagicYUV also advised me to do so)

現状、 Ut Video Codec Suite などの性能測定にはフルHDのクリップを使っています。使い始めた頃はこれでよかったのですが、UtVideo 自身の高速化や他の高速なコーデック（具体的には MagicYUV）の登場により1フレームを処理する時間が内部形式によっては1msを切る時代になり、そろそろ計測誤差を無視することができなくなってきました。そのため、次は4Kのクリップを使おうと考えています。（というか、MagicYUV の作者にそうすることを勧められた）

vcpkg という、 Microsoft が Visual C++ 向けに作っている（つまり、基本的にはライブラリをパッケージングするための）パッケージシステムがあります。

私は UtVideo のユニットテスト部分で boost と ffmpeg を使っているのですが、手打ちでビルドしていてかなりめんどくさいし、他人が UtVideo をビルドしようとした時に輪をかけてめんどくさいことになることが想像されるため、これが簡単になることを期待しています。

性能向上

• UQxx: 全体的に高速化した。

i386/x86_64 向けの GCC/Clang のインラインアセンブラで "i" 制約によって定数を埋め込む時、AT&T 記法の場合だと $ プレフィックスが付きます。 AT&T 記法の場合は即値にプレフィックスを付けることになっているので、この挙動は妥当です。即値にプレフィックス付けなくてもアセンブルはできるようですが。（今試して気づいた）

その２の続き

2要素の場合で既にかなり残念なことになっていますが、3要素の場合はどうでしょうか。