或るプログラマの一生

先週買ってきた 2.5TB の HDD の初期不良チェックが終わったのでメインマシンに繋いでフォーマットしようとしたのですが、なぜか 300GB 弱しか認識されてません。Windows 7 なのに。インテル・ラピッド・ストレージ・テクノロジー のコンソールを見てもちゃんと 2.3TB と表示されていたはずなのに（スクリーンショットは撮り忘れたので勘違いの可能性アリ

ちょろっとググると、どうやらドライバが 10.1 以降でないとダメっぽい？（10.0 を使っていた）ので、インテルに行って最新版の 10.6 をダウンロード。ストレージデバイスのドライバを更新するのはドキドキしますが、何事もなく再起動してあっさり解決。

しかし、今年に入ってから買ったマザーなのに、添付のCDに入っているドライバが 2TB 超えをサポートしていないって点には釈然としないものがあります。

友人Mが Eearth Defence Force: Insect Armageddon (EDF:IA) を買ってきやがったので遊んでました。旧来の（サンドロット制作の）EDF とはだいぶ違うらしいし、敵（虫）のテクスチャがリアルな感じなのでちょっと勘弁願いたいし、EDF2P 終わってないしで積極的に買うつもりはなかったんですが、まあ買ってきたんなら遊ぶか、というノリです。

ちなみに記事名を「北米からの使者」ってことにしてますが普通に日本語版です。単にゲームの舞台が北米だってだけで。

箱○の方の ACV CBT に参加していました。書いてなかったけど。

しょっぱなからサーバダウンするわよくフリーズするわで大変でしたが、βテストだしバグ出しとしては妥当な結果なのではないでしょうか（出すぎな気もするけど）。発売延期になりましたが、それでもちゃんとしたものになって出てくるのかは不安だらけです。ゲームバランスはあとからいくらでも調整できる（AC4/fA でもレギュレーションの配布してたし）けど、ゲームシステムはそう簡単に変えられるわけでもなし。

さて、AC4/fA は ALL S ランクにする程度にはやりましたが、対人とは全く違うわけで、当初はオペ志望ということにしていました。が、実際のところ、オペはAC操作能力は必ずしも必要ないんですが、戦場把握能力はAC搭乗者より高いものが要求されるわけで、考えが甘かったな、と。チームに入った後は中量二脚で練習してましたけど、ものすごい勢いで囲まれて落とされまくっていててんでダメです。オペになったらなったであまり役に立たない…というかAC搭乗者の皆さんの方が能力が高くて、せいぜい敵をマーキングするぐらいしかやってませんでした。

感想とか要望とかまとめないとなー

そういえば昔（1年ちょっと前）、KMC（京大マイコンクラブ）が IRCnet に参加して、国内の特定ブロバイダからのみ接続を受け付けるようにする、という話がありました。 過去記事1 過去記事2

バグ修正

• ULY2: DMO エンコーダで、RGB24/32 以外のフォーマットで入力すると、自分で提示した出力フォーマットを受け入れていなかった。
• ULY0: DMO エンコーダで、RGB24/32 以外のフォーマットで入力すると、自分で提示した出力フォーマットを受け入れていなかった。

その他

• DMO エンコーダおよびデコーダで、入出力フォーマットをチェックする際に、一部のパラメータをチェックしないようにした。

Ut Video Codec Suite では既にサポート外にした YVYU フォーマットですが、アップルの記事を見ていたらバイト順序について疑念が出てきました。

FOURCC.org の記述を見ると、バイト順序は Y0 Cr(V) Y1 Cb(U) となっていますが、アップルの記事によると k2vuyPixelFormat = UYVY を4バイト単位でエンディアンを逆転した Y1 Cr(V) Y0 Cb(U) と説明されています。つまり、輝度の情報が逆になっています。

「ほとんど使われていない」フォーマット (“This is not a common format.”) であるし、再サポートする気もないのですけど、どちらが正しいんでしょうかね。

とにかく QuickTime の技術的メモ

• AVI ファイルを開いてデコーダにフォーマットが渡されるとき、一般的な情報（幅、高さ、dpi、など）以外は BITMAPINFOHEADER の状態で渡される。特に、BITMAPINFOHEADER の後ろに独自の拡張情報を格納するコーデック（Huffyuv や Ut Video Codec など）は、このことを知った上で情報を取り出す必要がある。
• これはつまり、コーデックは自分の拡張情報がどうコンテナに格納されるかを知っていなければならない、ということである。コーデックはコンテナを知っていなければならない。（拡張情報が不要なコーデックの場合はこの限りではない）
• 一方、インポーター（データストリームをコンテナフォーマットにしたがって解釈して映像/音声ストリームに分解するコンポーネント）は、コーデックを知っている必要はない。実際、QuickTime 標準の AVI インポーターで、 ULRG な AVI ファイルを開き、ULRG のデコーダに渡すことができる。コンテナはコーデックを知らなくてもよい。まあ、そりゃそうだ。

Ut Video Codec Suite 的には元々 AVI ファイルだけしか対応するつもりはないので、別にこれでも問題ないんですけどね。

引き続き QuickTime のメモ。

• QuickTime Player からデコーダを使う場合、CodecDecompressParams::wantedDestinationPixelTypes にデコーダから「k24RGBPixelFormat だけをサポートする」という情報を設定してやると、k32ARGBPixelFormat な PixMap が渡されてくる。お前人の話聞いてないだろ。
• 「k32ARGBPixelFormat だけをサポートする」という情報を設定してやると、これは正しく k32ARGBPixelFormat な PixMap が渡されてくる。「何もサポートしない」という情報を設定すると無限ループし、NULL を設定してもやはり無限ループする。
• よくよく調べてみると、Image Codec Reference for QuickTime には、
  

  wantedDestinationPixelTypes

  Filled in by the codec during the execution of ImageCodecPreDecompress. Contains a handle to a zero-terminated list of non-RGB pixels that the codec can decompress to. Leave set to NIL if the codec does not support non-RGB pixel spaces. The ICM copies this data structure, so it is up to the codec to dispose of it later. Since the predecompress call can be called often, it is suggested that codecs allocate this handle during the Open function and dispose of it during the Close function.

  と書いてある。つまり、RGB な pixel type はここには設定しないのが正しい状態であり、なにも設定しない = RGB のみをサポートする のはずであるが、そうなっていない。他のドキュメントを見ると、RGB な pixel type もここに設定するのが正しいような記述がある。たとえばこれ

• あと、RGB でない pixel type をサポートしない場合は NIL を設定しろ、と書いてあるが、NIL なんてシンボルは <Carbon/Carbon.h> にも <QuickTime/QuickTime.h> にも存在しない。
• ともかく、渡された PixMap の pixelFormat はちゃんと確認しないといけない。ここだけは今まで調査した範囲でも信用できる値が入っているようなので。

World IPv6 Day も終わって別に問題なさげなので、ネットワークエンジニアとしては IPv6 対応しなきゃいけないよなぁ、とは思っています。

Web サイトとして IPv6 対応するには以下が全て満たされなければいけません。

• ISP が IPv6 接続性を提供する
• DNS に IPv6 アドレス（AAAA レコード）を設定できる
• OS のサポート
• Web サーバソフトウェアのサポート

このうち、OSとサーバソフトウェアに関してはとっくの昔に対応しているので問題ありません。

DNS サービスは、ホスト名を見ての通り DynDNS を使っています。W6D 時点では Dynamic DNS では AAAA レコードには対応していなかったはずなのですが、今さっき社内 IRC でボヤいたら「いや対応してるみたいよ？」と言われました。おぅ、いつの間に… DynDNS の IPv6 Implementation Plan を見てもいつ対応したかは書いてないのですけどね。若干不親切ですが、まあいいか。

最大の問題である ISP ですが、法人向けサービスでは予定が立っているものの、個人向けサービスでは未定のようです。この調子ではまだまだ先のことになりそうです。

単なる QuickTime の技術的メモ。Mac OS X 10.6 + QuickTime 7 環境下。

• kImageCodecPreflightSelect で CodecDecompressParams::wantedDestinationPixelTypes にコーデックがサポートするピクセルタイプを設定しないと無限ループする。より正確には、QuickTime Player が扱えるピクセルタイプが設定されていないと無限ループする。
• ピクセルタイプの k24RGBPixelFormat は実際には何故か1ピクセル4バイトで←ごめん嘘、k24RGBPixelFormat だけサポートしてると返したのに k32ARGBPixelFormat の PixMap が渡されていた、バイトの並びが (A) R G B の順序でラインがトップダウンとなっている。これは、Windows BMP の BI_RGB 32bit の時にバイトの並びが B G R (A) の順序でラインがボトムアップ（biHeight が正の値の場合）なのとはちょうど逆である。なお、A の所に 0 を入れると QuickTime Player では（RGBの値が何であっても）黒になって表示されるので、お前それ ARGB じゃねぇかと小一時間（ｒｙ
• 一方で、 k32ARGBPixelFormat は QuickTime Player は対応していないようだ。
• kImageCodecDrawBandSelect で QuickTime Player 側（あるいは ImageBaseCodec 側）がコーデックに渡してくるバッファは稠密ではなく、しかもライン間の隙間の空き方が妙である。たとえば、手元の環境で k24RGBPixelFormatk32ARGBPixelFormat で幅 640 ピクセルの映像をデコードさせようとすると、最初のラインの先頭と次のラインの先頭とは 640×4=2560 バイト離れていることが期待されるが、実際には 2576 バイト離れており、16 バイトの隙間があることが分かる。Windows BMP のように「必ず n バイトアライメントにする」といった規則は無いように思える（2560 バイトは十分にキリのいい数字である）。なお、この値は ImageSubCodecDecompressRecord::rowBytes に格納されている。
• ImageSubCodecDecompressRecord::rowBytes はバッファのフォーマットが packed でないと意味のある値を保持できないように思えるので、試しに planer なフォーマットである kYVU9PixelFormat でどうなるか調べようとしたが、QuickTime Player ではサポートされないので分からずじまいであった。
• そもそも QuickTime 用語で Band ってなんなの？

rowBytes のまわりがめんどくせぇなぁ。