図１ I/B/P の意味
11/20 付で、Intel C/C++ 7.0 が公開されていた模様。いちおー正規ユーザだし１年間のバージョンアップ権は有効なはずなので、試してみるべく現在ダウンロード中。
VTune も 7.0 が出てるかな〜と思って探していったけど 6.1 のままだった。6.1 は二ヶ月前に使用期限が切れてしまったから、新しいのが出てるようならまた 30 日間使わせてもらおうかと思ったのに。
インストールは成功し、ライセンスが切れているという警告も出ずに、コンパイルも成功。コンパイル後のバイナリサイズが 40k ほど増えたけど、速度面では実測値の変化無し。
メジャーバージョンが一つ上がったとはいえ、これで SSE2 コードよりも速度向上が大きかったら悲しくなってしまうところだったけれども、幸いそういう目にはあわずに済んだ。
まず、そんな人は居ないと思うけども、Intel C/C++ の正規ユーザなのにバージョンアップしたらライセンスが切れてると文句を言われるという方へ。CD ROM に入っていたライセンスファイルでは、バージョンアップはできません。
Intel の WEB でシリアル番号を登録すると、Eメールでライセンスファイルが送られてきます。そのライセンスファイルをしかるべきところに置くことで、新バージョンが使えるようになります。
節約。先月は散財が過ぎた。暖房器具（オイルヒータ）を買ったのは納得済みだからいいのだけど、本棚をもう１棹追加したり、ビデオ用のラックを購入したり、サウンドカードを買い替えたりに到ってはやりすぎたと反省。
特にサウンドカードは、24bit96kHz サンプリングに惹かれて購入したというのに WDM ドライバ経由では 16bit48kHz が限界ということが判明してショックを受けている。どれくらいショックだったかと言うと、思わず steinberg から ASIO SDK を落として、使い方を調べようとしてしまうぐらい。
とりあえずは食費から削り始めようということで、先月特売を買い込んだ 700g 128円のパスタを茹でて２週間を過ごすことが既に決定済み。耐乏生活よこんにちはといったところ。
再びアセンブラなループアンロールの日々が到来してしまった。食べていく為には仕方が無いこととはいえ、正直もちっと楽な仕事希望。ここ２週間ほどすっげー暇だったのでなんて素晴らしい職場なんだとか思ってたのに。
年内は怠けて暮らすつもりだったのだけど、塩野七生「ローマ人の物語」文庫版（１）〜（７）、福井晴敏「Twelve Y.O.」＆「亡国のイージス」、A.D.クックス「ノモンハン」全４巻と読み終わった時点でそろそろ飽きてきた。次に何をやろうかと考え中。
簡単で見返りの多いところとなると MPEG-2 プラグインの LPCM 対応なのだけれども、その後の泥沼（AC3/DTS/SDDS/AAC と果てしなく続く）が見えたりもするので、躊躇してしまう。AAC は MPEG なので多少はマシなのだけれども、LPCM/AC3/DTS/SDDS はそれぞれ好き勝手に拡張された結果、無理やり MPEG-2 PS/TS に押し込められているものなので互換性は無いに等しく、分離して ES を取り出すだけでも一苦労だったりする。
特に、LPCM に関しては主に業務用系で使われてた TS と、DVD で AC3 との共存まで考えた VOB(PS) 系で全く違うフォーマットが採用されてたりするから嫌になる。当面は「だって（LPCMやAC3は）MPEG じゃないし」と嘯いて対応作業は進めないことにしようかと。サンプル提供するから対応してとかいう要望が出れば話は別だけど。
I Only、IPP、IBP、IBBP などという単語を逸汎人の皆様は眼にしたことがあるかと思います。より逸汎的には M=3, N=15 とかいう表現もありますが普通の方には好まれません。
これらの単語は MPEG の GOP 構造を表現したものです。I Only は I ピクチャしか持たないもの。IPP は I と P ピクチャのみのもの、IBP は I,P,B ピクチャを全て使い、I/P と P の間に一つだけ B ピクチャが入るもの。IBBP は I/P と P の間に２つ B ピクチャが入るものを示します。I ピクチャとは Intra Picture の略で予測を伴わないもの、P ピクチャは Predictive Picture の略で前方予測だけ可能なもの、B ピクチャとは Bidirectionally Predictive Picture の略で双方向予測が可能なものです。
上の図 1 は、B/P ピクチャの予測方向を示したものです。MPEG-1 や MPEG-2 では I/P ピクチャのみが予測元ピクチャとして参照され、B ピクチャは予測元として参照されません。
また、MPEG-1 や MPEG-2 では予測元として参照されるピクチャは直近の I/P ピクチャ 1 枚ずつだけです。GOP 最後の P ピクチャが途中の P ピクチャを飛ばして、最初の I ピクチャを参照したりすることはありません。
MPEG-1、MPEG-2 では、I/P/B という３形式のピクチャが使用されますが、このうち P/B ピクチャはデコードの際、予測元となる参照フレームを必要とします。P ピクチャの場合は前方予測用の１枚のピクチャを、B ピクチャの場合は前方予測と後方予測用の２枚のピクチャが必要になります。このため、エンコードされた MPEG ビットストリームでは、各ピクチャが次のように並び替えられます。
図２で、上段が原画像でのピクチャ順、中段がビットストリームでのピクチャ順、下段がデコード画像でのピクチャ順になります。中段では B ピクチャが次の P ピクチャと順序逆転しています。これは B ピクチャをデコードするために必要になる、次の P ピクチャを B ピクチャよりも先にデコーダへ渡すための処置です。
このため、エンコード画像をリアルタイムでモニタする場合、原画像とデコード画像の間に最低でも B ピクチャの数 +1 フレーム分の遅延が入ることになります。ただしこれが問題になるのは USB MPEG キャプチャ製品にゲーム機を繋いで PC モニタを TV の代わりにしようとか、TV 電話に MPEG を使おうとする場合だけで、通常のファイルから再生するような場合には問題になりません。
また原画像・デコード画像でのピクチャ順から、最終フレームは I/P ピクチャのどちらかになります。MPEG-1/MPEG-2 では B ピクチャが最終フレームのピクチャタイプになることはありません。
GOP の範囲は GOP ヘッダから、次のシーケンスヘッダか、GOP ヘッダの直前までになります。また、GOP ヘッダはビットストリーム上で I ピクチャの直前にのみ挿入することができます。
このため、ビットストリームでの GOP の区切りは次の図３に示したものとなり、デコード画像での GOP 区切りは図４に示したものとなります。
図３および図４に赤枠で示した B ピクチャは、前の GOP 最後の P ピクチャからの前方予測と現在の GOP の I ピクチャからの後方予測を使用します。このように、直前の GOP を参照する B ピクチャを持つ GOP は「Open GOP（開いた GOP）」と呼ばれます。この B ピクチャは、前の GOP が存在しない場合、デコードできません。
開いた GOP があるならば、閉じた GOP もあります。開いた GOP と閉じた GOP をデコード画像の順で次に例示してみます。
| OPEN (1) | I B B P B B P B B P B B P B B I B B P B B . . . |
| OPEN (2) | I B P B P B P B P B P B P B I B P B P B P . . . |
| CLOSE (1) | I P P P P P P P P P P P P P P I P P P P P . . . |
| CLOSE (2) | I B B P B B P B B P B B P I B B P B B P B . . . |
| CLOSE (3) | I B P B P B P B P B P B P I B P B P B P B . . . |
表１で、黒い文字の部分が最初の GOP で、赤い文字の部分が２つ目以降の GOP になります。Open GOP の定義は、二つの GOP を跨ぐ B ピクチャが存在することでしたから、PBBI/PBI というパターンが存在する場合、それは Open GOP となります。
逆に言えば、P ピクチャと I ピクチャの間に B ピクチャが無ければ、それは自動的に Close GOP になります。I Only や IPP の GOP 構造の場合、B ピクチャ自体が存在しないため Open GOP は存在しません。IBBP や IBP の GOP 構造の場合は、最後の P ピクチャと I ピクチャの間で、B ピクチャを入れないようにすることで、Close GOP を実現することができます。
GOP ヘッダには closed GOP と broken link の二つのフラグが存在します。このうち、closed GOP フラグは、その GOP が閉じているか、それとも開いているかを示す為に使われます。
ただし、GOP 構造から自動的に Close GOP と決定される場合、closed GOP フラグは意味をもちません。closed GOP フラグが意味を持つのは、GOP 構造だけを見ると Open GOP に見えるけれども、実際は Close GOP という状態を示す場合です。
MPEG-1/MPEG-2 の B ピクチャは、前方予測と後方予測を使用することができて、予測の参照フレームとして使用されないピクチャ形式でした。B ピクチャでは常に双方向予測を使う必要はなく、符号化効率が最大になるよう、マクロブロック毎に双方向予測・前方予測のみ・後方予測のみ・予測無しを切り替えることができます。つまり、後方予測しか行わない B ピクチャというものも存在できるのです。
図５に赤枠で示した B ピクチャが後方予測のみの B ピクチャ、青枠で示した B ピクチャが前方予測のみの B ピクチャの例になります。ここで、赤枠で示した B ピクチャは P B B I という Open GOP のデコード画像順になっていますが、この B ピクチャは前の GOP の P ピクチャからの前方予測を持たないため、前の GOP のデータが無くともデコードすることが可能です。
GOP ヘッダの closed GOP フラグは、このように GOP 構造としては Open GOP のように見えるけれども、実際は Close GOP であるという場合を示す為に使われます。
closed GOP フラグは、任意の GOP に対して指定することもできるのですが、一般には、最初の GOP を B B I B B P . . . というデコード画像順でエンコードする場合に使われます。特に HW MPEG エンコーダではこの形式を使用するものが多いです。例としては Canopus MTV シリーズや SONY の VAIO 内蔵エンコーダ等があります。
closed GOP フラグの他に、GOP ヘッダにもう一つ存在するフラグが broken link フラグです。broken link フラグは Open GOP なビットストリームを GOP 単位編集した際に、編集ポイントとして破壊された B ピクチャが存在することをデコーダに通知する為のフラグです。
図６で、上段が入力ビットストリーム（デコード画像順）、下段が編集後ビットストリーム（デコード画像順）です。青枠と赤枠の GOP のみを残し、黒枠の GOP を削除する、ごく一般的な GOP 単位編集の例です。
赤枠の GOP 先頭の黄色で塗りつぶされた B ピクチャは削除された黒枠の GOP の情報を参照しています。そのため、この B ピクチャをデコードすると（黒枠の GOP が存在すると勘違いして）青枠の GOP を参照し、壊れた画像が出力されてしまいます。
こういったケースを避けるために用意されているのが broken link フラグです。broken link フラグが設定されることで、デコーダは、壊れたフレームが存在していることを認識して、そのフレーム表示せずにいられます。
GOP 構造の関連について解説してみました。今回はそのまとめです。前回までの６回で以下の内容を解説しました。
以上の情報は全て ITU-T H.262 で確認することが可能です。ITU-T H.262 は ISO/IEC 13818-2 (MPEG-2 VIDEO) の ITU 公開版（有料）ですが、ITU ではメールアドレス登録者に対する年間３ファイルの無料ダウンロードを許可しているため、個人でも無料で入手することが可能です。
他にも ITU では ITU-T H.222.0 (MPEG-2 SYSTEM) や、ITU-T H.261, ITU-T H.263, ITU-R BT.470, ITU-R BT.601, ITU-R BT.656, ITU-R BT.709 など MPEG に関連した勧告を公開しているので、今年の内に登録を済ませて３ファイル入手しておき、来年にもう３ファイル入手するのがよいでしょう。
ITU からの無料ダウンロードに興味がある方は ITU Electric Book Shop から "see also special information on free download" を参照してください。
６月 の IC35L060AVER07 に引き続き、IC35L120AVVA07-0 (DEC/2001) でも異音（ディスク回転時の高周波音）発生。これは今年の１月に購入したもの。
流石に２モデルで同様の異常が出てしまうと IBM 信仰を保つのは難しい。軸受け磨耗・異音発生・ディスク偏心・ヘッダ衝突・HDD 破損の坂道を下り始めた以上、早期のデータ移植が望まれる訳で節約中だというのに HDD を購入する羽目になってしまった。SATA モデルが出るまで HDD の追加購入は止めようと思っていたのに。
購入したのは Maxtor の M6Y120P0。さらば IBM。今までありがとう。
そりゃまー水平配置のマウンタじゃなくて、縦置きのマウンタに付けてたけど、前面の 8cm 吸気 FAN で冷却もしてたのに。何で１年持たないわけ？
仕事の話。DirectShow と格闘すること一週間。ようやく CTransformFilter の使い方を理解して、ますます MS のことが嫌いになった。
つーか、samples/multimedia/directshow/baseclasses/ の中の基底クラス（CTransformInputPin/CTransformOutputPin）に friend 文追加する必要があるというのはどーいうことだ。
入力 n に対して出力 1 を実現したかったので CTransformFilter::Receive() をオーバーライドしたのだけど、これってごく普通の使い方だと思うのだけどな〜。CTransformFilter の設計時に考慮されてなくても仕方がないような、特殊なケースじゃないと思うのだが。
上のは一番強烈だったものだけど、他にも RGB555/RGB565 で Video Renderer と繋ぎたい場合、biCompression に BI_BITFIELDS を 指定して、マスクビットも設定しておかなければいけないとか、ドキュメント化されてない訳の判らない仕様が多すぎて嫌になる。
冬ボーナス支給につき無駄遣い発動。ソファーとローテーブルで 80k 飛んで、福井晴敏「川の深さは」＆「終戦のローレライ」(上・下) と、高屋奈月「フルーツバスケット」(3〜10) に「.hack/SING」(6) さらにブルゲ「M&M」と購入。
そんなこんなで、気がついたら 100k 無くなっていた。なんと恐ろしいことだろう。
しかし、こうして羅列してみると、いかにも不健康な金の使い方をしている。「.hack/SING」は完全に惰性で買ってて、１回見るかどうかも怪しいし、「M&M」に至ってはデモムービーの頭の悪さだけに引かれて買ったものだし。
自分で稼いだ金をどう使おうが自由とはいえ、もっと有意義に ISO/IEC-13818-7 とか、Victor DH35000 とかを買っといた方が良かったかなと思わないでもない。
年内はなにもせずにだらけて暮らすという決意を守るべく、まずは「川の深さは」から読了。感想は、ハードカバーで買わずとも文庫になるまで待てば良かったかな、といったところ。
「Twelve Y.O.」の背景が見えたのは良い点のはずなんだけど、Apoptosis があんなものだったと判るくらいなら見ない方が良かったかなとも思う。正直 FINGER/TELNET に萎えてしまった。1996 年に Morris Worm もどきは時代錯誤じゃないかと思うのだけど。
という訳で微妙に失望しつつ「終戦のローレライ」を読み始める。私は IJN にも潜水艦にも詳しくは無いので、なんてリアルなんだと錯覚しながら、安心して読むことができるだろう。
２ヶ月あると思って作業してたのに、半分の期間が経過してしまった今になって、横から急ぎの仕事が発生。最適化なんて体力仕事なのに、今更どうしろというのだろう。
既に現状でも前より 1.4 倍速くできてるけど、仕様書に書いた作業が全部済んだわけじゃない。最低限アレとソレは片付けなければいけないので、年始休みも持ち帰り残業が決定。
これも 11 月に暇してた報い。仕方がない。
そういうわけで、仕事以外のコードいじる余裕が消失。今年の間は元々何もするつもりはなかったのだけど、加えて来年の１月末まで何もできなくなりました。２月には何とかなってるといいなー。
システムをインストールしてた HDD が死亡。ディスクは回っているのだけれども、読み出しをかけるとジージージーと暫く音を立てた後で READ ERROR を表示してくじけてしまう。
この忙しい時期にどうしてこんなことが発生してしまうのやら。システムだけでなくソースその他も入れていたディスクだったので被害は大きい。公開済みプログラムに関してはソースもサーバに残っているから問題ないけど、テスト用とか実験用のコードが失われてしまったのが非常に痛い。
壊れたディスクは IC35L060AVER07-0、 2001 8月の タイ製。既に IBM 信仰は失われていたけれど、今はまだ使えている IC35L120AVVA07-0 に対する信頼まで一気に揺らいでしまった。はやいこと代わりのディスクに置き換えることにしよう。
風邪引いた。まだ熱はそれほど上がらず鼻にも来ていないけど、喉が痛い。あまり悪化させたくはないので、夜更かしは避けようかと考えてる。
それでも最低限済ませておかねばならないことはある。とりあえず DirectX VA API で、構成のプローブと基本機能を呼び出すだけのフィルタでいいから作成を済ませておかなければいけない。
あー If-Modified-Scince と Last-Modified ですか。更新チェックかけてたりする場合は対応してた方がありがたいですよね。このサーバの場合だと、ファイルによって対応してたり対応してなかったりしてます。
具体的に言うと、日記系およびトップページは対応してなくて、その他のページおよびイメージファイルは対応してます。拡張子 ".html" は通常 HTML 扱いにしてるので Last-Modified 系に普通に対応してるのですが、拡張子 ".htm" は AddHandler server-parsed して SSI 扱いにしてるので Last-Modified 系全般に非対応なのです。
xbithack でどーにかならないかなと思って調べたことはあるのですが、その場合、.htm ファイルの更新日時が文書の更新日時になってしまい、<!--#include file="path"> で挿入してるテキストの更新日時にはなってくれなかった（いくら内容を更新しても永遠に未更新になってしまう）ので断念したのですね。これの最悪な点は、ちょっと融通の利かないキャッシュサーバを通してると、いくらブラウザ側でリロードしてもページが更新されなかったりするところです。
未更新でも更新扱いのほうが、更新してても未更新扱いよりは被害がすくないかなと判断して、現在の対応状況になってます。真面目にコレを解決しようと思ったら、静的 HTML 生成タイプの日記 CGI を導入するとか、あるいは apache をハックして、#include の場合はそれぞれのファイルで最新の更新日時を文書の更新日時にするとかになるんで、かなーり敷居が高いのですよ。