散財発動中。Pioneer DVR-A03-J を購入。あとまほろまてぃっく DVD の 2 巻と Corega の蟹さん NIC と MELCO の８ポートスイッチングハブも。年末とあわせると大物二つを立て続けに購入したことになるため、実弾不足状態。本当は暖房器具も買いたかったのだが、どうやらそんな余裕は無いらしい。３月までは家の中でも厚着をしてしのぐことにしよう。
さて、DVD-R/RW の話。たまっていた AVI ファイルを付属の RW で試し焼き〜としてみたのだけど。テストやらベリファイやらが入ったのもあるのだろうけれども、やっぱり 3.5G 焼くと時間がかかる。まだ PC 用データディスクを焼いてるだけだから良いけど、これが DVD プレイヤー用のディスク作成とかでトライ＆エラーという話になると間違いなく耐え切れないと思われる。
とりあえず、RW に焼いたものは DVD-ROM ドライブでも正常に読めてメディア上から AVI の再生もできたのでこれから R で本焼きに入る予定。これで CD-R の山を 1/5 に減らせて、多少は HDD を空けることができる。
つながらないと言ってしまうとかなり過剰な表現になるのだけど……住んでいるところが僻地なのかそれとも電波状況が異常に悪いのか。つながったと思っていてもいきなり反応が鈍くなりしばらく経過してからリンクが失われましたとエラーが表示されることがしばしば。
某 S 県 F 市ってそんなに文明から縁遠い場所だったのだろうか。PHS ぐらいつながるものと思っていたのに。
それから、正常に通信できている場合でもやっぱり 32kbps は遅い。職場（会社ではない）で大きめのファイルダウンロードしていて 20 k byte/sec しかでなくて遅いな〜とか考えていたのはひょっとしたら贅沢だったのかもと反省中。
つながりにくいのが単純に混雑が原因なのだとすれば、もうすこし設備を増強してもらえれば何とかなるのだろうけれども……こんな調子で春からの 128kbps サービスなんて本当にはじまるのかしらん。同時に 4 つのアンテナとリンクすることで 32x4kbps を出すとか言う目論見らしいけど。
otherwise の「未来にキスを」読了。なるほど、これは確かに評判どおり卑怯で、最高だ。GPM 系と分類したら双方から嫌がられるかもしれないけど、私の貧弱な経験と表現能力ではその分類しかできない。
同じ方がシナリオを担当してる 13cm の「フロレアール」は ED1 だけ見てあまりの退屈さに放置していたのだけど、これと同様の仕掛けがあるらしいから少し耐えてみても良いのかもと思いつつある。後で「Sense Off」も入手すべく努力することにしよう。
「フロレアール」は学生時代に自腹購入したにも関わらず、それでも ED1 を見ただけで小説の出来損ないという評価を下して HDD から抹殺してしまった。それが「未来にキスを」では、最後まで遊ぶことができたという点を評価したい。単に趣味とか前評判の影響かもしれないけど、少なくともゲームになっていると感じることができた。
ITU の勧告書はどうやら年間３本までなら無料でダウンロードできたらしい。しかも、このサービスは去年の１月から行われていたらしい。
あぁぁぁぁ、なぜ去年の内に気がつかなかったのだ、なぜ年が明けてからこんな重要なことに気がつくのだぁ〜。てなわけでものすごい後悔とともに嬉々として ITU-R BT.601-5 とか ITU-T H.222 とか ITU-T H.262 とか英語版 PDF をダウンロードしてあっという間に年間制限を消化してしまった。くそう、去年のうちに気がついていれば ITU-R BT.656 とかもダウンロードできてたのに。
今日中には無理ですが、そのうち BT.601 のページとか書き直します。いやー ITU も粋だね、３本までという制限があるにしろ、勧告書の PDF を無料ダウンロードさせてくれるなんて。ISO/IEC も見習ってくれないかな。
なお、ダウンロードを希望する場合は この辺 から登録フォームに進めます。英語だけど私でも登録できたくらいだから簡単でしょう。
GV-MPG3TV/PCI で取り込んだサンプル MPEG-2 ストリームを入手。TMPGEnc の BBS で不具合報告があったので気になっていたので m2v.vfp にデコードさせてみたところ……いともあっさり不正なアクセスを発生してくれた。
う〜ん偶然見かけたストリームを落として試してみただけなのに、こんなにもあっさり再現してくれるとは。……運が良いのか悪いのか。
というわけで、非常に恥ずかしいタイプのバグでもあるため現在原因追求中。何とか明日までに修正版を公開できると良いのだけど。
昨日書いた、GV-MPG3TV/PCI で撮った MPEG-2 ストリームを m2v.vfp に入れるとエラーを出す問題の原因が判明した。GV-MPG3TV/PCI の出力する MPEG-2 データは動きベクトルがあさっての方向を向くことがあるらしい。
720x480 の MPEG-2 で 44 個目のマクロブロックなのに、何で PMV[0][0][1] が -26 になるんだか……。あっさりとフレームの範囲外に出てしまうので、未確保の領域の参照になりアクセス違反で死亡する。
ここまで判った時点で何もやる気力がなくなり、まだ修正に着手してはいない。いや、確かに壊れた MPEG-2 入れられただけで死ぬのは問題だけど、でも壊れた MPEG-2 を出力する HW-MPEG2 ボードもどうかと思う。
年末に購入した新しいオモチャだが、こーゆーことも出来るらしい。うまいことグラフを作れば AVI からの HW-MPEG2 エンコードとかもできるのかしらん。
ちと COM とか DirectShow に完全に背を向けていたことを後悔しつつあり。どのみち DirectShow フィルタ経由だとインタレース YUV 420 が取れないし、正確なフレームの表示もできないから〜といって全部自分で作ろうとしたのは間違いだったのかも。少なくとも DEMUX の辺りは汎用の DirectShow フィルタが使えた可能性が高いから。
まーそれはそれとして JMF の Windows 用バイナリパッケージからこの辺のフィルタを弄れるのかな〜。とりあえず JMF Studio からだと DirectShow での MPEG-2 再生とかはできているようなのだけど。JMF から DirectShow フィルタのかなり深いところまで弄れるようならちょうどいいネタになるんだけどな〜。
Windows XP の 32bit システムアイコンを Common Control 上で正常に表示する方法。
以下サンプル
| Windows NT4 | WIndows XP | |
| 背景色指定 |  |
 |
| 指定せず |  |
 |
補足。TreeView で使用する ImageList では ImageList_SetBkColor() を使用する場合、TreeView_GetBkColor() を使用してはいけない。TreeView_SetBkColor() を実行前に TreeView_GetBkColor() を実行しても -1 しかかえってこないので CLR_NONE を指定したのと変わらなくなる。
正しい色を取得するためには GetSysColor(COLOR_WINDOW) を実行しなければいけない。もちろん独自の背景色を TreeView_SetBkColor() で指定してる場合は、その色を ImageList_SetBkColor() しておいてあげなければいけない。
せめて ImageList_SetBkColor() が必要なら必要と書いといてくれれば今週あんなに苦労することも無かったのに。まあ Microsoft だしということなんだろうけど。
lanczos3.auf は 0.97 系でアクセス違反を発生することがある模様。私の環境で再現したので明日までには修正できます。
lanczos3.auf 以外のプラグインは自分ではあまり使用していないため、連絡が無い限りバグに気がつかないでしょう。何か妙な動きをすることがあったら連絡をお願いします。
m4c.auo で拡張子省略時に（拡張子補完がされず）出力されない障害については回避ルーチン入れてあげればプラグイン側で対応することもできるのですけど、すぐに修正されそうな気もするので放置することにします。
奈須きのこ「空の境界」読了。1/12 から委託販売開始されていたらしいのだけれども、その事実に気がついたのが先週であったため、昨日あきばお〜４号店にて入手。15:00 から猿モードで読み始めて終わったのが 01:30。
この時代と、コミケに代表されるあの世界と、The Net に感謝を。すべてが無かったとしても、いずれ読むことのできた物語かもしれないけれども、今これが読めるのは、間違いなくその３つのおかげだから。
あの分量と体裁で上下あわせて 3000 円というのは絶対に安いので、買って後悔はしないはず。こんなことはわざわざ書かなくても、好きな人ならすでに入手済みだろうけど、それでもそう感じたということを記録しておきたいから。
lanczos3.auf のバグは、結局原因が良くわからなかった。デバッガ上では再現せず、また新しいディレクトリに新規でインストールしなおしてみるとやっぱり再現しない状態。
とりあえずコンパイラオプションを変更してみたところ、バグが発生していた環境でも再現しなくなったので更新してみた。不具合が発生している人は試してみて欲しい。
土曜に「空の境界」を買ったついでで、最安値が 35000 円を切った Deskstar 120GXP も購入。とりあえず 60G の HDD ２つに分散させていた動画ファイルをまとめて移動。
まだ容量は半分以上空いていたことだし、この値下がり具合なら 30000 円を切るのもすぐだったかもしれないので、もう少し待てばよかったのかもと思うこともあり。これでまた Digital BS と D-VHS が遠のいてしまった。今度からはもう少し冷静に行動することにしよう。
今頃気がつくのもあれだけど、フルメタルパニックはエンディングのテロップが 30fps なのね。これが 60fps とかだったら全編 24fps で作ってたところなのだけど、60fps で保存することに決定。ああ作業工程が増えてしまう。
やはりここは m4c に 60fps 出力オプションを追加するべきなのだろうか。
0.97c で更新された AUF API には、優先順が先のフィルタを適用した別フレームを参照するための関数が追加された模様。これで時報除去が別フィルタと共存しやすくなるし、領域複写もよりシンプルな形に変更することができる。
ただ、今使用してる時間軸処理が必要なフィルタがすべてあれを使うようになった日には……エンコード時間がさらに遅くなりそうだけど、まあこれは仕方が無いことだよな〜。
む〜 0.97c の VFAPI に不具合ありか。コマンドライン版の m4c 使ってるから 0.97c は使えないな〜。今日のところは mme.exe に手を入れるのを先にしようかしらん。
結合ベースに修正するまで機能追加するつもりは無かったのだけど、スクロールバーとタイムコード表示をつけるだけならそんなに大変じゃないし。192 byte TS 対応とかはいずれ気が向いたらということで。
シュガー待ちの間にペチペチとコードを書き、タイムコード表示とスライドバーの追加は完了。VFP には手をつけていないので 0.5.6a として mpeg2 に置いた時点で昨晩は力尽きて就寝。
実行ファイルだけ欲しいという方向けに MME 0.1.2 (39,667 byte) を用意しておいた。どちらも入っているものは同じなので好きなほうを落とすよ〜に。
一応一通りのテストはしたつもりだけど、多分バグがあるだろうから見つけたときは連絡をよろしく。スライドバーのドラッグ中も絵を更新して欲しいとかいう要望には応じるつもりがないので、どうしても欲しい場合は自分でコードを修正するように。mme.c の on_h_scroll() あたりでふがほげすれば解決できるから。
なんだかな〜本当に試してるのか疑問だ。150% クリップをエンコード・デコード毎に ON/OFF して４通り試してみればこのオプションが何をしているのか明らかなはずなのに。
特に Canopus DV Codec は標準だとストレートで変換してるのだから、ON でエンコードして OFF でデコードすればエンコード時の作用が、OFF でエンコードして ON でデコードすればデコード時の作用が確認できるだろうに。何であんな結論が出るのだろう。
私が試した限りでは、デコード時の作用は Y が 235 を超えるものを RGB 235 にクリップするだけで、エンコード時の作用は Y が 235 を超えるものを 255 に飛ばすようにしてる（謎な仕様だ）としか判断できなかったのだが。ひょっとしたらバージョンが違うのだろうか。私が使用してるのは初代の EZDV 付属の CODEC だから確かにかなり古いものなのだけど。
まあ実際何のためにあるのか謎なオプションで普通はずっと OFF にしとくだろこれとか感じたものだから、バグとして修正されていてもおかしくはなさそうだけど。
M4C で 24/30 fps ソースをヌルフレーム入れて 60fps 出力させるように改造。改造後の ソース
とりあえずはコマンドライン版のみ。-e オプションで 60fps 出力が発動。AUO 版は今晩作業予定。時間が余ったら解説とか書く。
柔軟で何でも可能なクラス設計と冗長で無駄なクラス設計の違いを誰か私に教えてください。
とりあえず、AUO 版も含めた 60fps オプション付き M4C の ソース一式。今のところ 24fps か 30fps のものしか 60fps 出力はできないようにしている。
ソースレベルで 60fps にしてしまうと再生が間に合わないのだけれども、24fps データに NULL フレームを加えた場合、再生自体は 24fps で行われて、表示するタイミングを 60fps で管理できるようなので、24/30 fps 混在ものの作成にはそこそこ使えるのではないかと思う。
24fps から 60fps への変換は１フレームに対して NULL フレームを 1/2 と交互につけているだけで、30fps から 60fps への変換も１フレームに対して NULL フレームを１つつけているだけ。まあ理想を言うと、60fps 出力ではなく120fps 出力で 24 からの変換には NULL フレームを４つ追加、30fps からの変換には NULL フレームを３つ追加することなんだろうけど、実際には 60fps で十分のようなのでこの形にしている。
げーん、Deskstar 120GXP 下げ止まる気配なし。うー 30000 円を切るまで待つべきだったのかな。再来週辺りには割ってそうだから悲しい。
当然のように起きていたため 10 分延長の被害は無かったのだが、後番組の放送時間変更テロップが入ったのはどーしてくれよう。何とか消せると良いのだけどかなり難しそう。
待ち時間には TS のヘッダダンプツールを作ってへこへこと遊んでいて、何とか TS の構造を理解することができた。TS の場合ユニットが 188 バイトなのでどうやってこれに PES を入れるのだろうとか不思議だったのだけど、TS のユニットって PES をバイナリ分割して 4 バイトのヘッダとアダプテーションフィールドを加えただけのものなのね。
同じ PID のユニットのデータだけを取り出して結合すれば pack が無いだけで PS とほぼ同じストリームになるみたい。対応する場合の問題点は、ランダムアクセスと先頭のゴミを如何に無視するかという辺り。先頭のゴミ無視はそんなに大変では無いけど、問題はランダムアクセスをどう実現するかなんだよね。今週末に悩むことにしよう。