３月になってしまったので www.marumo.f2s.com は消滅した。そーいう訳で、現在は e3lt11.ocv.ne.jp の実家サーバ１台のみの運営となっている。
実家サーバとはいえ 150M/day の転送量にも耐えており、速度的にはあまり不満はないし、今のところ心配していた IP の変更もない。ocv.ne.jp がバックボーンとのルータ障害で接続不能になるのも、最近は発生頻度も下がっている。障害時の復旧も１時間程度と許容範囲内。
なのだけど、一応昔からの夢だったりするので安めのサーバを何とか丸々レンタルできないか考慮中。とりあえず InterLink だけは止めといた方が良いと理解できたのだが、そーすると同一価格帯だと SRS さくらしかないんだよね。それほど悪いうわさも聞かないし、４月にもう少し財政状況が改善したら契約してしまおうかしらん。
某仕事関係で現在作成しているネットワーク関連のクラスライブラリでドキュメントを作成しなければいけないのだが。ふと思い立ってクラス図とかを UML で描いて付けてみたら便利になるかなと考えてしまったのが間違いだった。
そのライブラリはブリッジバターンを使いまくり、これでもかというほどに実装を隠蔽しきったもの、当然実装側の詳細など書く必要は無く、UML 的なものを書こうとすれば、アプリケーション側との関係を書くしかなくなる。
で、まともにクラス図を描こうとするとアプリケーションの詳細を考えなければいけないわけで、最小構成でのクラス図とか典型的な構成でのクラス図とか……描こうとして結局面倒になって諦めた。
アプリケーション側での設計までうんぬんするのはライブラリのドキュメントとしては踏み込みすぎのような気がしてきたので。シーケンス図とかなら提供する意味があるかもしれないけど、それもテキストフォーマットでのシナリオレベルで良いんじゃなかろーかと考えてしまった。
浅海智晴「やさしい UML 入門」を購入し、今日、半日をかけて作業した結論がそれというのも悲しいものがある。まあこの知識がいずれ役に立つ日もくるだろう。多分。
ITU-R 601でフィールドオーダが規定されていたとは知らなかった。私の手元にある ITU-R BT.601-5 の英語版 PDF ファイルを仔細に調べてみても、フィールドオーダに関する記述はまったく見つけることができなかったのだが、きっとこれは私の調べ方が悪いのだろう。
何しろ、Acrobat Reader で「field」で検索してみただけなのだから、きっと見落としもあるだろう。かろうじてサンプリング構造について「Orthogonal, line, field and frame repetitive.」という記述は発見できたのだが、これはフレーム、フィールド、ラインが入れ子になった直方体構造と言ってるだけで、フィールドオーダについての判断材料にはできないし。
信号成分の範囲や変換式はフィールドオーダには無関係だし、サンプリング前に入れるローパスフィルタへの要求仕様も無関係だ。ついでに同期パルスのフロントエッジの中間からが次のラインだという規定も無関係だろうし……一体どこに記述されているのだろう。
ああ、私は ITU-R BT.601 についてというページを作っていたにも関わらず、ITU-R601 でフィールドオーダが規定されていることを知らず、また、規格文書を所有していながらフィールドオーダを規定している記述を発見することもできないほど無能であったのか。
３月から analog で表示されるアクセス数が異常に増えているようなのだけど、これは一体どうしたことだろう。１月に増加したのは AviUtl が更新されたからだと判るので謎でもなんでもなかったのだけど、今回のは referer を見てても特にリンク元が増えた様子でもないので不思議だ。
wget にしてはアクセスがばらけているから違うだろうし、新種のウィルスが蔓延しているという訳でも無さそう。後考えられることとしては f2s.com が消滅したので、そちらからの流入ぐらいだけど……そんなに f2s.com を見てた人がいたのだろうか？
こんなメールが届く日がこようとは……
この度下記の時間帯で一時的にインターネットサービスが停止致します。 お客様には大変ご迷惑をおかけ致しますが、ご理解とご協力をお願い申し上げ ます。 １．期日・時間：平成１４年３月１９日（火）午前５：００〜午前６：００ ２．対象エリア：世田谷・麻生・町田センターの全エリア ３．目 的：機器の増設に伴うＩＰアドレス変更作業 ４．そ の 他：雨天でも決行致します
ちゅうわけで、e3lt11.ocv.ne.jp は 3/19 以降、このアドレスではアクセスできなくなる可能性が大。くそう、f2s.com がまだ残っていればもう少し余裕があったはずなのに。あ〜何とかしなきゃ〜。今から適当なところを借りてとか言ってたら絶対に間に合わないので、AirH" の接続先として利用してる DION を利用することにしよう。え〜と、どうすれば登録できたかな。
昨日のメールを受けて、M3 を設置。DHCP で振られるホスト名まで変化してしまったとか、OCV 自体が死んでるとか、落雷でケーブルモデムが死んだとかの場合に M3 で告知します。トップページ以外は面倒なので置きません。SSI も使えないようなので。
えーと、実際のところ DHCP で振られるホスト名は MAC アドレスから自動生成しているようなので、IP アドレス変わってもそのまま e3lt11.ocv.ne.jp でアクセスできるかもしれませんが、その可能性だけに賭けるのは危険なので、このページ読んでる方は M3 もブックマークしておいてください。
IEEE1180 という規格が MPEG 関連で存在していて、DCT 関数での誤差の許容範囲とかが規定されている。で、MPEG.ORG から IEEE1180 に適合しているかどうかを検証するためのテストプログラムのソースが入手できたりするわけだけど……。
SSE 無しの浮動小数点 IDCT は流石にリファレンスをそのまま使用しているものだけあって、最大誤差も MSE も ME も 0 という素晴らしいものだったのだが、INT32 は微妙に MSE が基準値をオーバーしていて、MMX32 は桁あふれを起こすことがある模様。SSE は SSE で PEEK ERROR から MSE/ME まで全部基準値オーバーと全滅模様。
ええ、直します。直しますさ、くそったれ。でもちょっと時間がかかるのは許してください。
IDCT 関数の修正は進んでいない。昨日今日と都心に出かけて、ネットワークの障害が解決するのを待ち続ける仕事をしていた為に帰りが遅く、趣味のコードを調べる時間が取れなかったので。
一番はっきりした症状のあらわれる SSE IDCT については、日曜の内に一応の予備調査を済ませたのだけども、解決の目処は立たずにかえって問題の根深さを浮き彫りにしてしまう結果が出た。
まず結論から書くと、単精度浮動少数点で IDCT の定義そのままのコードを計算すると必要とする精度を満たすことができないらしい。とりあえず四捨五入をサボってたのがいけないのかと追加しても効果は無く、コサイン定数を定義する際の桁数を増やしても効果なかった。
確かに１画素あたり 64 回の掛け算と足し算が行われる訳で、float では精度がでないという結論には納得できる。
つまり、SSE で浮動小数点 IDCT を使う場合でもやっぱり LLM なり Cheng-Wang なりの最適化アルゴリズムを使って（誤差が蓄積する）計算回数を減らさなければいけないらしい。
OCV のメンテは終了して、ホスト名もアドレスも全く変化の無いまま以前と変わらずにアクセスできる幸せを噛み締めている。
何で DDNS を使わなかったかというと……正直言うと単に知らなかっただけなんだが……。無理やり理由をこじつけると、DDNS では IP アドレスの変更にしか対応できないっつーのがあるかもしれない。
例えば停電で PC が落ちてるとか、落雷でケーブルモデムが死んだりとか、OCV が 80 番のフィルタを始めたりとか、OCV-バックボーン間のルータが長期稼動で発狂して ping すら届かなくなったりとか、そういう時に DDNS だとどうにもならないけど、ミラーページか告知用ページを作っとけば２つが同時に死なない限りは連絡可能とか無意識で判断していたのかも。
後からこじつけてるわりにかなり無理のある言い訳だと、自分で書いててもそう思う。ただ、実際上で書いた四つの障害はこの１年で何度か発生してるけど、IP アドレスが変更されたのは一度も無かったのでそれほど必要性を感じてなかったり。結局今回も大丈夫だったし。一応現在は sakura.ad.jp で FreeBSD マシンを１台確保するべく手続き中だったりするので、遅くとも４月には M4 を稼動することができるかもと考えている。
MPEG-2 VIDEO VFAPI Plug-In を 0.5.11 に更新。変更内容は IDCT 関数を IEEE1180 を満たすように修正しただけ。この変更でちょっと遅くなってしまったかもしれない。
で、作業中に判明した事実。月曜に SSE 版の精度についてあれこれと書いたけど、あれは完全に勘違いで単純に浮動小数点から整数に変換する際の丸め方法を間違えていただけだった。
今までは cvttss2si で整数に変換していたのだけど、この丸め方法は絶対値が小さくなる方向へのみ。変換前に 0.5 を足して四捨五入を試してみたのが勘違いの元だった。固定小数点の算術右シフトでは丸め方向が負の無限大方向だから 0.5 相当の固定小数点値を足してからシフトすれば四捨五入になるけど、cvttss2si の丸め方法では負の場合に四捨五入にならない。
実際には機能してないのだからテストプログラムを通してみても結果が変わるわけがないのに、こちらは機能しているものとして結果を見てるから勘違いした結論が出てしまう。
で、何でこれに気がついたかというと、LLM のアルゴリズムで倍精度浮動小数点を使用したものをテストプログラムに通したときに SSE 版と同じ結果が出てしまったから。おかしいなと思いつつ非最適化版のソースを覗いたりして、丸め方法が肝だと判明。命令セットリファレンスを見れば標準で四捨五入を行う cvtss2si があり、cvttss2si からそちらに切り替えたらあっさりテストにパスするようになった。精度も整数版よりもよくなっている。
整数 LLM でも、行処理から列処理に移るところでも四捨五入するようにして精度を少し上げて、MMX では桁あふれを抑えるために行処理から列処理に移る際のパスビットを 4 から 3 に変更した。これで一応全ての IDCT 関数が IEEE1180 にパスするようになったはず。
己の矮小さと品性の下劣さに嫌気が差しつつ TS 対応作業再開。
仕事が煮詰まってたり、別のことを手がけていたり（さっぱり形になってないけど）で放置しているうちに、以前はどうやって作るつもりで、何が問題だったのかも忘れてしまっていた。まずはそこから調べなおさなければいけない。
とりあえず映像ストリームの抽出だけならそれなりに形になってた筈なので、それほど時間がかからずに住むことを期待したい。今週末に追い込みをかけて、せめてデコードだけでもできるようにしておきたいものだ。
とりあえず TS 対応の下準備として PS 側のコードを変更したのが失敗だったのだろうか。変更結果のテストを実行してみると見事に PS まで開けなくなっていた。
デバッガ上で動かし、エラーの原因は判ったものの、今度は何故今まで正常に動いてたのか不思議になってくる始末。あちらを立てればこちらが立たず、パッチがあらたなバグを生み、行き着く果てはスパゲッティ。
あー、とりあえず寝てしまうことにして後は明日また考えよう。少し整理しなければ理解できない。