９時起床。とりあえずメールチェックを済ます。MPEG-2 VIDEO VFAPI Plug-In のバグレポートが一件。なんとなく原因は推測できるものの、現在開発環境が死んでいる（原因については昨日の記述を参照のこと）為デバッグ不能。サンプルの提供を依頼してから秋葉原へ出発。
駅に行く途中のコンビニ ATM で資金補充。未だ次に給料日まで 24 日もあるというのに、口座残高が非常に心元なくなる。先月は食えたのだから今月も飢えずに済むはずと自分をだますことにする。
直接秋葉原には向かわず神保町で下車。書泉ブックマートにて笹本祐一他著「宇宙へのパスポート」（２００２年、朝日ソノラマ）購入。こんな所にまで出てこない限りまず見つからない本なので。神保町から秋葉原へは徒歩で移動。
１２時秋葉原着。今回の目標は socket 423 主板。目標額は 5000 円。とりあえず九十九、ソフマップ、じゃんぱらと中古屋漁り。途中 DELL のジャンク主板で良さそうなものを見かけたのだが、IO パネルが通常の ATX よりも長いものであったため断念。
１４時、一巡りを済ませて socket 423 の不遇さをかみ締める。そもそも物の量が少なく、価格で選ぼうにも選びようが無い。とりあえず箱付属でもっとも安かった Faith 中古館で P4T（LAN/SOUND 無しモデル）を購入したが、価格は 7000 円であった。
１６時、自宅帰着。中途半端にばらしたままにしていた PC を本格的に分解。CPU とヒートシンクを分離した後でシリコングリスを買ってこなかった事に気づく。自宅近く（それでも二駅先、どっちかというと職場の方が近かったりする）のサトー無線に売っていることを祈りつつ再出発。
２３時セットアップ完了。情報の豊富な ASUS 主板だけあり、DMI 書き換えは dmiflash であっさり完了。途中 protect mode じゃ動かんとかいうエラーが出たものの、98SE の bootdisk の config.sys から emm386.exe を外すことで解消。あー GA-8TX で dmi_b24.exe が正常に動作しなかったのもこれが原因だったとしたらすっごく嫌な感じだなと。
試しに起動してみたところ、受信レベル 74 で安定稼動。PC で見る分には不満を感じないレベル。ただし、外部出力は…… 16:9 はマダ良い。接続機器をワイドテレビに設定しておけば、ワイド信号が出力されないだけの 720x480 で出力されるから。ただ、4:3 に関しては何故に 540x480 で出力するのか問い詰めたい。素直に 720x480 で出せばいいんじゃないのか。つーか 16:9 でも S1 接続してるんだからワイド信号出しとけ。
で、接続機器を通常テレビにしてみたところ、16:9 は 720x360 で、4:3 は 540x360 の額縁表示。あー普通のチューナへの欲望が高まってきてしまったな。少し節約することにしよう。
BIOS 飛ばしてしまった GA-8TX は明日ゴミに出すことにした。まだ１年経っていないので、無理押しすれば無償修理が利くのかもしれないけれども、それで手に入るものは socket 423 主板１枚。今更 P4 を買うはずもなく、修理上がり品を中古屋に転売するにしても秋葉原への足代程度にしかならないと思われるので。地球に優しくないね。
テープ交換と SmartVision BS インストールのイベントは完了したので実家に撤退。SSE2 最適化検証は SmartVisionBS インストール時に予想外のトラブルが発生したために完了せず。
かろうじて MPEG-2 VIDEO VFAPI Plug-In で不具合報告が行われた部分のみ修正を行い 0.5.17 として公開することができた。SSE2 コードはソースには入れてあるけどまだ無効にしてある。判る人なら有効にして遊んでみると楽しいかも。
0.5.17 にバグありました。0.5.18 を公開してます。MPEG-2 PS を出力する際、先頭から出力しようとすると壊れたストリーム出力してくれてました。あと、0.5.18.181 を落としてしまった方、ちょっとした時間差で 0.5.18.182 が出てるので、申し訳ないですが、落としなおしてください。
TMPGEnc 2.54a の特定の VFAPI プラグインって……やっぱりアレの事だよな。確か昔は VF_STREAM_VIDEO 返してれば音声は次の優先度の VFAPI プラグインを試してくれたはずだったのに〜と思っていたところだったのだけど、対応してくれたらしい。
どうも、手を煩わせて申し訳ありません。えーとそのうち音声対応も実作業を進めます。はい、えーと拡張 AVI 出力のケリがついて、シリアルママから TS も MPEG-1 も出せるようになったらの話ですけど。
拡張 AVI 出力は初期設計の不味さが判明してかなりな作り直しが必要と発覚。AVI2 出力を諦めれば作り直さなくてもいけそうなのだけど、そういう訳にもいかないだろうから。
んで考えるのが嫌になったので不具合報告のあった lanczos 3-lobed 拡大縮小の検証に逃げる。当初は地道に電卓片手に手動確認をしていたのだけど、途中で嫌になってテストモジュール作成し係数を全てダンプするように変更。
うぉぅ、本当にバグってる。という訳で本格的にバグ修正モードへ。ペチペチと修正し、一通りの動作確認をした上で 0.4.6 として公開。あーやる気がでないのはどうしたらいいのかな。
ある程度レスポンスの速い回線を、時間を気にせずに使えるうちに設定を済ませておかないとまずいよなという訳で、レンタルサーバの設定作業。一応公開できるレベルに達したので m4 としてリンク。
まだデザインや配置はこちらと同じ。その内プログラム系と個人的な書き物は分けるかもしれないけど、その辺は時間しだいということで。容量も転送量も CPU 使用率も余ってるので貸し出しとかも可能ですが──ふつーの人はこんなドメイン嫌がると思われ。
さて、後は analog 入れて、mrtg 入れれば当面の作業は終わる予定。掲示板は現在スクリプト選定中。やっぱ yybbs が楽かな〜枯れてるし。2ch タイプのも合理的で良さそうなんだけど。
ひねもす VTune 5.0 ３０日間試用版と戯れている。現在手がけているのは YUV RGB 変換の SSE2 最適化なのだけど、MMX 版のコードの処理スピードを 100 とすると、SSE2 化しただけのものは 83 ぐらいのスピードだったのに対して、今日一日作業して 90 程度のスピードまで持っていくことができた。
一応遅いのには訳があって、MMX 版は小数部 6 bit の 16 bit 固定小数点演算を pmullw で実行していたのに対して、SSE2 版では pmadddw を使用することで小数部 13 bit の 32 bit 固定小数点演算を行い、精度を稼ごうとしていた。四捨五入の 0.5 足してるところを省略すれば 99 程度に持っていけるのだけど、それをやってしまうとビット数増やした意味がなくなるから。
本日作業していての感想なのだけど、P4 のアウトオブオーダのすごさを実感してしまった。VTune で見ても何処がボトルネックなのか、さっぱり判らない。
同じループの中とはいえ、20 ステップ以上離れたところを変更した結果、今まで 3000 カウント程度しか使ってなかった筈のところがいきなり 270000 カウントも使うようになったと表示された日には何を信じればよいものやら。
サンプリング時間を無制限にして、アプリケーション起動から終了までの作業も固定して、その状態で最奥のループの総カウント数を比較してトライ＆エラーをしてみるぐらいしか調査方法が無い。
一応なるべくパイプラインが詰まらないように、レジスタに書き込んでから参照するまでの時間を空けるとか、それを満たした上でなるべく演算数を減らすとか、そういった非常にあやふやな対処しかできない。それでも何とか 7% スピードアップさせることはできたけど、これ以上はちょっと限界。
lanczos3 は AviUtl 0.98 対応ですよ。プラグイン側から見た 0.98 での主な変更内容は前後フレーム取得用外部関数の追加ですから。縮小では時間軸処理なんてしてませんし。後、今作ってる YUV - RGB SSE2 版は MPEG-2 用で、しかも YUV444 から RGB 変換を行うものなので XviD には使えません。
職場の 80 アクセスを乗っ取ってくれるキャッシュサーバからのみ marumo.ne.jp が見えないのってどうすれば良いのだろう。多分 ne.jp のネームサーバを見に行く頻度が低いのだろうけど。
ping とか ssh はあっさりドメイン名引けるくせに、何でキャッシュサーバだけ……。えーと仕事中に私用ページ見てるのが悪いと言えばその通りなんだけどな〜。
今週は連休明けのせいで仕事が詰まっていた。つーか、現在も詰まりっぱなしなのだけど、現実逃避。あ〜１日椅子に座れなかっただけで筋肉痛になる足って非常に軟弱。最近は腹も出てきたような気がするしもう年かも。弱気。
そんな中でも時間を見つけては作業を進めている。とりあえず 6 bit 固定小数点演算に逃げる前に、演算のビット数によってどれだけ誤差が出るかの調査をしてみた。んで結果
| ビット数 | 平均誤差 | 平均二乗誤差 | 最大誤差 |
| 16 | -0.000069 | 0.000304 | 1 |
| 13 | 0.005084 | 0.003632 | 1 |
| 6 | 0.843492 | 1.207887 | 3 |
上の表は YUV -> RGB 変換時に double で処理した場合と、各ビット数の固定小数点演算で処理した場合の誤差を調べてみたもの。流石に最大誤差で 3 とか出ると 6bit 演算は駄目かなという気がしてしまう。
誤差が 3 以上になるのは Y が 246 以上の時だけなのだけれども、それでも Y が 112 以上から最大誤差 2 というのが出てくるので、映像ソースに使う場合を考えると問題があるかも。
うー 16bit 幅でも桁あふれを起こさない、6 bit 演算で十分な精度が出てくれれば、そっちに逃げて速度の向上を目指そうかと思っていたのに、逃げ道がふさがれてしまった。13bit 精度でもちっと速度上げられないか調べる必要があるらしい。
水月中。
まだ水月中。香坂ルートが埋まらん。スポイラーに頼ろうか悩んでいるところ。
途中感想。和泉・花梨・雪・那波・鈴蘭の順で読んだのだが、那波ルートは正直判らなかった。雪ルートぐらい判りやすければもちっと楽しめたような気がする。これでコンプリート後に真ルート発生とかいってネタバラシが始まったら喜ぶべきか怒るべきか微妙なところだな〜。
とりあえず地雷ではなく出費額以上に楽しめてるので可。途中きのした順一かと突っ込みたくなったりもしたけど。
6 月分のサーバ代振込み。M1 と M4 の analog の出力を支払ってる金額と比べると悲しくなってくるのは何でだろう。片や 3500 page/day 片や 200 page/day。
ちょっぴり涙がでそうなので、できれば新規にリンクを張る場合は M4 の方にお願いします。M4 の方が回線的には 2 〜 10 倍早いし、固定 IP ですから。一応収入がある限り維持する予定ですので、f2s.com で公開してたページのようにあっさり消えたりはしないはずです。
ITU-R BT.601 と ITU-R BT.709 という勧告があります。どちらも YUV データの形式を規定しているもので、それぞれ RGB から YUV への変換式は次のようになります。
| ITU-R BT.601 | ITU-R BT.709 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 表１ RGB -> YUV の変換式 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
ここで、R,G,B,Y はそれぞれ 0 〜 1.0 の、U,V は -0.5 〜 0.5 の範囲を持つ実数データですが、8 bit で符号化する場合、Y は 16 が 0 で 1.0 が 235 となるように、U,V は 128 が 0 で 0.5 が 240 に、-0.5 が 16 となるように量子化するように規定されています。
表１の係数から、YUV -> RGB に逆変換する式を出すと、次のようになります。
| ITU-R BT.601 | ITU-R BT.709 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 表２ YUV -> RGB の変換式 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
RGB -> YUV の変換係数が違うので、当然 YUV -> RGB の変換係数も BT.601 と BT.709 で異なります。また、表１と表２の変換式は二つとも R,G,B,Y,U,V が実数データである場合の式なのでプログラムから 8bit データを扱う場合は YUV の圧縮・伸張を考慮した式に変換する必要があります。
MPEG-2 では sequence_display_extension の matrix_coefficient で、エンコード時にどの変換係数を使用して YUV データが作成されたか示すことができるようになっているのですが、sequence_display_extension および matrix_coefficient を省略することも可能になっています。
実際、Canopus MTV-1000 や Sony MPEG2 R-Engine 等で取り込んだ MPEG-2 データは BT.601 と同じ係数の YUV データ（ITU-R BT.470-2 System B,G か SMPTE 170M のどちらか、これ以外は DVD ソースに使用できないことになっているらしい）ですが、ストリームでは sequence_display_extension が省略されています。
DVD への書き出し前提の HW MPEG-2 キャプチャボードからのデータのみを扱う場合、matrix_coefficient が省略されていても何も困ることはないのですが、Digital BS からの MPEG-2 データを扱う場合、多少困ったことが発生します。
Digital BS では YUV データは全て ITU-R BT.709 形式で送り出すので、matrix_coefficient が省略されている場合も ITU-R BT.709 が指定されたものとしてデコードするようにと規定されています。HD 放送の場合だけでなく、SD 放送の場合もです。ARIB STD-B32 で確認しました。
Digital BS から直接デジタル形式で取り込んだ SD 放送の MPEG-2 ストリームと、HW MPEG-2 キャプチャボードで取り込んだ MPEG-2 ストリーム。RGB 形式にデコードする場合、それぞれで変換係数を切り替える必要があるのですが、matrix_coefficient が省略されている場合、MPEG-2 デコーダはどの係数を使用するか判定できません。
MPEG-2 VIDEO VFAPI Plug-In 0.5.19 で追加された「色空間行列（省略時）」という設定項目は、MPEG-2 ストリームで matrix_coefficient が省略されている場合に、使用する変換係数をユーザが指定する為のものです。
通常は自動認識に設定しておけば問題ないと思いますが、D-VHS からのデジタルキャプチャを行っている場合は ITU-R BT.709 に設定してください。
AviUtl が遅いのは画像データが 48 bit YUV444 (各色有効範囲 12 bit) で処理してる以上、仕方がないことかなと私は考えてます。16 bit YUY2 と比べるとデータ量で 3 倍、32 bit RGBA と比較しても 1.5 倍ですから、同じ画像を処理する場合でもメモリアクセスが増えるのでそれだけで速度的に不利になります。
フィルタを掛けずに素通しするだけなら、AviUtl より Avisynth や VirtualDub の方が余計な変換が入らない分、速度・画質の両面で有利になるでしょう。実践した訳ではないので推測ですが、理論的にはそのはずです。私ならそのような場合は VideoMaid を使用しますけど。
つい昨日気がついたのだけど、5/3 版の AviUtl Plugin SDK から interlace_filter.auf が追加されてたのね。インタレースフィルタで 60/120 fps 化して、EDIT_FRAME_EDIT_FLAG_NULLFRAME とか指定できるようなら、出力プラグイン側でフレームレート揃えるよりも楽で良いかも。後で調べてみることにしよう。
一部屋で７人働いてるうち、４人が私物のノートパソコン持ち込んでて、しかも３人が AirH" 使ってるっつーのは一体どういう職場なんだか。
いや、実際には３人目が AirH" を使おうとしたらアンテナの取り合いになって、全員つながらなくなったというのが真相なんだけど。一応そこにはかなり高速な回線（PlatformSDK が 10 分で落とせるぐらい）が引いてあるんですけどね〜。
なんでそんなことをしてるのか、事情はなんとなく想像がつくと思います。せちがらい世の中ですね。
むー 5/3 の Plugin SDK ではフィルタからのフレームレート増加は不可能な模様。4/5 とかの一定の比率で減らすことならできるようなのだけど、増やすことはできないらしい。残念。
適当にフレームレート増やしてコピーフレーム設定してやることができればファイルの入出力は全部 AviUtl に任せることができて拡張 AVI 出力を闇に葬り去ることができるかと思っていたのに。
一応出力プラグインは残して、インタレースフィルタから出力プラグインへはファイルマッピングとか名前付きパイプでフレームレート情報を渡す方向で作業してみることにしよう。
土曜から昨日までインタレース解除フィルタの作業していたのだけど、結果はあまり芳しくない。１回の走査で済まそうというのが虫の良い願いだったのかもしれないと感じている。かといって安易に２パスには逃げたくないし。今は縞判定のアルゴリズムが不味かったのかと考えて色々と弄り回しているところ。
今まで試していたコードは大体次のようなもの。
これでは閾値をどう変更しても誤判定がなくならなかったので、もっと良いアルゴリズムが無いものか考え中。縦の情報だけで判定するのでなく、横方向の情報も使ったほうが良いのかもしれない。問題はどうやって処理に組み込むかだけど。
昨日のコードでは判定漏れが多かったので、縞判定の式を変えてみた。だいたい次のような形。
1x4 の 1D-DCT から i=3 の項だけを求めて縞の強度として評価しようというのがその趣旨。で、試した結果、判定漏れは少なくなったのだけど誤検出が増えてしまってどーしよー。
テレシネ済み 59.94 field/sec 部分と CM 用 29.97 frame/sec 部分で縞強度を出力させた感じではまだ昨日のコードの方が判定漏れと誤検出の数が少なかったので、悲しくなっているところ。
30fps も 24fps も、18fps も 15fps も 12 fps も 8 fps も、レイヤー毎に 3:2 プルダウンのタイミングが違うのも全部解除できるようにしようと考えたのが大それたことだったのかもしれない。前後１フレーム使った 4x4x3 のブロック単位評価で解除も即実行つーのはやっぱり無理なのかな。
仕事が忙しいため縞判定は一回休み。フィルタ開発は縞判定がもう少し高い精度で動いてくれないと次に進めないので、実質振り出し周辺をうろちょろしてる状態。問題はインタレースによる縞とオリジナルからある縞の判別なんだよな。もちっとうまい評価関数を作る必要がある。
むー夏茄子を美味しく食べるための自己評価で唸っている。本当はもう１週間はやく出しといた方がよいものなのだけど、流石に今週中に出さないとまずいので。つーか今後６ヶ月の自己目標とかはまだ何とか書きようがあるけど、長期の自己キャリア設計とか言われてもな。
基本的に自信過剰で、必要な知識は必要になってから覚えればいい（覚えることができる）とか、食って遊ぶのに足りる金があればいいとか考えてる人間がどうやったら受けの良い（査定に有利な）長期の自己キャリア設計を書くことができるのだろう。
うーん何も思い浮かばん。本当に何も浮かばない訳じゃないのだけど、地に足のついてないすべった妄想しか出てこないので、書くに足りる物とはならない。
壊れてしまった人を見るのは悲しい。話を聞くのは辛い。確かに私は壊れていくあの人を何もせずに見捨てたのだけど。
上で書いたのは現実世界の個人的な付き合いのある人のことで、書いちゃまずいんだけど、でも耐え切れなかったので愚痴をこぼしたもの。動画関連の知り合いじゃないので、あまり気にしないでいてくれると嬉しい。しばらく暗い記述が続くかもしれないけど。
ISO/IEC 11172-3 を購入。他にも 2 つほど PDF ファイルを注文したのだけど、それは 0 CHF なので支払いは 44 CHF のみ。85 掛けて大体日本円だと 3740 円。普通の技術書を購入したかと思えばそれほどたいした出費ではない。
注文したその日の内に届いたのは良いのだけど、非常に判りづらい購入手続き方法だと思う。PDF 版は注文確認が取れた状態でメール送信という形なのだけど、何故か注文の際は配送先住所を入れる必要があるし、しかも一発目だと Airmail しか指定できないくせに、それじゃ配送先住所に届かないからリストから配送業者を選んでくれと言われて、DHL を強制的に選ばされたりするし。
で、届いた PDF は ISO_IEC_11172-3;1993(E)-Image_600_PDF_document.pdf というファイル名の 10M のファイルだった。何となく嫌な感じだなと思いつつ開いてみると、いかにもスキャナで取り込んだものですよ〜という、微妙に斜めなガビガビのもの。くぅぅ、安っぽい。
実際スキャナで取り込んだ PDF ファイルって始末に終えないもので、テキスト検索ができないからデジタルフォーマットの利点が 3/4 ぐらい失われて、容量はかさむし、読みづらいし、開くの遅いし。ちょっと損したかも。
とりあえずサンプルプログラム（dist10）と規格書がそろったから、実装に必要な情報は全てそろったことになる。あとは時間だけが問題点と。はやくインタレース解除フィルタを形にしないと。一つ思いついたことがあるので、今日これからためしてみる予定。
１パスは諦めた。遅いのは我慢することにして、フレーム全体の評価とフィールド入れ替えによる縞解除で動くものをまず作成し、後のことはそれから考えることにした。
のだが、案の定細かい縞が取れなくなって困っている。30fps/60fps ものについてはとりあえず無視することにして、24fps からの 3:2 プルダウンを考える場合、トップファーストでのプルダウンパターンは次のような形になる。
| フレーム | 0 | 1 | 2 | 3 | 4 | |||||
| トップＡ | 0 | 0 | 1 | 2 | 3 | |||||
| ボトムＡ | 0 | 1 | 2 | 2 | 3 | |||||
| トップＢ | 0 | 0 | 1 | 2 | 3 | |||||
| ボトムＢ | 0 | 1 | 2 | 2 | 3 | |||||
| 差分 | 0 | 1 | 1 | 1 | ||||||
| 1 | 1 | 0 | 1 | |||||||
| 0 | 1 | 1 | 1 | |||||||
| 1 | 1 | 0 | 1 | |||||||
今使ってる縞判定関数は ２１日のコード から２つめのステップを省いたもので、これは大抵の縞を検出してくれるのだけど、次のような形の場合にインタレースノイズを検出してくれない。
| フレーム | 0 | 1 | 2 | 3 | 4 | |||||
| トップＡ | 1 | 1 | 0 | 1 | 0 | |||||
| ボトムＡ | 0 | 1 | 0 | 0 | 1 | |||||
| トップＢ | 1 | 1 | 0 | 1 | 0 | |||||
| ボトムＢ | 0 | 1 | 0 | 0 | 1 | |||||
| 差分 | 0 | 1 | 1 | 1 | ||||||
| 1 | 1 | 0 | 1 | |||||||
| 0 | 1 | 1 | 1 | |||||||
| 1 | 1 | 0 | 1 | |||||||
これはどういうパターンかというと、1,0 の縞が縦１ピクセルずつスクロールする 24fps のフレームを 3:2 プルダウンで 30fps にしたもの。実に極端な例なんだけど、3:2 プルダウンによって縞が発生すべきフレーム（1,2）は縞がないと判定し、オリジナルであるべきフレーム（0,3,4）に縞を検出してしまう。実際に縞はないのだからそれで正しいのだけど。
ここまで極端な例は稀なのだけど、小さな変化の場合これに似た現象が発生するためにプルダウンノイズを検出することができなくなる。前後の差分に縞が出ることを利用して何とか判定できないか試してみたのだけど、それをやると今度はオリジナルであるべきフレーム（0,3）もノイズとして検出するようになり、どうしようもなくなってしまった。もう少し考える必要があるらしい。
とまあこういうことばかり考えていられればそれはそれで仕合せなのだけど、MPEG-2 VIDEO VFAPI Plug-In の方のバグ報告が２件詰まっているので今日はそちらを片付ける予定。仕事を早めに片付けよー。
知能とは、1+1 の答えをすばやく出す能力。知性とは 1+1=1 を疑う能力。
するってーと、なにかい熊さん。コードに修正を加えた後、十分なテストも無しにバグを残したままソフトをリリースするようなやつは知性が低いってことかい。
MPEG-2 VIDEO VFAPI Plug-In ver. 0.5.22 を公開。0.5.20 からの、MPEG-1 出力機能を追加した以降に加わってしまったバグはこれで修正されたはず。はずなんだけど、最近すごーく自信がなくなってるのでまだなんか残っているような気がしてならない。
まー最初にオーディオデータのトリム機能を付けた時の手抜きが後から響いてきたわけで、自業自得なだけに……これ以上考えるのは嫌な結論しかでそうに無いので健康の為にやめとくことにしよう。
Intel C/C++ Compiler の評価中。とりあえず 0.5.22 と同じソースを icl でコンパイルするように Makefile 書き換えて make 実行。320x240 の MPEG-1 では cl 版 136.8 fps に対して icl 版 137.8 fps と大差なかった（GDI がネックだからな〜）ものの、1920x1080i 46 Mbps MPEG-2 では cl 版 1.7 fps に対して icl 版 2.4 fps と大幅な高速化。
金が溜まったら買うことにしよう。ちまちま最適化してるよりずっとリターンが大きい。なお、購入するまで Intel C/C++ Compiler 版のバイナリの公開予定はない。ライセンスよく読んでないのでひょっとしたらできるのかもしれないけど、多分評価用のコンパイラで作ったバイナリって公開しちゃ駄目だろうから。
mme.exe 0.1.10 が入ってた方、それはアタリです。運が良かったのです。ですからあまり追求してはいけません。
3:2 プルダウンの場合、前後フレーム間での差分が一定のパターンを示すことをインタレース判定に利用できないか、次の方法を試してみた。既にもう「縞」の判定ではなくなりつつあるけど。
結果、インタレース縞があるフレームも縞無しフレームと判定してくれるようになった。これ は 1,2 フレームに縞があるパターンだけど、テストに使ってる .hack OP の場合、連続した縞の片方を縞無しフレームと判定するようになってしまった。
単純に差を取るのではなく、差分画像でパターンが現れてるときだけ評価に入れるような仕組みにしてやらねばならないらしい。むーますますブロック単位評価が遠ざかっていく。
再度方針転換。フレーム評価止め。指輪が一番小さく回ってるところの縞が周りのノイズに埋もれてしまう。ブロック評価をフレーム評価にフィードバックする形で作成しなおすことにした。
フィードバックの方法は単純に縞強度を平均してフレームの縞強度とし、ブロック縞強度に足してブロックのインタレース解除方法を決定するというもの。今はパラメータの調整中だけれども、これで行けると判れば解除方法を拡張 AVI 出力に渡して、そちらででフレーム間差分から FPS 決定して可変 FPS 出力ができるはず。
後は最後まで縞が取れなかった場合に二重化で解除する処理を追加する必要があるけど、それはそんなに大変ではない。今週末にもう少し作業を進めて、来週中のリリースを目指したい。