グラフ１ 平均二乗誤差
喉が痛い鼻水が止まらない頭が回らない。というわけで馬鹿が春風邪を引いて日曜には作業が進まず、今日も PS のコードから今までのエンバグを選り分けただけでダウン。
つかこのペースで作業していたらいつになったら完成させられるか判らない。せめてあちらで 204 byte TS の知識が必要になる前には何とか 188 byte TS だけでも扱えるようになっておきたいものだったりするのだけど、望み薄かな〜。
忙しさに紛れて気がつかない内に、桜も殆ど散ってしまっているし、YANG KING OURS の４月号は買い逃してるし……。二宮ひかるの作品が載っていたというのに何たる不覚。
今月の目標は無理しない程度に仕事をするにしておこう。
MProbe でも買えばとか言ってしまったら、駄目なんだろうな。個人ユースで MPEG の解析機能が欲しいという人の場合。
要望を出すのは構わないと思うし、黙っているだけではそういう要望があるということに気づかれる事が無いから、主張する必要はあるのだけど。せめて、その機能を実現するためにどれだけのコストが必要で、その機能によって得られるものに、コストに見合うだけの価値があるのかを少し考えて欲しいなと思う。
金銭というのは一応それなりに共通の価値観に結びついているので判りやすいからここで例に使わせてもらうけど、MProbe は MPEG のエンコード機能も、デコード機能もない、ただ MPEG の解析と表示機能だけのソフトなのに、32 万円で販売されている。MPEG 解析機能を持った製品を作成して販売するのは、そんな価格になってしまうほど面倒なことなんだ。そして実際にその値段でも必要だから（大抵は企業ユーザだけど）買うところもある。
掲示板やメールでちょっと要望を出すのに必要な労力は非常に小さなもので、それだけで必要な機能が追加されるならそれはコストパフォーマンスが良いけれど、それを実現するために裏で必要な作業と労力をちょっとは想像してみて欲しい。
つう訳で、私ならまずそんな機能が付けない。だってスンゴイ面倒なんだもん。そんな作業してる暇があったら他のもっと優先度が高い作業を進めるし、漫画眺めたり小説読んだりアニメ見たりゲーム遊んだりもしたいから。
現在の住環境での最大の不満点は、VHF 帯が全滅に近い惨状を呈していること。ほぼアンテナと平行にそこそこ交通量の多い道路があるため、時間帯によってはパルスノイズが VHF にのりまくり、メダカが泳いだり突然ワイド画面になったり、最悪の場合コピーガードと誤認識されて録画がパーになったりする。
日曜朝など最悪で GA はまともに録画できたことがない。深夜は多少ましで、特に雪使いでは幸運な事に一切その手のノイズの被害にあわずに済んだのだが……。
天地無用 GXP ではいきなりやってくれた。起きてることだし、テープも勿体無いから NV-DM1 のメディアコンバート機能を生かして HDD 録画していたところ「不正な DV データです」との無常なエラーメッセージで止まってくれた。どうやらパルスノイズをアスペクト比情報と誤認識してくれたらしい。
カノープスもこれさえなければ完璧なんだけどね〜。せめて途中で 16:9 に変わっても無視してそのまま取り込み続けるとかできれば良いのに。その点だけは IO-DATA の GV-DVC シリーズの方が良かった（単にアスペクト比情報を反映してないだけなんだろうけど）と思う。
新番組について。天地無用 GXP はどうやら録画するなというお告げが下ったようなので止め。ちょびっつは原作を積極的に嫌っているうえ第一話を見ても駄目っぽいので止め。
HOPPY☆LESSEN ４話まで様子見。ぴたテン GA と同時間枠なのでまともに録画できるはずも無し、見て捨てる。十二国記 よっぽど駄目でない限り保存予定。
進んでるんだか進んでないのか不明な例のアレは、昨日と一昨日の作業で VIDEO ES の抽出だけなら何とか動くようになってくれた。テスト用のプログラムで分離した M2V は MSSG のコーデックで検証してもエラーが出なかったので、抽出は成功してる模様。
抽出が動くようになった時点で、さくっと組み込んでさくっと動いてくれれば嬉しかったのだけど、それは見通しが甘かったらしい。シーク周りの処理が駄目でまだまだ TS を直接扱うことはできそうにない。
とりあえず抽出して見た 1080i の m2v データで遊んで見たのだが、やっぱり MPEG はランダムアクセス向きじゃないということを痛感してしまった。GOP 毎に量子化行列がカスタマイズされてるので、GOP start_code に対してシークしてると最初の GOP が壊れた絵になってしまう。
つーか GOP タイムコードでしかシークできないくせに、シーケンスヘッダからじゃないと正常に再生できないというのは絶対に間違ってる。おまけにシーケンスヘッダ自体はストリームの頭以外ではオプショナルだったりするから、必ず GOP の前のシーケンスヘッダに戻して……てな処理にすることもできないし。どーして MPEG ってこーなんだろう。
げ、.hack てのが始まってたのか。完全にノーチェックだったので１話は見逃してしまった。設定その他がかなりツボなのでものすごく後悔してる。２話以降はとり逃さないようにしなければ。
MPEG-2 VIDEO VFAPI Plug-In を 0.5.12 に更新。TS の読み込みに対応。とりあえず 188/192/204 byte TS に対応したつもりなのだけど、D-VHS も Digital BS チューナも、CS チューナも Digital CATV も持ってないので 188 byte TS での動作確認しかしていない。
0.5.12 では表示のみ対応なのでおまけツールで範囲選択して出力しようとしても動かないはず。そっちはまだ何もコードを書いていないので、最悪「不正な処理……」でおちるかも。
試しに HD をデコードしてみたところ 3.5 fps という素晴らしい速さでデコードすることができた。P4 1.5G でこれしか出ないのははっきり言って悲しいが、これも実力だろうから仕方がない。
今のところ、TS の編集をつける場合はユニット単位でのバイナリ切り張りレベルで済ませてしまおうかと考えている。真面目に結合処理をつける場合にまた作り直さなければいけなくなるけど、TS 対応のデコーダなら先頭にゴミがついてれば無視してくれるのが普通のようなので。
acm 関連の API について調査中。今までは M4C & MS-MPEG4V2 だけのエンコード生活を送っていたのだけど、そろそろ XviD やら VP3 とかの新しいものも試してみようかと考えたのと、どうせなら音声出力機能も欲しいなと考えたので。
とりあえずは AVI で 60fps 出力とデルタフレームのサイズ制限が可能なだけの任意 codec で使用可能な aviutl 用出力プラグインにしようかと考えているが、そのうち AVI2 にも対応したいな〜とか考えている。
ただし、どうにもやる気が出ないのでやな感じ。先週からずっと風邪が抜けなくて、咳をしながら仕事してるし。すぐに治るだろうとか考えて無茶をしていたのがいけなかったのだろうか。
memmem() が欲しくなる。検索する。linux (っつーか glibc) にはあることを知る。もちっと検索する。VC には無いことも知る。さらに検索する。SNIPPETS に memmem.c を発見。コードを読む。簡易 Boyer-Moore すら使ってないことを知る。自分で作ることを決意する。
まーパターンが短かったりするとジャンプテーブル作る方が重いこともあるので、BM が一律に良いとは言い切れない。けど、BF で検索するだけのコードなら 1 分かからずに組めてしまうので、ライブラリに入れるぐらいならせめてそれぐらいやっといて欲しかった。
ただし、今回作ったのは BM 版ではなく BF 版。後で暇があったら BM に書き直す予定。多分そんな暇は無いのだろうけど。
死亡。ちょっと立ち直れそうに無い。教訓、テスト重要。
浮上。偶数月 10 日にはあの雑誌が出ていたのを忘れていた。帰りがけに読んで少し浮上。これからギスギスしてきそうでとっても楽しみ。
んーなんて安上がりなんだろう。とってもお手軽な人生。
SRS さくらに頼んでいたサーバのレンタル手続きが多少進んで、ようやく IP アドレスベースでサーバを弄れるようになった。ドメインがまだ登録手続き中なので公開はできないけど、色々と調整を進めておく予定。
とりあえず気になっていた転送速度は、職場の機械からのダウンロードで 1.6 Mbps 程度。ただし職場で、しかも昼休みの調査なのでネットワークがすいている時間帯ならもっとスピードは出るかもしれない。
折角サーバ借りても実家サーバよりも遅いか、どっこいどっこい程度だったら悲しかったけど、これなら後悔はせずに済みそう。何しろ実家サーバだと MAX でも 512kbps だから。
ただし、NTT が光 100 M 共有を家庭用で月額 5,800 から（別に ISP 料金必要）始めるらしいので、サービス提供範囲ならばそちらを使ったほうがよいのかも。
だら〜〜っと体を伸ばして何もしないで済む時間が欲しい。先週末はほぼそれに近い生活を送ることができたのだけど、その報いとして某ソフトの MPEG-1 対応がさっぱり形になっていなかったりとか、acmFormatChoose() で音声フォーマット選択ダイアログを表示できただけで止まってしまっている 60fps 汎用コーデック出力プラグインとか、やりたかった事がさっぱり片付かないままになってしまった。
個人的動機から MPEG-1 対応を優先して作業を進めているのだけど、某掲示板の某スレッドを見ていると出力プラグインの方が需要が多いのかもと考えたりもする。一応フルメタルパニックは今までとフォーマットを揃える都合から M4C で処理する必要があって、ちょびっつもぴたテンも保存してないので、個人的にはそれほど必要を感じてないのだけど。
ここでさくっと両方とも作ってしまえるようなら素晴らしいのだけど、悲しいことに私はそんな技術を持っていない。こういうときに自分の生産性の低さを痛感して嫌になってしまう。怠け癖をなくせば多少は生産性が上がるのかな〜。
今から BIND / sendmail の設定ファイルについて調べ始めるのってやっぱり間違っているような気がする。当面両方とも動かすつもりないけど。
ただ、その内 m1 や m3 を、そのまんま m1.hogehoge.jp とかで見せたいとか考えると、named.conf 他を書けた方が便利なのだよな。というわけで、往復の電車の中でプリントアウトしたマニュアルを眺める日々を送っている。
趣味のコード書きは、I フレームだけなら MPEG-1 でもまともに表示できるようになった。つーか ISO/IEC 11172-1 は持っていないので mpeg2dec でトレース出力して、デバッガ上で動かしながらそれと比較して……とか考えていたのだけど悲しいことに mpeg2dec のトレース出力は MPEG-1 だとマクロブロックレベル止まりで、DCT 係数までは見えるようになっていなかった。
現在 MPEG-2 用のトレース出力のコードを参考に MPEG-1 用のコードにもぺちぺちと書き加えて、無理やりブロックレベルトレースを有効にしている最中なのだが、コード読むのとどっちがはやいかなと時々考えてしまう。
また、調べてみたところ ISO/IEC 11172-x は PDF 形式ならばどれも１冊 44 CHF で、日本円換算で 4000 円程度と安いため購入しといた方が便利かもとか悩んでいる。ISO/IEC 13818-3 & 7 も欲しいのだけど、こちらは PDF 形式でも 188/200 CHF と購入するには非常に勇気のいる値段になっているので、暫くは購入できそうにない。
ISO も ITU のように年間３ファイルまで無料ダウンロード可能とかにしてくれればいいのにな〜と思いつつ、現在 ARIB STD-B32 の購入手続き中。どの程度詳しく書いてあるか全く判らない状態なので、かなりの賭けなんだけど 3000 円程度と安いうえ、支払方法が配達後振込み方式だったので試してみた。これで ISO/IEC 13818-7 を入手する必要がなくなったりすると非常に嬉しいのだけど、多分それはないんだろう。
とりあえず表示だけ。MPEG-1 でも何とか表示はできるようになった。本当に表示だけ。
出力まわりを放置してまで対応を進めて何がしたかったかというと、こういうこと がやりたかっただけだったりする。MediaPlayer だとフレーム移動できないのが嫌だったのと、TMPGEnc で Windows 標準の DirectShow フィルタを使っても、逆方向のフレーム移動が I ピクチャ単位だったので自力で解決することにしてしまった。
TS と MPEG-1 SYSTEM の出力にも対応できるようになったら 0.6.x に上げるつもりなのだけど、とりあえずそちらは放置して脱 M4C 方面の作業を進める予定。何とか今週末までにリリースできるようにしたいな〜と考えてる。
あー TS 読むときにかなり無駄が。映像のユニットよりも先に TS_program_map_section のユニットが入るとファイルを全部読みに行ってしまう。普通は我慢してくれないだろうからなおさないと。
とりあえず、全 PID のテーブルを作って逃げてしまうことにしよう。無駄になるメモリの量はせいぜい 32k だから最近のシステムなら屁でもないはず。
うー、MPEG-1 対応の際に sequence_display_extension が無い場合の YUV -> RGB 変換式を ITU-R BT.601 定義の YCbCr にしてしまったのだけど、これだと MPEG-2 で sequence_display_extension が省略されてる場合に問題が出るか。
MSSG の codec では ITU-R BT.709 にしてしまっていた（0.5.14 以前の MPEG-2 VIDEO VFAPI Plug-In でも同様）けど、規格ではどうするのが正しいのだろうと調べてみたところ「In the case that sequence_display_extension() is not present in the bitstream or colour_description is zero the matrix coefficients are assumed to be implicitly defined by the application.」との記述。何でもアリ予定のソフトウェアデコーダでどうやったら暗黙に定義されるんだか教えて欲しい。
NTSC なら SMPTE 170M で、英独 PAL なら ITU-R BT.470-2 System B,G のはず、1125i(1080i) の HDTV は SMPTE 240M でそれ以外の HDTV は ITU-R BT.709 と、解像度やフレームレートから決めてやるしかないのだろうか。異様に面倒なのでできればどれか一つに固定したいのだが……。いっそユーザに設定させてしまおうか。
昨日寝るタイミングを逃してしまったため脱力中。体力の無さと自己管理能力の欠如を痛感。帰ったら即寝ようと決意し、仕事をさくさくと片付けるべく作業を……すすまない。
寝不足注意力散漫状態でコードを書いているためミスが頻発しテストのたびにエラーが増えていく。小人さんなら見えるかもしれないが、神が降りてくるっつーのは絶対に嘘に違いないと確信した。
今月の C Magazine （2002, 5 月号）で興味を引いた記事があったので、あれこれと検索。相変わらず日本語検索だとさっぱりヒットしなくて英語検索に切り替える羽目に。
conditional average とか maximum homogeneity とか symmetric neighbourhood とか色々と楽しそうなキーワードを仕入れることができた。
conditional average ってのは多分 s.u. さんの aviutl_c2dc.auf が使ってるアルゴリズムなんだろう。閾値決めて、ブロック内で注目画素との差がそれ以下ならば平均処理に入れるって処理だろうから。
maximum homogenity というのは 昌達K'z さんの記事で紹介されてたアルゴリズムで、幾つかの領域の中からもっとも平坦な部分を選択してその領域内で平均化するというもの。領域のパターンで幾つかの亜種があるらしいけど……それぞれの論文の著者名を眺めていたら、何でわざわざ英語で検索しなきゃいけないのだろうと悲しくなってしまった。
symmetric neighbourhood は、注目画素近傍の 8 点から対称に 4 つのペアを作り、各ペアから注目画素に近いものを１つずつ４点選んで注目画素とあわせて５点で平均化するというアルゴリズムらしい。
楽しそうなのでもう少し調べたい所だけど、これ以上は先に出力プラグインを済ませてからにしなければ。一応今週末に作業する予定でいる。
全て予定通り。順調に作業は遅れていて、未だに設定用ダイアログの表示すらできていない。とりあえず初期リリースからはオーディオの同時圧縮機能は削除されることが決定した。
オーディオ出力機能までつけてると明日の内に公開できなそうな雰囲気であるためとりあえずは断念し、後回しを決定。これでも公開できなかったら割腹もんだよな。
ARIB-STD-B32 到着。早速斜め読み。AAC を TS に MUX する際の PES パケットのフォーマットとかを一番期待していたのだけど、その辺りの記述は見つからず。疑問に思ってもう少し詳しく調べてみると、PES パケットのストリーム ID の記述で 0xc0 〜 0xdf の所に ISO/IEC 13818-7 も含むと書いてあったりした。
手元の ITU からダウンロードした ITU-T H.222.0 を確認してみると、こちらにも確かに 0xc0 〜 0xdf に ISO/IEC 13818-7 が含まれると書いてある。あー調査不足だったか。
当然ながら MPEG-2 VIDEO 圧縮フォーマットの詳細やら AAC フォーマットの詳細などは記述されておらず、その辺は規格を参照しろという形。デジタル放送のフォーマットとして使用する場合の各パラメータの制限範囲などしか記述されていなかった。また、放送フォーマットとしては LPCM は含まれていないので、LPCM を TS に多重化する際のフォーマットも記述されていない。
新しく知ることができたこととしては、デジタル放送の場合 720x480 の SDTV クラスの場合でも、色空間の変換行列は ITU-R BT.601 の YCbCr ではなく、ITU-R BT.709 の YPbPr を使用しているらしい。
「sequence_display_extension が伝送されない場合、color_primaries, transfer_charactaristics, matrix_coefficient の各値は、それぞれ "1" と等しいものとして受信側で処理される」
ARIB STD-B32 1.2 版 P.22
って、HW MPEG-2 キャプチャボードは DVD 用に ITU-R BT.601 と同じ YCbCr で変換した上に、sequence_display_extension を付けてくれなかったりするんだけど、そゆ場合どうすれば良いものだか。
完全に自動判別の道は閉ざされてしまったので、設定ツールを修正して色空間が省略されてる時の値を指定できるようにしてやらなければいけないようだ。
嵌り所が予想以上に多く、まだ DialogProc を書いている。うーん、自前で ICCompressorChoose 相当のダイアログを描画しようとしたのが間違いだったのだろうか。出力周りにはまだ手を付けていないが、この分では本当に公開できるのか不安になってきた。
まず、ICInfo(ICTYPE_VIDEO, index, &icinfo) を実行しただけでは icinfo.szName および icinfo.szDescription が空のままであった問題の解決に２時間を費やし、ICOpen(ICTYPE_VIDEO, icinfo.fccHandler, ICMODE_QUERY) で HIC を開いてから ICGetInfo(hic, &icinfo, sizeof(icinfo)) で icinfo.szDescription で情報を得ようとすると、Canopus DV Codec や UYVY やら YUY2 やら YVYU やらは ICMODE_QUERY では ICOpen できない問題の解決で３０分。
WM_HSCROLL で LOWORD(wparam) < END_SCROLL とフィルタしておかなければ HIWORD(wparam) に妙な値で飛び込んでくるのの解決にも３０分かかってしまったし……つくづく WIN32 API SDK レベルでのコーディングに嫌気がさしつつある。
わ〜い、まだ DIalogProc 書いてる〜♪
でも後ちょっと。IDOK と IDCANCEL 書けばとりあえず Dialog 周りは終了して出力本体に着手できる予定。まあ後７時間あるし、何とかなるかな。
現在 21:00 本日あと３時間。ようやく AVI 出力の初期化周りに着手しはじめた。このペースだとちょっと無理かも。火曜の深夜には間に合わせるからそれまで我慢して……とか言ったら許されないんだろうな。ちと手抜きをすることにしょう。
結局間に合わなかった上、かなり手抜き（当初予定機能の削除）を行ってるけれども、一応 60fps AVI 出力プラグイン 0.1.0 を公開。AUF に置いてある「拡張 AVI 出力」っつーのがそれです。
現状かなり名前負けしてますが、そのうちそれなりになる予定。なるといいな。ならなきゃ駄目だ。というわけで、今日は仕事もあるのでもう寝ます。おやすみなさい。
補足。60fps 出力を使用する場合、同じ FPS のパートごとに区切って出力し最後に結合するしか方法は無いと思われます。AviUtl で選択部分のみ FPS 変更を行っていたとして、それを出力プラグイン側から知ることは……できるのかもしれませんが、現在はそのようなことを考慮せず、出力部分先頭の FPS のみを見て NULL フレーム挿入パターンを決定しています。
ので、ソースフレームレートが変動している場合は、同一 FPS のパートごとに個別出力してください。最終的に結合する際は VideoMaid を使用するのが一番楽なはずです。（多少問題のある AVI を出力しますが）
あまり詳しくない上に、LPCM で取れる実機を所有していないので推測ですが、SMPTE 302M とかを読めば参考になるのではないかなと考えてます。
LPCM/TS の規格は検索してみた限りでは SMPTE 302M が一般的なようなので、D-VHS でもそれを採用してるのではないかなと。確か SMPTE から $30 以下で買えたはずですので、どうしても必要ならば検討してみてはどうでしょう。
あそこまで香ばしい方だとは存じませんでした。実際あそこまで指摘されているにも関わらず、自己の正しさを確信し、検証を試みようともしないその態度は尊敬に値すると、私は考えます。
特定の個人を想定して記述しています。ひょっとしたら自分の事かもしれないと考えた方、貴方ではありません。ええ、これを読んで、ひょっとしたら自分の事かもしれないと考えるような殊勝な方ならば、あれほどの醜態をさらすことはないでしょうから。
売り物のはずのデジタルコンテンツをアクセス制限も掛けずに HTTP で取れる所に置いとくってのはどうなんだろう。トライアルとして公開したものだけとはいえ、リンクを削除してもコンテンツはなくならないし、ディレクトリのリスティングを禁止しててもファイル名が簡単に推測されるようじゃ何の役にも立たないって気がつかないのだろうか。
エンコード素材が溜まってきているのだけど、まだ次期フォーマットを決定しきれていないのでコードを書きつつ調査中。残り 20G 程度しか取り込めないのでちと焦っている。
と言うわけで例のプラグインに簡単な画質評価機能を追加。RGB スペースでエンコード＆デコードして平均二乗誤差と平均誤差と最大誤差を出すようにしてみた。
XviD と MS-MPEG4V2 で比較してみたのだけど、XviD ではオリジナルからの色ずれが MS-MPEG4V2 よりも大きいようで、非常に悪い結果となってしまった。データ加工が終了したら追加報告する。
まず、平均二乗誤差から。基本的にどっちもどっちなんだけど、均してみると XviD の方がちっと高い＝誤差が多い。
次に平均誤差。こちらは完璧に XviD の方が悪い。0 を中心に分散するべきなのに、XviD では分布の中心が + 方向にずれている。誤差は「ソース - 結果」という式で出しているので、XviD だと結果が平均的に 1 〜 2 小さくなる（暗くなる）傾向を持つことが判る。
最後に最大誤差。MP42 と同じレベルに行くこともあるのだけど、やっぱり全体的には XviD の方が悪い。
てな訳で、XviD 惨敗。RGB - YUV 変換で手抜きをしすぎてるんじゃないだろうか。
一応 CODEC のバージョンと符号化パラメータを書いておく。MS-MPEG4V2 は 3920 ビルドを Key:999, Compression Control:100, Bitrate:6000 でエンコード。XviD は 4/23 22:00 JST 頃の CVS ソースをそのままビルドして、quantizer=1 の CPU 自動認識でエンコード。ファイルサイズは MS-MPEG4V2 が 33M 程度で XviD が 90M。
私の設定で XviD にとって不利すぎる所があったら指摘して欲しい。
で昨日の続き。YUV - RGB 変換の手抜きと書いたけど、あれは故の無い誹謗という訳ではなく、そこそこ根拠あっての主張だったりする。
例えば、xvidcore の src/image/x86asm の rgb_to_yv12_mmx.asm や yv12_to_bgr24_mmx.asm では、除算での丸めを切り捨てにしているけれども、paddw/add 命令を一つ挿入して四捨五入にするだけで、平均二乗誤差や平均誤差は次のようにあっさりと改善する。
こういった重箱の隅じみたことを気にすると、体に良くないことは判っているのだけど、気にしだすとなかなか心から離れない。
yv12_to_bgr24_mmx では１画素（3 byte）ずつ movd で（4 byte 単位に）出してるから画面サイズぴったりのバッファを確保して ICDecompress を呼ぶと最後で必ず 1 byte はみ出して、不正な処理の原因になってくれるところとか、ICSetState() では戻り値に書き込んだバイト数を返すことになっているのに 0 を返してくれる事とか今までは気にならなかった所まで耐え難い事のように思えてきてしまう。
いや、ちょっと神経質になってるのは自分でも判っているんだ。とりあえず最高画質で出してから何処まで落としても気にならないか試そうとした最初で躓いたのが悪かった。
上記修正を加えた CODEC のバイナリは、例のプラグインで出力すると最後で落ちてしまうようになったので、もう少しテストしとく必要がある。余計な所にまで手を入れてしまったのかもしれない。あーいつになったらエンコード開始できるのかな。
えーと、120fps 出力必要ですか？
必要ないかなと考えて付けなかったんですけど、作ってまで欲しい人がいるようなので、付けます。えーと 240fps とか 480fps とか 960fps は要りませんよね？
NULL フレームでもインデックス分のサイズは必要なので微妙にサイズは増えるのですが、倍というのは異常です。デルタフレーム制限を ON にして 100 程度にしてしまってるということは無いでしょうか。あそこの単位は byte なので、それなりの数値にしてあげる必要があります。とりあえず何かおかしな動きをすることがありましたら、ログを出力させて見てください。
待っている方には申し訳ないのですが、今日はもう風呂に入って寝ることにします。つーか今朝起きて AM 10:45 だった時にはびびりました。ちょっと疲れが溜まっていたようです。一応５月は６日まで通して休めるのでその時に落ち着いて作業することにします。
微妙に拡散しつつ。
さて、このうち何処まで作業を終わらせることができるだろうか。全部は絶対無理だろうけど。せめて半分ぐらいは終わらせたい。
winsock2 の本をお探しだそうですが、Lewis Napper さんの「WinSock2.0プログラミング」ぐらいしかお勧めできるものは知りません。ちょっと書いてあることは古いですけど。
MPEG-2 VIDEO VFAPI Plug-In の YUV -> RGB 変換を SSE2 化すべく試してみている。精度も同時に上げてみたのでそれほど速くならないだろうとは思っていたものの、まさか遅くなるとは予想外だった。
あんまり厳密な計測をした訳ではないので、ひょっとしたら本当は速くなっているのかもしれない。でも適当な MPEG ファイルを選んでデコードさせてみた限りでは SSE2 版の方が微妙に遅かった。
アウトオブオーダがよきに計らってくれることを期待していたのだが、ペアリングとか厳密に考えてやらなければいけないのかも。あぁ面倒。
ちゅうわけで連休中 10 日間 AirH"─しょっちゅう切れるはレスポンス悪いは─32kbps で耐えるのは嫌だったので実家に帰還。ああ、8Mbps の愉悦。
実家に P4 は無いので SSE2 最適化調査は完全に中断。火曜に一度 DV テープ入れ替えに（泣き笑い）北の果てに帰る予定なので、その時にでも VTune5.0 の体験版で調べる予定。これから DNS サーバの設定作業進めて、拡張 AVI 出力の作業はそちらが済んでからになります。ちっと待っててください。
拡張 AVI 出力 AviUtl プラグインを Ver. 0.1.3 に更新。内部で比を持つのではなく、適当に整数比を算出して出力するように変更し、60 〜 960 fps の範囲内での任意 FPS 出力に対応。
実際に使ってみて意味があるかどうかは知りませんが、一応 960 fps 出力とかもできます。わはは。NULL フレームの分余計に（1 NULL フレーム当たり 32 byte 程度）サイズ食うだけな気もしますけど。
これから音声出力つける予定なんですけど、本編細かく 24fps パートと 30 fps パートで処理しようとする場合って音声は別に出して処理した方が楽だから付けてもあんまり意味は無いような気がします。
まあフルメタルパニックみたいにエンディングだけ 30 fps とか言う判りやすい構成の場合には音声出力付いてた方が便利かなと思ったりもするので、きっちり終わらせる予定です。
えーと DivX 5 出力でサイズが膨らんだのは、デルタフレームサイズ制限の為だったということで良かったのでしょうか。まだ DivX 5 インストールしてないのですが、他にも不具合がおきてるようでしたらインストールして調べなければいけないので、某掲示板 アニキャプスレか AviUtl スレ にでも書き込んでおいてください。
最初に acmDriverEnum に引っかかってしまったせいで、音声出力対応はあまり進展していない。大抵の人は acmDriverEnum と acmFormatTagEnum どちらが重要かと聞かれれば Driver の方じゃないかと考えると思うのだけど、どうも FormatTag を使えば Driver は要らないらしい。良く判らんが。
オーディオ圧縮ボタンを置いて、amcFormatChoose するのが嫌だったばかりに無駄な調査をする羽目になっているのが現状。なんつーか ICCompresserChoose を回避するために同じような苦労をしたのにさっぱり懲りてない。
それでもダイアログ周りに関しては大体作業は完了していて、後は acmStreamOpen して acmStreamConvert してやれば機能追加完了の予定。ただし、どうも今日中には終わりそうに無い。明日は明日で移動時間とかアレコレあるので、公開できるのは明後日以降になりそう。
８時起床。朝食をとりながら、xyzzy 2ch-mode の追っかけスレに入れてるスレッドの更新チェック。９時半に身支度を整えて外出。残金が乏しくなってきた ocv 引き落とし指定講座に少し金を移す。連休明けの平日のせいか銀行は少し混んでいた。
途中新宿にて 60 分 miniDV テープ 10 本セットを２つとアンテナケーブル２本購入。DV テープは残りが 5 本を切ったので補充のため。アンテナケーブルは 4/24 日に若松に注文して 4/27 に到着した SmartVision BS 用。
GIGABYTE の i850 メインボードで dmicfg.exe や dmiflush.exe が正常に動くか自信がないのだけど、多分何とかなるだろう。先週末は実家に帰っていたので、未だ箱を開けただけなのだけど、実物を見ると１万円のボードでは無いというのには断然同意。とりあえず本日動かせるかどうか調査予定。
１３時到着。判ってはいたものの、部屋の荒れっぷりに嫌気がさす。ここ１・２ヶ月ほど掃除機かけてなかったからな〜。埃や床に散らばる雑誌の数々を何とかしたい気持ちでいっぱいに。予定を変更して片づけから作業開始。
２２時、BIOS 消滅。わーいネタができた。つ〜か思いっきりバカな話。
てな訳で BIOS 飛ばしてしまいました。てへ。さて、今時 Socket 423 のメインボードは入手できるのだろうか。