先月から減量を開始して、現在の体脂肪率は 17〜14% で横這中。MAX 20% から MAX 18% まで落ちるのは速かったのだけど、流石にここからは厳しいようだ。とりあえず気になっていた腹回りは多少細くなってきているので、地道な腹筋の効果もあったかと喜んでいるところ。なのだけど。この余った皮さえなければもっと喜べるのに。
腹囲が 80cm に迫っていた時期の皮膚が「たるん」と余っていて引っ張れば何処までも伸びていくし、ちと腹に物を入れるとぽっこりと膨らみ出してしまうのがなんとも言いがたい。先人たちの教えによると、ほっとけばそのうち吸収されるということらしいのだが……あとどれくらいかかるのかなぁ。
6/29 株主総会後の経営近況報告会での SBI 北尾 CEO の発言
今度はあの Vodafone を買うということになったら、今度はソフトバンクが SBI を売るんじゃないか、それだけの資金調達をするんだから、こういうような話になってまた相関係数が上がる、こういう部分が出てきた。
しかし、孫さんは、実はあの Vodafone を買うっていう決める前に、SBI の比率をずいぶん落ちたから上げさせてくれんか、1000 億ぐらい投資させてくれんかと今非常に安いんでと、こう言って私のところに来ていたんです。だから売ろうなんていう発想は、彼の頭の中に基本的に無いんです。
んで昨日、8/1 付けのソフトバンクの IR 「SBIホールディングス株式会社株式の一部売却実施のお知らせ」
１．売却の概要
（１）売却株式 SBI 普通株式1,111,000 株
（２）売却先 SBI ほか(ToSTNet-2 を通じて売却)
（３）売却金額 約500 億円（一株当たり45,000 円）
（４）資金使途 借入金の返済等に充当
いやはや全く。ただでさえマーケットの信頼が薄いんだから、僅か 1 ヶ月ちょいでボロがでるようなこと言わなきゃいいのに。おまけに資金使途は「借入金の返済等に充当」でメイっぱい Vodafone がらみで大当たりだし。
えーと、北尾 CEO の発言内容に関しては SBI グループ公式ページ から 6/29 経営近況報告会の 動画配信 (プレゼン資料の 99 ページあたり) から確認可能で、ソフトバンクの IR に関しては 公式ページをニュース -> プレスリリースと辿って SBIホールディングス株式会社株式の一部売却実施のお知らせ から確認可能と。
Intel Core Microarchitecture では、128 bit の SIMD ユニットが搭載されるようになったという話だったので、以前、Pentium M や Athlon 64 で調べたものと同じベンチマークを動かしたらどうなるのか、とても興味深く思っていた。というわけで、本日 Core 2 Duo E6400 (2.13 GHz) とマザーボード、メモリを買い漁り、サブ PC の中身をそっくり入れ替えたので、結果報告。
| Core 2 Duo Conroe:2.13GHz |
Athlon 64 San Diego:2.2GHz |
Pentium M Banias:1.1GHz |
Pentium 4 Prescott:3.6GHz |
|
| SSE | 0.768 sec | 1.062 sec | 2.974 sec | 1.375 sec |
| SSE2 | 0.578 sec | 1.235 sec | 3.315 sec | 1.063 sec |
この表は、Intel がソフトウェア開発者向けに公開していた、IDCT 処理の SSE/SSE2 コードを 800 万回呼び出す処理を書いてみて、それの完了までにどれだけの時間がかかったかということを記録したもの。
Pentium M や Athlon 64 では、SSE よりも SSE2 の方が遅くなっていたので、書けと言われないかぎり SSE2 (128 bit 整数 SIMD 命令) を使うのは止めようと決意していたというのが前回までの話の流れ。
Core 2 Duo ではどうなるかというと、流石に消費時間が半分とまではいかないようだけれども、それでも Pentium 4 との比較でも SSE2 の改善率が良い (Pentium 4 では 22.7% の消費時間低減だったのに対して、Core 2 では 24.7% の消費時間低減) のは嬉しい。これなら SSE2 コードを書いてやってもいいかもしれない。
この結果からすると、エンコーダな人にとっては Athlon 64 X2 と Core 2 Duo では Core 2 Duo の方が魅力的だろう。SSE 段階での地力も違うし。円周率をひたすら計算したい人がいるかどうかは兎角として、動画をひたすらエンコードしたい人はそれなりにいるんじゃなかろうか。
二次キャッシュ 2M と、クロック 370 MHz の違いに 12,000 円の価値を見出せなかったので、昨日は E6400 を選択してしまったわけなのだが、よくよく考えてみると L2 キャッシュ 4M と 2M の違いというのは大きかったかもしれない。
L2 キャッシュが 4M あれば HD 解像度 (1920x1080) の 1 フレームが全部乗るので、うまくやれば HD ソースの 1 フレームのエンコードの間に、メインメモリへのアクセスを無くすことができる。実際、エンコーダー内部で一番処理の重い動き検索部分で何がボトルネックになっているかというと、メインメモリと CPU の間のアクセス帯域だったりするので、スピード面でかなりの差が出てきそうな気がする。
流石にここから追加で 40,000 の出費をする気にはならない & HD のソースが気軽に手に入る状況にいないので今から E6600 を買う気は無いけど……。もちっと考えてから買っとけば良かったかな。
含み＋確定損は 90〜60 を行ったり来たりという状況。先週から今日にかけての下落も非常に痛い。そんなこんなで 7/18 以降の取引履歴。
今月の取引では確定損が増えてっただけなので、税金の出入りはなし。8/18 〜 8/21 にかけての取引とか、こうして振り返って見るとあまりのセコさに悲しくなってくる。
久しぶりに 2ch DTV 板をつまみ読みしてみたところ、x264 が VfW (VCM) インタフェースでも B スライスをサポートしているということを知ったので、一応 exavi.auo での対応を試みるべく x264 の仕様を調査してみた。(使った CODEC は snapshot-20060827 を Visual C++ 2005 Express + nasm 0.98.39 環境で自力ビルドしたもの)
結果、非常に素直な実装になっているということを理解した。B Frame の Max consecutive で設定した B スライス数に到達するまで、エンコード結果のサイズを 0 で返し、それ以後は普通にエンコード順のデータを返してくる。(Max consecutive = 2 の場合、skip - skip - I[0] - P[3] - B[1] - B[2] の順で 1 フレームずつ出力してくる)
まー実際、DivX/XviD のように先頭でキーフレームを出力しているが故に、パディングバイトを利用してアプリケーション側に出力すべきでないフレームを通知するとかいう形にするよりも、先頭でサイズ 0 のエンコード結果を出してもらった方がアプリケーション側では処理しやすいので喜ぶことにしよう。(キーフレームが出てきた後でサイズ 0 のエンコード結果が出てくると、スキップと区別がつかないけど、先頭データ出力前のスキップなんてありえないので B による遅延だと判断できる)
ついでに、GOP (という言葉は H.264 には無いのだけど、判りやすいので使う) 境界でどのような処理をしているか調べてみたところ、x264 は次のような形で正しく P で終端していた。
I[0] P[3] B[0] B[1] P[6] B[4] B[5] P[9] B[7] B[8] P[12] B[10] B[11] P[14] B[13] | I[15] ...
MPEG-4 までは、次のような形で、GOP をまたぐ予測というのが普通に存在できた。
I[0] P[3] B[0] B[1] P[6] B[4] B[5] P[9] B[7] B[8] P[12] B[10] B[11] | I[15] B[13] B[14] ...
しかし、H.264 だと IDR (とりあえず I のことだと思ってくれ) で参照フレームのリセットが発生するため、MPEG-4 までのような I[15] と P[12] から予測を行う B[13] B[14] のような符号化は存在できない。
JM なんかだと手抜きをして、MPEG-4 までと同様に B[13] B[14] を (I[15] からの予測しか行わないで) エンコードしてるのだけど、x264 では GOP 終端を P[14] として閉じて、残りを B[13] としてエンコードするという望ましい形での実装になっている。
えーと DivX 6.x に関しては、後で調べるけど……多分また FourCC 増やしやがったんだろうなぁと推測。他の CODEC に影響出したくなかったので、B 関連の処理は FourCC が XVID/DIVX/DX50 の時しか実行しないようにしてたんだけど……多分 DX60 とかが増えてるんだろう。
もしこの推測が正しければ簡単に直せると思うんで、x264 対応の後でなんとかする予定。
更新。Kiraru2002 さんの exavi_vfr での修正のマージとか、DivX 6.x での fourcc 'divx' への変更対応とか、B フレーム関連処理の (スキップ周辺での) 見直しとか、ffdshow vfw が登録されている環境での設定ダイアログ落ち問題対応とか x264 の B フレーム対応とかをしたつもり。
一度きちんと書いておいたほうがいい気がしてきたので、x264 での例を使って、VfW API で B フレーム対応エンコーダを利用する場合の処理方法を書いておくことにする。
| 入力原画 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| エンコーダ出力 | skip | skip | I:0 | P:3 | B:1 | B:2 | P:6 | B:4 | B:5 | P:8 | B:7 | I:9 | P:12 | B:10 | B:11 | P:15 | B:13 | B:14 |
| デコーダ出力 | skip | skip | 0 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 |
上は x264 で B Frames の Max consecutive を 2 に、Scene Cut の Min/Max IDR-frame interval を共に 9 に設定した場合に、「入力画像をエンコーダに与えた時にどんなデータが出力されるか」と「エンコーダの出力をデコーダに与えたときに何が出力されるか」を表にしたもの。
昨日書いたように、x264 のエンコーダは Max consecutive に設定した数のフレーム数が入力されるまではサイズ 0 のスキップフレームを出力し、それ以降はエンコード順のデータを出力してくる。
また、デコーダは開始時に先頭フレームを２回出力することで、フレーム並べ替えに必要な遅延を確保し、それ以降はエンコーダに入力された順でデコード画像を出力する。
背景の赤いセルに注目すると読み取れるように、デコーダから "1" のフレームが出力されるのは、エンコーダに "4" のフレームを入力したときに出力されてくる "B:1" ("1" フレームを I:0 と P:3 からの予測で B としてエンコードしたもの) が入力されたときとなる。
このため NULL フレームを追加して表示タイミングを調整するアプリケーションは、デコーダから出力されるタイミングの後に NULL フレームを追加しなければいけないので、"1" フレームに追加すべき NULL フレームを AVI ファイルに書き込むのは "4" フレームをエンコードに与えたときに出力されるデータを AVI ファイルに書き込んだ後でなければいけない。
さらに、エンコード終了時。エンコーダにすべての入力画像を供給し終えた状態でも、エンコーダ内部には未エンコード状態のバッファデータが残っている。これを吸い出す必要があるのだけど、VfW の API ではこれを吸い出す方法としてダミーフレームをエンコーダに供給して、出力されたものを使う以外の方法が存在しない。
拡張 AVI 出力 Ver. 0.3.10 で、入力 24fps、出力 60fps 設定で、上と同じ設定の x264 を 0 から 8 フレームまでエンコードした場合の処理は次の表の形になる。
| エンコード部分 | バッファ吸出し部分 | |||||||||||||||||||||||
| 入力原画 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 8' | 8' | 8' | ||||||||||||
| エンコーダ出力 | skip | skip | I:0 | P:3 | B:1 | B:2 | P:6 | B:4 | B:5 | P:8 | B:7 | I:8' | ||||||||||||
| AVI ファイル | I:0 | P:3 | B:1 | x | x | B:2 | x | P:6 | x | x | B:4 | x | B:5 | x | x | P:8 | x | B:7 | x | x | I:8' | x | ||
| デコーダ出力 | 0 | 0 | 1 | 1 | 1 | 2 | 2 | 3 | 3 | 3 | 4 | 4 | 5 | 5 | 5 | 6 | 6 | 7 | 7 | 7 | 8 | 8 | ||
AVI ファイル行の x が入っているセルは、追加されたひとつの NULL フレームを示している。この AVI を VfW でデコードした場合に表示されるフレームの対応を示したものがデコーダ出力の行だ。
まず、先頭フレームが出てくるまでに出力される skip フレームは AVI ファイルには保存しない。このスキップフレームが出る毎に、追加すべき NULL フレーム数を記録しておくためのリスト要素を増やし、今回エンコーダに供給したフレームに付与すべきだった NULL フレーム数を記録する。
先頭フレームが出てきた時点で、デコード時の遅延に対応するために NULL フレーム数リストの要素をひとつ増やして、先頭のフレームに追加すべき NULL フレーム数を「0」に、次のフレームに追加すべき NULL フレームの数を「元々の先頭フレームに対して付与すべき NULL フレームの数 - 1」に修正する。これによってデコーダが最初に先頭フレームを二回出力してくる問題を吸収し、本来先頭フレームが表示されるべき時間だけ先頭フレームがデコード出力されるようにできる。
後は NULL フレーム数リストを回しながら、エンコーダから出力されるデータに NULL フレームを追加していくだけとなっている。
エンコード終了時（バッファ吸出し部分）では、最終フレームを NULL フレーム数リストの要素数だけ繰り返し入力し、エンコーダから出力されたデータに NULL フレームを付与して AVI に出力する。
注意しておくべき点として、分割エンコードしたデータを結合した場合、前のファイルの最終フレームが、次のファイルの先頭フレーム部分に表示される。これはどうしても避けることができない問題なので、我慢して欲しい。
なぜ CPU が販売されてるのに、SSE4 に対応した命令セットリファレンスは公開されてないんだというわけで、SSE4(Merom New Instructions)非公式リファレンス を参考に SSE4 の仕様調査用プログラムを作成。[ ファイル: sse4.lzh ]
SSE4 のニーモニックを利用したインラインアセンブラは Visual C++ 2005 Express でフツーにコンパイルが通ったので、Core 2 Duo 既に入手してて SSE4 命令使ってみたい人とかは入手しといた方がよさげ。
SSE4 命令の仕様に関しては、非公式リファレンスの推定結果は psign 系と pmulhrsw, palignr 以外では当たっていて、違っていた部分も微妙な相違程度。とりあえず SSE3 とは違って、pabs 系や psign 系、pshufb など映像 CODEC 屋に嬉しい命令が増えてるのがありがたい。abs 系と sign 系は、量子化/逆量子化で、係数の符号部分と level 部分を計算させるのに使えそうだし、pshufb では 4x4 のバイト行列の転置が一発でできる。よーやく intel もユーザのニーズというものを理解し始めたか。
CPUID でのチェックはしていないので、Core 2 Duo 以外で sse4.exe を動かすと例外を発生させて落ちる。仕様。修正するつもりはない。