或るプログラマの一生

一晩おいて思ったんですが、前回の記事での測定結果は一部直感に反するのですよね。

• SetThreadAffinityMask 等を呼ばない場合に速くなったり遅くなったりするのは、直感に合致する。たまたま別のコアにスレッドが割り当てられたら速くなるだろうし、同じコアの別の論理プロセッサに割り当てられたら遅くなるだろう。
• SetThreadIdealProcessor を呼んだ場合に（速くはならないが）遅くならないのは、直感に反する。しかも、測定時はわざと同じコアの別の論理プロセッサを優先的に使うように指示したにもかかわらず、遅くなっていない。
• job queue をスレッドごとに持たなくても速度に変化が見られない点については、よく分からない。直感ではどちらとも言いがたい。

あと、測定したのは i7-2600K SandyBridge 上なのですが、この CPU の LLC は（わずかに non-uniform access だけれども）共有なので、スレッドがコアを移動することによるペナルティは比較的小さいはずです。そのため前回の測定結果では差が見られないという可能性があります。たとえば Core 2 Quad とかだと L2 はダイごとに分かれていて、しかもダイ間は FSB という今時ものすごく遅いバスを介して接続されているので、ペナルティは相対的に大きく出るでしょう。すぐに計測できればいいんですが、今環境が無いので…（マザーやCPUはある）

というわけで、もっと詳細な計測ができるまでは、Win32 に関してはこのままにしておきます。pthread の場合は完全に新規に書くことになるので、もっとも単純な構造にします。

Ut Video Codec Suite はマルチスレッドエンコード/デコードをサポートしています。ULxx においてはスレッドへの分割は映像を横長の帯（これを band といいます）に分割して割り当てるのですが、分割後の処理中にスレッドが CPU コアをまたぐとキャッシュミスして遅くなるので、以下の対策を実装してあります。

バグ修正

• Windows で、入出力の幅と高さが一致していることをチェックしていない。

#534 (Ut Video Support) – FFmpeg

んっ？

注： wishlist が登録されただけであってコードが commit されたわけではない（少なくとも現時点では）

いつでも QuickTime の挙動調査。今回はちょっとだけ。

バグ修正

• Windows で、デコード時に稀にクラッシュすることがある。

UNIX ドメインソケットを使っている場合、INET ドメインや INET6 ドメインなどの場合と違って、通信相手（正確には通信を開始した相手）の PID, UID, GID を取得する方法があります。通信相手が名乗るのではなく、カーネルから情報を取ることになるので、取得した情報は信頼できます。

ちょっと必要になったので、SOCK_STREAM なソケットの場合を調べてみました。SOCK_DGRAM の場合でも取得できますが、その場合だと同一のソケットであってもパケットごとに違う相手である可能性があるため、取得がめんどくさくなります。

バグ修正

• Windows で、グローバル設定で「コーデック側で設定をグローバルに保持する」にしていると、コーデックを読み込んだときにクラッシュする。

その他

• Mac で、ベース SDK を 10.6 から 10.5 にした。

現状、Ut Video Codec Suite は、VCM、DMO、QuickTime（Mac のみ）インターフェースに対応しています。で、以前から他の環境への移植は無いの？と聞かれることがあります。具体的には FFmpeg (libavcodec) や gstreamer ですね。

機能追加

• QuickTime for Mac 用コンポーネントを追加した。RGB24/ARGB32 へのデコードのみ。とても遅い。

その他

• 入出力フォーマットのチェックがより正確になった（はず）。