或るプログラマの一生

(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: 全体的に高速化した。

ARMS、結局発売日に Amazon のオンラインコード版（買うとメールでコードが送られてくるやつ）を買いました。

パッド操作の方がやりやすいのですが、イイネ持ちの方が細かい操作ができる（が、慣れるのが難しい）のでこっちでやっています。オッサンには辛いです。1時間もできない…ｗ

あと、ARMS 合わせで発売になった Joy-Con 拡張バッテリーも買ってきました。これを付けると普通のストラップとは違って厚さが増えて握りやすくイイネ持ちしやすくなるので、電池部分に興味が無くても持ちやすくするためだけに買ってもいいように思えます。（重くなるので実際乾電池は入れずに使っている）

で、ゲーム自体はどうしているかと言うと、やる時間が取れてません。他のことをしている時に DNAマンをバレーボールでいじめて金策をしている程度です。ううむ。

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

その２の続き

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

その１の続き

要素の並べ替え（正確にはアンパック）を行う場合はどうでしょうか。 UtVideo では packed フォーマットと planar フォーマットの変換でこの処理が出てきます。

intrinsic に移行したけどそれもやっぱり辛いよね、という話を以前書きましたが、ではコンパイラによる自動ベクトル化はどれくらい使い物になるのかを調べようと思います。

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