画像は左から、前・前解除・現・次解除・次 の順
7/4 に備えて松下の TU-BHD250 購入。DVD 買い揃えておきながらマダ足りませんかと言われると苦しいが、9/26 から第二期も始まることだし、早めに買って使い方に慣れといて悪いことは無いだろう。D-VHS も欲しいのだけど、そちらは冬のボーナスまでお預けになる予定。
SmartVisionBS でも見れない訳じゃないんだが、そこまで PC を信頼することができないのと、ケーブルの取り回しが面倒なのと、ケースファンの騒音が嫌だったので。結局単体チューナを購入。これで冬になってから DBS チューナ内蔵 HDD+D-VHS モデルが出たら泣くんだろうな〜。
で、プログラムの方はインタレース解除も MPEG-2 も、どちらも進展なし。先週一週間はまるまるタイトルのもので遊んでいたために潰れてしまい、さっぱり進んでいない。一応日曜日に MPEG-2 関連をちまちまと作業して、発見済みバグについては潰せたのだけど、依頼されている機能の追加がまだなのと、追加で入ってきたバグ報告の確認がまだなので。公開できるのはもちっと先になる予定。
楽しい楽しい WIN32 API プログラミング。扱いにくいダイアログエディタや、覚えるたびに忘れてしまう一貫性の無い API 関数名に悩まされつつコード書き。あーホント楽しい。
一応今日中にダイアログの作成を完了させて、明日には修正版 MPEG-2 VIDEO VFAPI Plug-In を公開するつもりでいる。その為にも今日の仕事は早めに片付けておかないと。流石に 22 時過ぎに家についてから、十二国記と G-on 眺めてさらにコードを書く気力は残らないだろうし。
忘れてた。次のバージョンで修正される予定のバグリスト。
これ以外に何か不具合を抱えている方は、早めに報告をお願いします。……やっぱりバグ報告して欲しかったら BBS とか置くべきなのかなー。
MPEG-2 VIDEO VFAPI Plug-In を 0.5.22 に更新。主な変更内容はバグの修正とコンパイラの変更。Intel C/C++ Compiler でバイナリを作成してみた。
Transmeta 製 CPU でも、一応動作したので大丈夫だとは思うけれども、他の環境のことを一切考えずに /G7 (Pentium4 最適化) とかいうオプションを指定してるので場合によっては問題が発生するかもしれない。また設定ツール上で、CPU 拡張機能を全て OFF にしてもコンパイル時のオプションで、好きに SIMD 化して構わんという設定にしてあるので勝手に SSE コードを使う可能性もあり。
AMD 製 CPU を使用されている方はそれなりの覚悟をしてから使ったほうがよろしいかと。声が聞こえるようなら次からは VC 版も用意するようにします。
M4 は 21:00 頃調子が悪かったはずです。で、今後も断続的に応答が絶える可能性があります。これ の巻き添え食らって。くそう、安めのサーバを借りたのが間違いだったか。
自分のサーバは何とかするけど、隣のサーバがやられるのまでは対処できないからな〜。ルータレベルで叩き落してくれるところを借りた方が良かったのかもしれない。まず代金を払えないだろうけど。
つーか決して安くはない金を払って手に入ったものがこうなってしまうとな〜。ショックが大きい。事前の情報収集と分析を怠った報いだから恨みの向けようがないし。
先週木曜に引き続き、本日 11:10 頃から m4 死亡。近隣の IP アドレスに ping を打っても 2:8 ぐらいの割合で応答が帰ってくるので、ひょっとしたら何かに犯られてパージされてしまったのかと怯えながら、tracert の結果を添えてサポートに問い合わせてみる。
結果、リブートなら無料で引き受けてるので、希望する場合は返信してくれという回答。直ちに返事を書いてリブートしてもらい、ネットワークが復帰したのは 13:40 頃。ひょっとしたら電話で接触すればもちっと早く復活したのかも。
で、復帰後 /var/log/message やら /usr/local/apache/logs/error.log やら /var/log/cron.log を眺めてみたのだけど、今ひとつ原因不明。cron は動いていたので kernel は死んでおらず、apache の access_log から 11:10 までは生きていたと判明したのだけど、ネットワークが死んだ原因が判らない。SYN flood でも喰らったのだろうか。
てな感じで怖いことが多い（先週水曜から mrtg で NIC の受信が 500 bps 前後を保つようになってしまった）ので tcpip と stdio と act の FreeBSD 4.5 用 patch を適用して再起動。make install して reboot を打った時はこのまま再起動してくれなかったらどうしようかと怖くなってしまったけど、1 分弱で無事再起動してくれたから一安心。
あー BIND も早めに resolver の穴塞いだバージョンに変更しておかなければいけないなー。
インタレースノイズ除去関連の開発を再開。現在詰まっているのは、次の４つへのクラス分けを行う場合に、どういうパラメータを、どのように使用するかという点。
| ノイズ | 動き | 内訳 |
| なし（判定外） | なし | 動きが無ければインタレースノイズは発生しない |
| なし | あり | 30p, プルダウン独立フレーム |
| あり（回復可能） | 30p フィールドずれ, プルダウン混合フレーム | |
| あり（回復不能） | 60i |
フィールド毎の前後差分（４個）とフィールド間の相関（３個）のトータル７個までは整理できたのだけど、これ以上パラメータを削ることができないでいる。この７個から直接それぞれのクラスでの確率を出せるような便利な式があれば問題は全て解決するのだけど、そうそう都合よくは行かないのだろう。
とりあえずこの７個を記録ながらクラス分けしてみれば何か見えてくるかな〜。
当然ながら馬鹿な機械にクラス分けなどという重要なことをさせる訳には行かない（というか、それが既に出来てればこんなに苦労する必要も無い）ので、人間様がお手本を見せてあげなければいけない訳なんだが……サンプルの数に関しては心配ない、日々垂れ流されている放送を DV テープ経由でコピーした大量のサンプルが既にあるから。30 分も採れば 50000 枚以上の画像が手に入るのだから、サンプルの少なさに困ることだけは無い。
ただし、ぼーだいなサンプルを全手動でクラス分けするという苦行に耐える必要が発生するので、どうしようかという気分。つーかこんなダイアログが表示されるのを、猿の様にマウスをクリックし続けていると段々仕合せな気分になってしまう。
もう少し効率的な作業方法が無いか考える必要があるな〜。これが終わっても、次のパラメータの分析ステップをやらなきゃいけないわけだし。誰か 7 次元空間の密度分布を可視化できるような素敵なツールを知ってたら教えてください。
FreeBSD 上で NET-SNMP と MRTG から 利用中メモリ量を参照する方法がようやく判った。MRTG は Target 毎に 2 つの数字を要求する訳なのだけど、それと MRTG 設定リファレンス : 複数ターゲットの文法 で書かれてるような式をどう使えばよいのか判らなかったのだが、ようやく理解することができた。物理メモリでは総量から空き容量とバッファとキャッシュを引いたものを表示したくて、スワップでは総量から空き容量を引いたものを表示したかったのだけど、どうやって Target を書けば良いのか判らなくて悩んでいた。原文マニュアルにも同じ事しか書いてなかったし。以下調べた結果判明したこと。
で、現在使用中の mrtg.cfg のメモリモニタ部分は次のような形になっている。
Target[mem]: 1.3.6.1.4.1.2021.4.5.0&1.3.6.1.4.1.2021.4.3.0:com@ipaddr \
- 1.3.6.1.4.1.2021.4.6.0&1.3.6.1.4.1.2021.4.4.0:com@ipaddr \
- 1.3.6.1.4.1.2021.4.14.0&1.3.6.1.4.1.2021.4.1.0:com@ipaddr \
- 1.3.6.1.4.1.2021.4.15.0&1.3.6.1.4.1.2021.4.1.0:com@ipaddr
MaxBytes1[mem]: 131072
MaxBytes2[mem]: 1048576
Title[mem]: Memory Used
Options[mem]: gauge, absolute, growright
YLegend[mem]: Mem Used
ShortLegend[mem]: B
kMG[mem]: k,M,G,T,P
Legend1[mem]: memory
Legend2[mem]: swap
LegendI[mem]: mem
LegendO[mem]: swap
本当は /usr/local/share/snmp/mibs/UCD-SNMP-MIB.txt とか include して OID をシンボルで書いてた方が良かったのだろうけど、面倒だったのでそのまま記述してしまった。スワップは総量 - 空き容量だけで使用量が求まるのだけれども Target 文の仕様にあわせる為、必ず 0 を返す 1.3.6.1.4.1.2021.4.1.0 を参照してる所がアッタマ悪くてステキなところ。
木曜 BS-i 深夜の冒頭テロップに怒りを感じつつ、D2 アップコンバート由来のドット妨害をみてやっぱり DVD の方が高画質と自分を慰める日々。せめてコンポーネントソースならば……。
昨日の事だけど、何故か北京の方から「VFAPI の VF_PluginFunc::ReadData() のパラメータについて教えて欲しい」というメールが届いた。なんでも D2V ファイルを AVI に変換したいらしい。
何故私に聞くのだろうと疑問を感じつつ「m4c ダウンロードして src\vfapi_read.h/c 読めば参考になるんじゃない」という返事を翻訳サイトの助けを借りつつ書いたところ「VFAPIConv が作りたいのに m4c はそういうソースじゃない」という返答が。
それを見た瞬間の感想を正直に書くとしたら「そこまで面倒みれん」になる。実際、それ全然単純な質問じゃないし。（最初のメールのサブジェクトは One simple question だった）
てなわけで、実際に質問が行ってしまったらすごく迷惑だろうな〜と思いつつ「わたしゃ VFAPI クライアントの作り方なら知ってるけど、VfW codec の作り方なんざ知らないから力になれんよ。VFAPIConv の作者に聞いて見たら？」と返事を送ってみた。もしもそういうメールが届いてたらごめんなさい。
M4 の BIND 9.1.2 に更新。したのだけど、まだ chroot jail に閉じ込めることには成功していない。せめて特権ユーザ以外で動かすように変えたかったのだけど、/var/run/ の書き込み権限を変えるのが面倒だったのでまだそのまま動いてる。
あー予防策が重要なのはよーくわかってるのだけど、今のところは判明済みの穴を塞げたことで納得して、先のことはまた来週調べることにしよう。つーか電車の中で立ちながらノートのキーボードを打つのって面倒。片手ではシフトキーとかが打ち辛くてたまらない。
先週に引き続き機械に使われる日々をすごしている。流石に 1 フレームあたり 2 万回もマウスクリックするのは嫌だったので、あらかじめフレームタイプを設定しておき、あきらかに動きの無い部分は判定無しに、あきらかに動いてる部分は設定タイプでログを出力することにして、怪しい所だけ人間が判断するようにした。
しかし、それでも１フレームあたり数百回の判定をこなさなければいけないので非常に嫌な気分になっている。同じようにマウスクリックするだけの作業なら、まだ音声付デジタル芝居を眺めてる方が有意義に思えてくるのは何故だろう。本当は逆のはずなのに。
かといって、既に昨日古橋秀之のブラ三作品（ブラックロッド・ブラッドジャケット・ブライトライツホーリランド）と秋山瑞人「鉄コミニケーション」（１・２）を購入して読みふけっていた身としては遊ぶような余裕が残されているはずもなく。せめて今日中にある程度データをためとかないことには、明日以降に分布から判別式を考えるステップに進めなくなってしまう。
最近、某 BBS は見てなかったので気がつかなかったのだけど……いつか見たような書き込みに、いつかみたようなリプライが返り、いつか見たような議論が繰り返されている。
あー「技術的保護手段」を回避しての複製が違法なのは、著作権法第３０条の「私的利用」での複製に限った話で、著作権法第３５条の「学校その他教育機関における複製」では「技術的保護手段」を回避しても別に違法な訳ではないのだが（少なくとも法律上は）
以下、某 Intel C/C++ Compiler で P4 最適化を掛けながら出力させたアセンブラコード。
mov edx, DWORD PTR [edi+276] ;180.23
add edx, edx ;180.23
add edx, edx ;180.23
add edx, edx ;180.23
add edx, edx ;180.23
add edx, edx ;180.23
add edx, edx ;180.23
add edx, edx ;180.23
これは int array[2][32] に array[i][j] でアクセスする際の、i の添え字計算をしている部分を抜き出したもの。以下はこのコードを見た際に考えたアレコレ。
普通はこんなコードにコンパイルしないで、左シフト演算を使うと思う（というかそれを期待して２の乗数で配列作ってた）のだけど、ひょっとして２番目の推測が正解だったりするのだろうか。だとしたらすごく嫌なんだけど。
ひょっとしたら何とかなるかもと思い始めてる。インタレースノイズ除去の方。今はまだクリック地獄に耐えながらデータを集めているところだけど、大体の傾向は何となく判ってきた感じがする。
まだクラス分けの境界を確定できてないし、境界を決定できても境界線上の微妙なブロックをどのように扱うかという方針も決定できていない。ただ、フィールド間の相違量をどのように処理に組み込むかという問題は提示されるパラメータを見ながらクリックしてる内に、おぼろげながら形が見えてきた。
とりあえずパラメータ分析の方針は決定できて、分析用のスクリプトも書いたことだし、後はもう少しデータを貯めれば（30p のフィールドずれとプルダウンのオリジナルフレームについて）コードに落とせそうな感触。かなり時間がかかったけれども、振り出しからゴールまでの 20% ぐらいの所までは辿りつけたような気がする。
昨日の今日だけど、データ取りを進めていたところ現在の分類方針ではシーンチェンジに対応できないことが発覚してしまった。しくしく、データ破棄して取り直し決定。
９日に書いた分類 ではなく、ブロック毎に許容する解除方法（前解除・解除無し・次解除・二重化）を投票して、フレーム内で一番多かった解除方法を選択という形の処理にした方が自然に扱えそう。それなりに手直しが必要だけれども。
夏休み前にはけりをつけたかったのだけど、このペースで作業してるとそれはむりなんじゃないかという気がしてきた。夏休みには折角購入した ISO/IEC 11172-3 と流出物を入手した dist10.tar.gz を読みつつ MP2 対応作業進めるつもりだったのだけど、果たして着手することはできるのだろうか。
あー FF X 買うのか。今月は赤字気味だったりするんだけど、仕方が無い。
BBS を設置しておかなかったことをこれほど悔やんだことは無い。他所様に迷惑はかけたくなかったのだけど、TMPGEnc および AviUtl のサポート BBS に迷惑を掛けまくってしまっている。
どうして、全く＆ほぼ無関係なことをあそこで質問するかな〜。m4c のコンパイルは aviutl には関係ないだろうし、ffx2mov で抜き出したファイルで m2v.vfp から扱えないものがあることも TMPGEnc には無関係だし。
Q&A に追記してても、読んでくれないんだろうな〜。あー BBS 設置作業の優先順位上げとこう。
で、土日の検証作業の感想。PS2 の MPEG デコードライブラリって優秀なんだな〜。こんな MPEG 初めて見た。P が一つもなくて、I と B だけで出来てる。しかも I と I の間に入ってる B の数は２桁は普通で、物によっては３桁に到達してるのまである。
さらに、ムービーの途中で水平解像度が切り替わるのには驚き。多分容量節約の為なのだろうけれども、最初は 576x480 で途中から 704x480 になってるファイルがある。先週から某 BBS を騒がせているのはどうやらこれでエラーを出してるらしい。
対応は、無理という訳ではない。けど、かなり大規模な修正になって、埋め込んでしまうバグも増えそうだし、できればやりたくないというのが本音。それでも、画像が壊れるとしても、せめてエラーで死なないように修正だけはしておかなきゃならないんだろうな〜。
実メモリのランダムアクセス性能 は（チップセットやメモリタイプ、バスクロック等）に依存するので CPU クロックに対するレイテンシとしては表示できないんじゃないかなと思います。
L2 キャッシュに乗ってる場合はレイテンシ 7 クロックって書いてありますけど、L2 は P4 でも 8 ウェイしか無いので、ランダムアクセスなんてしたらあっさり L2 から外れてしまいますし。（L2 キャッシュのウェイ数って、確か非連続なデータを幾つまで同時にキャッシュに乗せられるかの意味だったはず）
久しぶりに Intel 日本語技術資料のダウンロード ページ覗いてみましたが、いつの間にか IDCT とか MC の SSE2 コードまで日本語 PDF が公開されてたんですね。そのうち仕事でも必要になりそうなのでダウンロードっと。
掲示板じゃなくて 影舞 とか TrackGuy (ページ到達できず）のようなバグトラッキングシステム使ったほうがよいのかも。週末に影舞を試してみることにしよう。ruby だし。
先週金曜に職場から M4 のアドレスが引けなくなってしまったので、調べてみたところ RFC 1912 の 2.4 CNAME に、CNAME を NS/MX のターゲットにするなという記述を発見。ぐ、思いっきりそれやってた。
また、もう少し調べてみると、逆引きができない場合、信頼できないホストとして DNS の応答が無視されたり、SMTP の接続が拒否されたりとかもあるという記事も発見。面倒だからと頼んでいなかった、逆引きの委譲も申請することにした。
MX レコードおよび NS レコードのターゲットは全て A レコードで同じ IP を指定するようにして、TTL も短くして、逆引きの委譲も設定完了のメールが昨日到着。全ての設定が完了してから１日以上経過してるので、今では以前の問題のある設定の応答もキャッシュから消えているはず。今まで www.marumo.ne.jp に DNS エラーとかでアクセスできなかった方、今なら正常に引けるようになっているはず。
ただ、正引き・逆引きで一貫性チェックして、アクセス元のホストの検証を行うのって、単一 IP に複数ホスト名割り当て（見栄の為）てたり、複数 IP を単一ホスト名で運用（負荷分散の為）てたりする場合にどう動くのだろう？
単一 IP で複数ホスト名の場合、IP から逆引き＆正引きして IP に戻す場合の一貫性は保証されるけど、ホスト名から正引き＆逆引きしてホスト名に戻した場合は一貫性が保証されないはず。複数 IP を単一ホスト名の場合も IP から逆引き＆正引きの際の一貫性は保証されない。（gethostbyname() で複数 IP が返ることを考慮済みの場合は別）
今は安全の為に MX と NS は同じホスト名（A レコード）指して、逆引きではそこで指定したホスト名だけを返すようにしてるのだけど、単一 IP で複数ホスト名を運用したい場合、どうするのが正しい設定なのだろう。
Avisynthを絶賛ιょぅょPART5 - 448 さん、readme.txt 読みました。取り込むのはやぶさかではないのですが、今の MPEG-2 VIDEO VFAPI Plug-In って mpeg2video.c の中で一度全て YUV 444 に補間してしまってるので、YUY2 で渡す場合はその辺りの無駄を省きたいかなと考えています。
YUV420 ->(4%) YUV422 ->(8%) YUV444 -> YUY2 という処理は明らかに無駄なので。矢印の右に書いてるパーセントはそれぞれの処理にかかってる時間が全体の処理に占める割合です。
これが RGB の場合だと YUV444 ->(14%) RGB というパーセンテージになるんですけど、YUV444 から RGB への変換のうち、７割がメモリの読み込み待ちで計算に使ってるのは３割程度なんですね。これは P3 と SDRAM 100MHz で測定した時の数値なので別環境では当然割合は変化します。
なので、YUV444 -> YUY2 はかなり気を使って書かないと、YUV444 -> RGB より遅くなってしまうことがありえます。ここで、YUV422 -> YUV444 を飛ばして、YUV422 -> YUY2 としてしまえば 8% の処理がまるまる削れる上に、最終出力時のメモリ参照量が減るのでかなりの高速化が期待できます。
うげげ、P4 だと本気で shl 1 個と add 8 個が同じ速さ でやがる。
| 命令 | レイテンシ | スループット | 実行ユニット |
| add/sub | 0.5 | 0.5 | ALU |
| shl/shr/sal/sar | 4 | 1 | 不明（ALU?） |
| インテル Pentium 4 プロセッサ最適化リファレンスマニュアル 付録Ｃ IA-32 命令のレイテンシとスループット より抜粋 |
|||
うまいこと実行ユニットへの割り振りを考えながらペアリングしてやる場合はまだシフト演算の方が速いけど、単純にレジスタに値がセットされるまでの時間を比較すると add * 8 と shl は等しいらしい。どーゆー演算装置なんだか。
メモ
一通り試して感じた不満点はこれぐらい。という訳で現在コードの修正中。
バグが発生したという事実こそが重要なのであり、報告を行うための敷居は低ければ低いほどよい。報告を行うことに責任を求めるならば、メールサポートのみ受け付ける今の形で何も問題はない。
というわけで、メールアドレスをオプショナルに退化させることに成功したため、バグ追跡システムをトップページからリンク。
私が公開してるプログラムで何か問題が発生した場合は、BUG の方へ報告してください。不具合だけでなく、機能追加要求も書き込んで構いません。だから、お願いだから他所様の掲示板にいきなり書き込んだりしないでください。2ch のように管理者の所有権が希薄な BBS なら書き込まれても問題は感じないのですけど、それ以外のところに書き込まれると、申し訳なさを感じてしまうので。
デモを見て Natural 直系と判断して購入したのだけど、これ、面倒だな。一応３つ個別エンディングを眺めたのだけど全然埋まっていない。どうやらステータスと経験と場所でイベントが決定して分岐するゲームらしいのだけど、条件を探すのがかなり面倒。スポイラーが充実するまで待とうかなという気分。
しかも、物語は微妙に薄いのでスポイラーに頼って見てもあまり楽しく無さそうなのが悩ましい。その場合、完全に作業になってしまう。三並列進行させることが可能な組み合わせを発見することを目的としたパズルならば、模範解答の通りに作業したとしてもな〜んも楽しみは得られんし。購入をちと後悔してる。
ここまで並列進行可能につくっといて同時エンディング無かったりしないよな〜。あるいは同時エンディングがあってもそのエンディングを迎えたら、プレイヤーと入れ替わってもう一周とかいうコトは……いくらなんでもそこまであからさまな真似はしないはずなのだが。
某 ML にリプライを出すに当たって考えたこと。HTTP で行われる通信のうち、不正アクセス防止法で保護されるのは、アクセスにあたって BASIC 認証などのパスワードを伴う認証手続きが必要な場合だけな訳なのだけど、アクセスログに http://user:pass@www.hoge.jp/fuga/ とかが入っていた場合、うっかりリンクをクリックしてしまったらそれは不正アクセス防止法違反になるのだろうか？
例えば、適当にアクセス制限をかけたページを作成した上で、JavaScript の document.referrer 使ってアクセス解析してるページにリンクを張り、http://user:pass@host/path/ 形式でアクセスしてからリンクを参照しまくって、アクセスログに足跡を残し、後はアクセス解析を辿ってきたら、さあ始まり。
おうおう、よくも不正アクセスを実行してくれたな、こっちは httpd のログも取ってあるんだ、出るところに出たら、そっちは懲役１年以下か、５０万以下の罰金刑だぜ。そこを我慢してやろうと言うんだ、それなりの誠意を見せよーって気は無いのかい。
ってな話になったりするのだろーか。あー、Netscape や Mozilla だと document.referrer に user:pass@ 部分が出ないので、上のリンクを試すときは IE を使ってください。IE 6.0 Q312461 でも document.referrer に user:pass 含まれてたので、多分まだ残ってるでしょう。
補足。サーバ側にリクエストヘッダとして送る Referrer: からは IE もきちんと user:pass@ 部分を省略してるのだけど、何故か document.referrer からは削除されてないとゆー大変知性に欠ける状況なんですな、これが。という訳で「サーバ借りてて apache の生ログ読めるから JavaScript なんていらねー」という人も、document.referrer タイプのアクセス解析つけておくと楽しいデス。
referrer 繋がりで。仮説１。FlashGet を使う人は頭が悪い。
つーかどうして User-Agent が FlashGet の Referrer に ero だの emu だの sex だの xxx だのそーゆー単語が入ってるのか不思議でならない。IE コンポーネント使って分割ダウンロードツール作る方が大変な気がするのだけど、ひょっとしたら違うのだろーか。
やっと DCT が判った。今まではベタに移植してたのだけど、なるほど libjpeg の LLM idct のコードでの固定小数点定数の意味はそういうことだったのか。Intel の AP-945 を読んでて気がつくというのはかなりアレだけど。
そうすると Intel のアルゴリズムは LLM のように 1D DCT を２回繰り返したものではなくて、2D DCT を直接最適化したものに近い訳ね……。行処理が素の DCT に近いコードになってしまうけど、その代わりに列処理で乗算の数を３つに減らすことができるアルゴリズムなのか。係数のテーブルも正確に 128 byte ずつブロック化してるし、気合の入れ方が違うわ。
今プラグイン側で使ってる LLM だと、行処理で AC 係数が 0 の場合のショートカットを入れてるおかげで、低ビットレートの MPEG なら AP-922 とそんなに速度は変わらないけど、高ビットレートでは AP-922 よりも遅くなってしまうから、AP-922/AP-945 デッドコピーしてでも Intel のアルゴリズムに修正した方が良いのかもしれない。そのままのコードだと多少精度が落ちるけど、それでも IEEE 1180 には適合してる訳だし。
うげー、WinDVD だとファイルの途中で水平サイズが切り代わる MPEG-2 を何の問題もなく再生しやがる。PowerDVD だと駄目だったから安心してたのに。どーしよ。