今週はやらなければいけないことが多かったので、MPEG-2 VIDEO VFAPI Plug-In の修正が捗った。人間としてどうなんだろうと思うけど、やらなければならない作業を忘れて無心にコードを書くのも、それはそれで楽しかったりする。
今回の更新のきっかけになったのはとあるエラー報告のメール。そのときにサンプルとして貰った MPEG ファイルなんだけど、なかなか素敵な壊れかたをしてたので、ここで紹介して見る。
そのサンプルはとある HD 放送を DVHS 経由で取り込んだもので、静止画部分で画面の下のほうに緑のゴミが出るという報告だった。ストリームを見ると、I ピクチャの途中でいきなり次の B ピクチャのスタートコードが入るという素敵な壊れ方をしてる。
取り込み時のエラーなのではないかと聞いたところ、TS 取り込みでも出たし、違う週でも出るし、他の局でも静止画部分で同じゴミが出ることがあるという話。とすると取り込みエラーの可能性は低い。
一応、説明可能な原因は推測できるのだけど、でも、そんなことが起こりうるのか疑問だったりする。以下、推測した原因
一応説明はつくんだけど、こんなレベルの低い（ある意味極限まで画質を追求してるんだけど、でもレートコントロール的には失敗な）エンコーダが放送用に使われているとは思えない。何か他の原因がありそうな気もするのだけど、納得のいく説明が見つからない。
という訳で、今回（0.6.6 〜 0.6.8 にかけて）のメインはエラー耐性の強化だったり。どーやってるかというと、ピクチャデコード中のエラーチェックを強化してエラーを取りこぼすことがないように修正して、エラー発生時には、P/B ピクチャの場合は次の MB の動きベクトルで、I ピクチャの場合は前方参照フレームから動きベクトル (0,0) でコピーするようにした。
これで、順方向の再生ならば緑ブロックは出なくなるはずなんだけど、ジャンプなんかで飛び込んでこられると、参照フレーム自体が無いからやっぱり緑ブロックが出てしまう。こればっかりは、本当にどうしようも無い。
MSSG のソースコードを見て、なんて綺麗なソースだろうと感じるようになってしまった。昔はこんなソース読めねぇと叫んでスクラッチからデコーダを書いたというのに。
まぁ綺麗・汚いというのは相対的なもので、単に MSSG のコードよりも汚いソースにここ２月ほど付き合わされた結果、閾値が下がっただけのことなんだけど。人はどんな環境にでも適応できるんだな〜と、思わず遠い目になってしまう。
まだ自由の身になれてないので簡単に。0.6.6 で追加した AP-922 IDCT 関数ですが、アセンブラソースの先頭にコピーした IEEE 1180 の結果を見れば判るように、LLM よりも精度が高いものです。
速度も SSE/SSE2 が有効な環境であれば LLM の MMX 版よりも速く、MMX しか使えない環境でも高ビットレートならば AP-922 の方が速くなっています。MMX すら使えない環境の場合 LLM の方が速いですが、その環境では emms の呼び出しで不正命令例外を発生させて m2v.vfp が死にますので LLM の存在意義は非常に薄いです。
とてもとてもかなしいことがあった。DVHS 買おう。
MProbe が使いにくすぎる。つーか製品紹介のページ見てたときはもっと使いやすいものかと思ってたけど、はっきり言ってだめだめ。あの値段分の価値は無いと断言できる。
なにより不満なのは機能が足りてないこと。DCT 係数の VLC が見たかったのだけど、どうも見れないらしい。しばらくは MSSG のデコーダでトレースログ出力させてしのぐけど、自分で作りたくなって仕方がないのはどうしてくれよう。
2ch DTV 板の某スレッドが熱い。つーか見ててすっげー楽しい。思わずちゃちゃを入れてしまいたくなる。最初は某動画の色補正がやりすぎじゃないかという話だったのに、いつのまにやら sRGB が windows の 8 bit システムカラーということになってるし。
えーとカラーマッチングの話なら All About Color が詳しいです。ガンマ補正だけなら osakana.factory - ガンマって何？ が一番判りやすく書いてます。
あー、ITU-R BT.601 のページに嘘発見。NTSC から BT.601 形式に変換するときはカメラガンマの逆補正はされません。電流値がそのままリニア PCM にサンプリングされます。某副業で BT.470 やら BT.709 やら調べてて気がつきました。そのうち直します。
何故、P4 2G のマシンで QCIF サイズ（176x144）の 1 フレームをエンコードするのに 3 秒もかかるのだろう。720x480 をリアルタイムエンコードできている codec もあるというのが信じられない。本業が一つ片ついたのはいいけど、今度のもつらそー。
いくらなんでも、QCIF サイズで 1 フレーム 3 秒はありえない話だったらしい。今日リリースモードで作り直したバイナリは 1 フレーム 1 秒でエンコードしてくれるようになった。
劇的なスピードアップではあるのだけど、それでもやっぱり遅すぎ。いったい中で何をやっているのやら。最適化の仕事が来ませんようにと願っても無駄なんだろうな〜。バグはないだろうと推測されるところだけが救い。最低でもライブラリ化の話は来るものと覚悟しといた方がよさそう。
時報除去にバグありますか。以前も似た書き込みを見かけていたのですが、環境依存だと思って放置してました。今日帰ったら調べます。
本業がひと段落して副業も終わりが見えたので、勉強再開。多変量解析の初級本を買い込んで、統計学の復習中。R をダウンロードし demo(graphics) と打ち込んでペチペチとリターンキーを押してはみたものの基礎知識無しに使えるようなものでは無いということが判明した為。
本当はその前に日曜の試験の勉強をしなければいけないのだけど……一夜漬けでどうにかなるような分量でもないしな〜。ああ、まだ受験表に貼る写真も撮ってない。
C で関数ポインタ使うのも、C++ で仮想関数オーバライドするのも大して変わらないし、仕組みが判りやすい分関数ポインタの方が好きとか考えていたのだけど、関数ポインタの重要な欠点に気がついてしまった。
関数ポインタだと doxygen が追跡してくれない。仮想関数のオーバライドなら辿ってくれるのに。
某他所様の書いたコードに doxygen 用コメントが埋め込まれてたので、折角だからソースよりもドキュメントの方を読もうかと試したところ、この事実が判明。私にそんなことを言う資格はないのは判っているのだけど、何で C++ じゃないんだろう、このコード。
遠方からでは状況が掴めなかったので、週末だし実家に戻ってしらべました。今まで１年と半分、IP アドレスもホスト名も変わらなかった幸福な端末でしたが、とうとうアドレスが変わってしまったようです。
17 日の 0 時にプロバイダの事務所移転があったのですが、その際の機械変更で今までに記憶していた MAC アドレスと IP アドレスの対応を忘れてしまったようです。
今後の方針ですが、今更新しいアドレスを告知して、上り 512kbps しか出ないサーバを１台確保し続けるのも無駄っぽく思えるので、実家サーバを公開するのは当面止めておこうかと考えてます。と、言うわけで、当面は M4 (www.marumo.ne.jp) のみでの運用になります。M1 (e3lt11.ocv.ne.jp) にリンクしていた方は申し訳ないですが、リンクの修正をお願いしたいと思います。
時報除去のバグはまだ調べていません。今朝は５時で力尽きてしまいました。
更新しました。えーと、久しぶりに中を見たのですけど、こりゃバッチ出力で最初のにしか利かなくてもあたりまえですね。というわけで直しました。いちおー 0.98d で動作確認済みです。
３年前の過去問集がどこまで役に立つかわからないけど、漬物開始。
わはは「生産性＝行数／人月」とは流石だ通産省。今時こんな問題文書いて恥じないその厚顔さを尊敬する。嘲りつつ「ア」にマークを付けたが、10^0.98 って電卓無しで計算できるような式か？ 10 に近似して計算したが。
えーと解答速報からの自己採点の結果、午前が 34/50。前受けた時より落ちてる。午後Iは２・３・４を選び、午後IIは２を選んで一応解答欄は全部埋めた。注意不足のミスが幾つかあって、それが悔やまれる。
多分午前で足切られて落ちているだろうけど、その場合は今日の第一声は負け惜しみということで。
あー仕事しよう。いい加減速報サイト眺めてても虚しくなってくるだけだ。
真面目な勤め人は職場で 2ch や日記サイト眺めたり、１０時２０分に起きてあわてて出勤したり、シュガー録画失敗に怯えてリアルタイム監視したりしないよな〜。
一応、為念。wrapsharp の作者とは別人です。てーか私はオペレータオーバーライド使いこなせるほど C++ 詳しくないし。
よく判らないが、AviUtl のページが不思議なことになっている。いったい何があったのだろう。ただの更新ミスならいいのだけど。
むー何となく予想はしていたが、「東の滄海」をやらないということは、当然「図南の翼」もやらないんだろうなー。残念。せめて劇場版とかでやってくれないものだろうか。
どちらかというと外伝の方が好きなだけに本当に残念。「魔性の子」はやればすごいと思うけど、個人的にはどうでもいいしなー。
YUY2 フィルタモードって、もしかしてフィルタプラグイン全部作り直しですかー。
後方互換性とるにしても、それはそれで本体側が大変そうだし、私としてはメンテしなきゃいけないのは lanczos3 と 色タイミング補正だけだから無くてもいいけど、他の人はそうはいかないのでないのかしらん。
まるも式インタレース解除に手を出さずに、MPEG-2 VIDEO VFAPI Plug-In の 422 → 444 補間処理除去に着手しといて良かったと笑うべきか、lanczos3 のアセンブラソースを全部修正する日を思って泣くべきか。微妙なとこだな。
２３日の戯言の補足。YUY2 でも精度はそんなに問題にならないでしょう。データが 8 bit でも 16 bit でも大差ないんですよ。最終的には 8 bit に落とさなきゃいけないんだし、途中で適切な丸めが行われれば打ち切り誤差はさほど気にならないものです。
ただ、YUY2 だとフィルタ作るのが面倒になるなーとそういう意味で嫌がっていたのです。速度では間違いなく有意差が出るので対応しない訳にはいかんのですけど。（だから、プラグイン作者という立場から見れば、後方互換性はどーでもよかったりする。ユーザの立場としては対応されるまでの間プラグインが使えなくなるので大問題だけど）
使った食器は床に放置せず、すぐに洗って片付けよう。週末には掃除機をかけよう。ベッドのシーツも洗おう。
７月から掃除をしていないので当然といえば当然なんだけど、最近生活環境の悪化がいちじるしい。せめて真人間のフリ位はできるようになろうとしみじみ実感してしまった。
運が良ければそのうちフリが身について、本物の真人間になれるかもしれないし。