引き続き 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 じゃねぇかと小一時間(ry
  • 一方で、 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 のまわりがめんどくせぇなぁ。

相変わらず QuickTime for Mac の挙動を調査しているところです。

骨組みだけ書いて走らせると、QuickTime 側がコンポーネントを開いて閉じてを無限に繰り返す状態になってしまいます。Perian にデバッグコードを仕込んで HFYU (Huffyuv ね)な AVI ファイルを開いた場合は当然ながらそうはならないので、何か実装が間違っています。試しに Perian を「HFYU だけ除いたもの」と「HFYU だけ実装したもの」とに分解してビルドしてもちゃんと動くので、コーデックを実装する際に他の要素(たとえば AVI ファイルを開くコード)も書かなければいけない、ということも無いようです。

ちょっとずつ Perian を削ってってどこがクリティカルなのか調べるしかないかなぁ…

とりあえずコーデックコンポーネントの骨組みを書いて挙動を調べているところで、ようやく Open イベントが飛んでくるようになったところです。先は長い。あと、コンポーネントの拡張子は何でもいい(.component でなくてもいい)みたいですね。

ところで、Perian を参考にして書いているのですが、Perian はよく見たらデコーダしかないんですな。エンコーダで参考になりそうなソースがあったら教えてください…

バグ修正
  • DMO デコーダで、出力フォーマットを列挙する際に矛盾したフォーマットを返していた。

Read the rest of this entry

ねんがんの うめざわのじってを てにいれたぞ!

Read the rest of this entry

自分の貧弱な市場調査(主にコンビニ)の範囲では M&M’s や マーブルチョコ 以外のコーティングチョコとしてはおそらく唯一の「森永プラスミントチョコレート」を再発見しました。さわってもベタつきにくいしミントチョコは好きなので一時期好んで買っていたのですが、見かけなくなって久しくて製造終了したのかなぁと思っていました。森永の商品情報を見ても載ってないし…

Read the rest of this entry

最初にことわっておくと、Linux には SO_REUSEPORT はない(追記: Kernel 3.9 で追加された)。Windows (Winsock) にもないし、Linux に近い環境を構成する Cygwin にもない。(Solaris はどうだったかな…) 今現在簡単に入手できる OS のうち SO_REUSEPORT があるのは、大まかに BSD に分類される OS、つまり {Free,Open,Net}BSD の系統と Mac OS X だけである。

Read the rest of this entry

blogは全く更新してませんでしたが、HARDまで陸男ペリ子ともにクリアしました。

今は HARDEST/INFERNO を進めているのですが、そろそろ今までとは同じ感覚ではクリアできなくなってきました。まあ今までが楽すぎた(INFERNO 向けの武器でやっていたので)わけですけどね。奈落とか魔軍とか勝てる気がしません。