日本橋ヨヲコ「G戦場ヘブンズドア」読了。才能と不器用の物語。気に入ったのでバシズムも本日購入してしまった。そのうち他の単行本も買うことにしよう。
ついでで、犬上すくね「ラバーズ７」も購入。帯のアオリがアレだったのでちとレジに運ぶのを躊躇してしまったけれど、これ以外の本は買っていたことだしということで。
……おかしいタイトルを書いたときにはこんな内容になるはずではなかったのに。とりあえず 9 月はアレに費やす時間が少なすぎたので、10 月はもちっと時間をかけることにしよう。未だに I すらデコードできないのは問題だ。
cvsup.jp.freebsd.org がさっきから max client で接続できず。最近穴がたくさん見つかってるからなぁ。しかし、せっかく同じ sakura.ad.jp 内に cvsup サーバがあるのに別のサーバーを指定するのもアレな気分。
明日に伸ばしても大丈夫かなぁ。こーゆー時に限って泣きを見るような気がして嫌なのだけど。
2004 年 4 月に備えて、Rec-POT 120S を分解してみた。以下、分解手順。
以上で分解完了。
上の画像で、ケース内部の左上にあるのが AC ソケット基板。右上にあるのが AC-DC 変換基板。左下にあるのが AVHDD 基板。右下にある IDE のフラットケーブルに隠れているのがコントロール基板。次の画像は AVHDD 基板を拡大して撮影したもの。
HDD 本体は通常の IDE ドライブらしく見えた。ラベルおよびコネクタ部の画像を置いておく。
現時点では HDD のコネクタを確認して、PC への物理的接続が可能のように見えたところで調査中断。Linux 等で HDD を認識してくれて RAW セクタダンプが可能であれば、暗号化されてはいるだろうけれどもソフトウェアで操作可能なデジタルデータが入手可能といえそう。
あーデジタルチューナーに普通に DVB-ASI がついてて、対応ボードさせば TS 取り込み放題の EU の人々がうらやましくなる。COWBOY BEBOP がサイコーで chobitts がカワイーと言っていた彼にしてみれば、アニメがリアルタイムで母国語で見ることができる日本人が贅沢を言うなと言いたいところだろうけど。
Game Programing Gems を注文してみた。とりあえず本屋から運ぶのが重い本に関しては amazon から買うことにしてみて、少しでも支出を抑えるべくアソシエイトプログラムにも加入。
自分が買う分に適用されるのか少し疑問だったりもするけど、適用されるなら 5% は大きいので。（ああ貧乏性）
先週末の記述に関連して、ARIB STD-B25も注文してみた。どの程度のってるのか不明だけど、少しはヒントになるかもしれないので。
どの程度本気で調べるつもりがあるかと訊かれると微妙なのだけど、プラグイン側の作業の息抜き程度には調べていくつもり。次の予定は適当な PC をでっち上げるあたり。どうやら独立した PC があった方が便利そうなので。
一月半 AC アダプタ生活を続けた結果、やはり電車移動時に PC を使えないのは耐えられないということで代替バッテリーを購入することにした。もう一年この PC を使い続けることにしよう。
購入したのは 3600mAh (39960 mWh) の PCGA-52A/L。実際に装着してみると微妙に下にはみ出していてバランスが悪いけれども仕方がないことなので諦めた。
せっかく電池を交換したことだし、OS 標準のバッテリーメータよりももう少し詳しい情報（パーセンテージではなく実際の電力値）が見れないものかとgoogleってみたもの、目的に適うソフトウェアを発見することができなかった。とりあえず Platform SDK に検索をかけてみたところ、そこそこ簡単に実現できそうだったのでコマンドライン用で試作してみた。使用した API の都合から 2k/XP 専用になっている。
同じソフトで壊れた電池を調べてみると、電圧は 11395 mV を記録しているものの、容量は 0 mWh から少しも動かず、設計容量・最大充電容量は 655350 mWh とかいうありえない数値が表示されていたので、セルの寿命が尽きたのではなく制御基板側の故障が発生したのではないかと疑っている。まあ、半分はセル交換という危険な賭けに出ても敗北に終わっただろうと、自分を納得させるためだけど。
こんな手抜きソフトでも、ソース込みであれば何かの役にたつかも知れないので、一応 btcheck.lzh に置いておく。ソース流用する場合は、もう少しエラーチェックを厳密にするべきなので、その辺は理解しておいてくれると嬉しい。
本格的に H.264 の仕事が始まってしまった。スクラッチからエンコーダーを作っていいという大変やりがいのあるお仕事なのだが、担当 PG １名で一体どこまでできると思っているのだろう。まあ、できることをできる範囲でやるしかないと諦めて JM73のソースやら ITU-T H.264 FDISを読んでいるのだが……。
MPEG-2 の TM や MPEG-4 の VM と違って、Coding Rule が明文化されてたり、doxygen 用のインラインコメントが埋め込まれていたりと、それだけ聞くと素晴らしいもののように思えるのだけど。
(in lencod/inc/global.h)
typedef struct
{
...
int *****mv_top; //!< For MB level field/frame coding tools
int *****mv_bot; //!< For MB level field/frame coding tools
int *****p_fwMV_top; //!< For MB level field/frame coding tools
int *****p_fwMV_bot; //!< For MB level field/frame coding tools
int *****p_bwMV_top; //!< For MB level field/frame coding tools
int *****p_bwMV_bot; //!< For MB level field/frame coding tools
...
} ImageParameters;
実際のコードがこれだからな〜。誰か止める奴は居なかったのだろうか。doxygen 用のコメントも、構造体＋関数ポインタ形式のコードのせいでほとんど役に立ってないし。
H.264 の概要 (Pioneer R&D 2003 Vol.13 No.1) によると、H.264 は Baseline Profile に関してはパテントロイヤリティフリーを目指して調整中とか書かれているけれども、これってその後どうなったのだろう。
これが実現できるのならば MPEG-4 のライセンスを嫌った所が飛びつくだろうから、急速に普及しそう。Baseline Profile だと、B ピクチャ、CABAC (算術圧縮)、フィールド適応符号化がないらしいけど、特に携帯向け地上デジタルならフィールド適応は不要だし、B や CABAC は演算量を考えると使えないとすれば Baseline で十分ということになるのか。
もっとも、JPEG2000 も core coding system に関してはパテントロイヤリティフリーで調整済みのはずなのに、未だに普及の様子が無いところを見ると上の予想は外れるかもしれない。
MPEG-2 VIDEO VFAPI Plug-In 0.6.39 を公開した。拡張子 ".MP2" の（MPEG-1 Audio Layer 2 ではなく）MPEG-2 ファイルが開けないという要望が来たので、今までのバグ修正とか 0.7.0 向けにテストしていて効果のあった機能などをまとめて 0.6.39 として公開した。
0.7.0 はようやく I をデコードするのに必要な部品がそろい始めた段階で、テストできるのは来週末になりそうだから、まだしばらく時間がかかる。何とか年内に表に出せるレベルにしたいところなのだけど……頑張ろう。
今回更新した DCT 係数の VLC デコード高速化だけれども、テストした大抵のファイルでは旧コードよりもはやくなってくれたのだけど、一部の低レートのファイルだと旧コードよりも遅くなることがあった。プラグインの使われ方（高レート MPEG-2 一次キャプチャからの再エンコード）を考えるとこれで問題になることは少ないと思うのだけど、遅くなったという意見が多いようならもう少し考えなければいけない。
というわけで、速くなった場合は連絡も何もいらないけれど、遅くなったとか、出力される絵が変わったとかいう場合は FTP にサンプルを放り込んで連絡をしてほしい。なおせる範囲で、もう少しはやくできないか調べてみたいから。
2ch DTV 板 H.264 スレッド 5 の「屁タレ技術屋」さんの書き込みに感謝しつつ H.264 / MPEG-4 Part 10 Tutorials" を読む。判りやすさに感激しつつ H.264 and MPEG-4 Video Compression の和訳が欲しくなる。
かといって、次世代動画符号化方式 MPEG-4 AVC/H.264 は高すぎて個人で買う気がでない。なんだか刊行予定日には半分以上仕事が終わってなきゃいけない雰囲気が漂ってるけど、とりあえずこの本を買ってもらえないか聞いてみよう。うー段々と書けないことが増えていくのか。
今日公開した MPEG-2 VIDEO VFAPI Plug-In 0.6.40 ですが「GOP タイムコードを使わない」に設定している環境の場合、更新する必要はありません。0.6.39 までは GOP タイムコードを検証するポイントを先頭と終端の二つだけだったのに対して、ファイル中間の 8 ポイントを加えて合計 10 ポイントでタイムコードの逆転などが発生していないか検証するようにしただけですので、最初から GOP タイムコードを使わない設定にしている場合は何も影響を受けません。
とりあえずこの修正で（使ってはいけないケースで）GOP タイムコードを使う可能性は下がりますが、これでも取りこぼす可能性はありうるので、安全を求める場合は設定で「GOP タイムコードを使わない」にチェックしておいた方が良いということを記憶しておいてください。[参考情報]
先週放送の「月姫」第一話をようやく見た。現段階で評価を出すのは早すぎる気もするけれど、正直微妙。原作新規書き下ろしにしてさっちん篇で１２話使い切ったらすごいけど、それはかなうことなき夢。まあ一応、技術の進歩の恩恵で録画ミスの心配は無いことだし、最後まで見ることにしよう。
あぁ、その技術の進歩も人を幸せにしてくれるだけじゃ無いんだなと悲しくなりつつ、例の作業を進めなきゃと決意を新たにする。優先順位はかなり下で、とりあえず今までに Rec-POT から移動した TS ファイルを DVD-R に退避させる作業を先に済ませてから……と先延ばしにしていたり。
誰でも一度は思いつく方法だと思うのだけど、googleってもぜんぜん人柱報告が見つからないのが不思議だ。Rec-POT HDD 換装で検索しても 80G の旧モデルでの例しか出てこないし。何か事情があるのだろうか。
設計ミスでのバグが発覚。その問題が出るということがすっぽり頭から抜け落ちてた系の最悪パターンのミス。
去年と同じ試験を受ける。過去問で調べていたはずなのに Automatic Repeate reQuest と Forward Error Correction の罠に引っかかる。一応去年よりはまともな点がとれたと思うのだけど、その辺は明日回答速報サイトを見て午前の得点から判断しよう。
午後２は意外とはやめに終わったので、帰りに秋葉原へ寄り、MSI のベアボーンキットやらいろいろと購入。結果 FreeBSD マシンがでっち上げられた。
HDD は 120GB のディスクを世代間比較したかったので 300G を。CPU は総当りを覚悟して P4 2.4C GHz を。メモリは適当に 256M * 2 を。
最悪まったくフォーマットが解析できない状態でも、せめてフルダンプ＆リストアでのムーブもどき（ハゲしく不便だが）はできると思いたいのだけど、書き戻してそれ以降使えなくなったらショック大きいだろうな〜。
そんなこんなで、土曜は試験対策の一夜漬けで潰れ、今日も今日で時間が取れずにプラグイン側の作業は 0.7 向けも 0.6.x のバグ修正も進んでいない。
むー MME で編集した場合に AC3 オーディオの不正フレームが頭と尻尾に付くというバグレポートにはどう対処するべきか。AC3 音声は対応してないから、当然の結果なんだけど、どう返事を書くべきか悩む。
2ch UNIX 板「ニャース、ML、キテガイリスト 14 人目」のリンクから ネットピープル分類学 その傾向と対策 へ。オチまで読んで（職場だというのに）ひとしきり笑ったあと、自己評価を試みる。
むー謎めき系＋薀蓄系かなぁ。昔話系や軽薄系・粘着系は入ってないはず。
４月１２日（木） 通勤時間倍とかが謎めき系のいいサンプルで１２月１８日（月） 縮小アルゴリズムなんかが薀蓄系の……というにはちと倨傲さが足りないか。とりあえず、上のページの資料は対策側が素晴らしく有用で、実践できれば仕合せ間違いなしだったりするので一読を推奨。
テクニカルエンジニア（ネットワーク）試験。午前の自己採点結果は 39/50。ぎりぎりで足切ラインは通過できた模様。しかし、RARP の問題で脊髄反射で IP -> MAC をマークしていたのが悔やまれる。リバースだから MAC -> IP と判っていた筈なのに、選択肢を今日読み直すまで逆を解答してたのに気がつかないとは……。
0.6.41 がまだ公開できない。このバージョンで修正される予定のバグは「MPEG 的に正しい連番ファイルの読み込みで、オーディオストリームの長さが最終ファイルのオーディオの長さになってしまう」件。とりあえずコードは一通り書き終わって、オーディオの長さは正しく取れるようになったのだけど、今度はシークの際にファイル境界で無限ループに落ちるバグが出てきてしまったので、そちらの原因調査中。
非常に恥ずかしいタイプのバグだし、10/15 に報告を受けてからもう一週間経つので早くなおしたいのだけれども、設計ミスに由来する作業量の増加と、試験対策の必要によってこんな羽目に。多分今晩の作業でシーク時の無限ループは潰せると思うので、他のエンバグが無ければ明日には公開できるはず。
AVHDD 側の話。Rec-POT から外した SV1204H は新しくでっち上げた FreeBSD マシンに接続したところ、通常の IDE HDD として認識され、dd による RAW セクタダンプにも成功した。とりあえずフォーマットがわからない状態で 120G のデータを眺めるのは嫌だったので、昨日の「まぶらほ」第２話の録画前と録画後の２世代で RAW ファイルを作成。後は差分ポイントを中心にファイルを眺めて、HDD フォーマット等の推測予定。
そんなこんなで、MPEG-2 VIDEO VFAPI Plug-In 0.6.41 を公開。これで 0.7.0 の開発に戻れる……はずなんだけど、今回の修正で適当にごまかしてしまった部分をどうするか悩みが深い。
何とか PS/TS では PTS ベースのシークで済ませたいところなのだけれども、単純なバイナリ分割と、分割点（結合点）で PTS がリセットされる場合とで二通り読み込みルーチンを用意するのもアレな気分。正直、複数ストリームを考慮しつつ全部スキャンするに心が傾きつつある。（流石に映像で一回スキャンして、オーディオでももう一回スキャンしてってのは許されないだろうけど……）
AVHDD の方もバッチで流せるものはどんどんやっておかないとな〜。とりあえず RAW イメージを比較して、相違点のオフセットを見た限りでは普通に先頭領域にセクタとのマッピングテーブルがあって、対応セクタに TS データが書き込まれるという常識的なフォーマットのような印象を受けた。この次は、相違点を RAW イメージから切り出して先頭領域のテーブル部分と思われる部分を実際にバイナリエディタで比較するのと、後半のデータ部分と思われる部分で 0x47 の出現頻度を調べる予定。
0x47 が 188/192/204 バイト毎に出現しているようなら AVHDD としての独自暗号化は無しで、生の TS が入れられていると判断できるのだけど……そんな期待は持たない方がいいのだろうな〜。
う〜む。そんなに BT.601 のページって判りにくいかな。確かに実例が少ないから判りにくいかもしれないんだけど……。CODEC 毎の YUV/RGB 変換表 (YUY2 で Y=235,U=128,V=128 のデータを渡して圧縮して、RGB でデコードして調査) とか、DirectDraw YUV/RGB オーバーレイと GDI の比較するツールとか作って VGA 毎の特性比較とかしてあげなきゃいけないものなのだろうか。
0.6.41 でエンバグしてしまったので、MPEG-2 VIDEO VFAPI Plug-In 0.6.42 を公開。ファイル読み込み部分を富豪的プログラミングから伝統的プログラミングへ変更したのが失敗の元だったのかなと思いつつ、元に戻すのもアレなので抜けパターンを回避するコードを追加。
これで全部塞げたはずなんだけど、またバグ報告が入ってきたら落ち込むだろうな〜。
Rec-POT の末路。リムーバブル HDD ケースへと電源延長ケーブルと長めの IDE ケーブルで接続され、蓋は開いたままの状態に。[写真]
AVHDD はテーブル領域まで含めて全体で暗号化されているらしく、差分ひとつだけではさっぱりフォーマットの推測がつかないので、もう数世代追いかけてみる必要がある。しかし、いちいちその度にケースを開けたりするのは面倒だし HDD 側の IDE コネクタに負担をかけるのもよろしくないだろうということで、こんなことに。
一応差分を眺めた結果判ったこととして、暗号フォーマットは 8 byte (64 bit) 単位のブロック暗号らしい。これで、差分を数世代眺めてれば暗号アルゴリズムから秘密鍵まであっさり判ってしまうような弱々の俺暗号つかっててくれれば最高なんだけれども、いくら松下でもそこまでアレでは無いはず。
64 bit ブロック暗号というと有名なのは DES だけど……とりあえず DES が使われてると仮定して調べてみるか。むぅ。おおっぴらに続けるのが微妙な領域になってしまったなぁ。
ちと発想を変えて、「AVHDD 暗号」で google。結果、C2 暗号 (Cryptomeria Cipher) から順繰りに 4C Entity まで到達し、"C2 Block Chipher Specification, Rev 1.0" 他色々まで入手できてしまった。
むー暗号アルゴリズムがあっさり判明してしまった。おまけに pdf に C のコードまで載ってる。後は総当りで鍵を見つけるだけか……。既知平文攻撃から選択平文攻撃までやりたいほうだいな以上、後は本当に時間の問題だけだなぁ。
というわけで、総当りでどれくらい時間がかかるのか試算。1 G key/sec で処理できると仮定して、鍵長が 56 bit だから全鍵空間の走査に 20016 時間で 2 年半。ちと現実的ではないなぁ。解説を読んだ限りだと DES の親戚のようだし、同じような弱点が調べれば見つかるかも。
予備調査はほぼ完了し、資料もだいぶ集まったので、今までに判ったことを整理。
同一モデルの HDD フルコピーでも AVHDD ボードに HDD が認識されなかったのは、HDD のシリアル等から CPRM で言うところのメディア鍵が作成されて、そこから秘密鍵が作られるせいではないかと推測している。今後は、キャプチャ後の TS を Rec-POT に書き戻して平文と暗号文を 1:1 で比較できる環境を作る予定。
どうやら 11 月放映分から wowow 無料放送は COPY ONCE 状態になってしまったらしいので、少し作業を急がなきゃいけない。
