デプレクサは何とか完成。各 ES をばらすだけの実に単機能なものだけど、一応データ化け等は無く、正常に動いている模様。
……ただし、m2v.vfp の方に組み込んでみるとどうにも上手く動いてくれない。多分何処かでデータを落としてしまってるのだと思うのだけれども……こういうののデバッグが一番面倒なんだよな〜。一応再現性があるのが救い。
こりゃ連休の間はデバッグでつぶれてしまうかも。８月中頃の VLC テーブルのデバッグで延々ビットストリームをトレースしていた時よりかは楽に解決できると思うのだけれども……。
う〜ん、上手いことバグを捕まえて潰せれば週末頃には M2P 対応版の Ver. 0.3.0 をリリースできるのだけど、この調子じゃ無理かな。
今日のところは５時から用事もあることだし、余裕を持って１時には出なきゃいけないから、これ以上の追求は断念。一応怪しいところをプリントアウトして、電車の中で読むぐらい。
バグは潰せて、テストした限りでは正常にデコードできるようになったため、m2v.vfp ver. 0.3.0 をリリース。Program Stream に対応してみました。
まあ一人でテストを完全に行える訳が無いので、多分あちこちにバグが眠っていることでしょう。と、いうわけで、何か怪しい動作をすることがあったら教えて下さい。
特に、最近各社が出してる H/W MPEG-2 キャプチャボードで作成したデータの 1 秒間ぐらいのサンプルを頂けるととても嬉しかったりしますので、よろしく m(. .)m
さて、今後の方針ですけど 予定 どおり、MPEG Audio の対応とかを考えてます。何とか今年の内にそこまでやっておきたいのですけど、できるかどうか。
もちろん、PS のバグが見つかればその都度修正版をリリースしますので、報告の方よろしくお願いします。（できれば不具合が再現できるサンプルをつけて）
なんとか卒業後の職を確保。内定頂けました。どこかは秘密。自分的にはかなり良いところなので仕合せ。
え？ 普通はとっくに（遅くても６月頃には）内定貰えてるものなんじゃないかって？ まーいいじゃないですか４月までに何とかなれば。周りに流されるだけが人生じゃないでしょう。
と、言うわけで他の人には全然参考にならないであろう就職活動の履歴。
４月某日、大手 国際商売機器 受験。箸にも引っ掛らず落ちる。
以降、２ヶ月ほどずるずると過ごす。
何か売り込めるものを作るかと思い立ち、ついでだから自分が欲しかった m2v.vfp を作りはじめる。
９月、ある程度 m2v.vfp が形になってくる。そろそろ活動再開しなければとか焦りつつずるずると過ごす。
１０月、売り込み開始
１０月中旬、面接。いきなり１時間遅刻。面接を設定してくれた方と、面接する予定だった方に謝って、２回目のチャンス頂く。
先週木曜、再面接。なんとか大きなポカをやらずに（既に大ポカをやってるという説もある）済み、その場で内定（口頭で）頂き、昨日文章でも内定通知頂けました。
というわけで、卒業後の扶持が確保できたので CATV との契約を進めるべく、手続き開始。将来のあてが無い状態で常時接続にしてしまうとなんだかドンドン落ちていってしまいそうな予感がして踏み切れなかったのだけど、問題が解消できたため憂いなく進める事ができる。
さて、後は工事の進み方次第だけど多分年内に常時接続環境にできるはず。速度の方はあまり期待できない（下り 384k, 上り 128k らしいので）けど、常時接続ならば現在の面倒なダイアルアップの手間が省けるのが嬉しい。まあ、来るのは１月ほど先の話になるのだけど。
やっぱりというか、PS 対応にバグありました。DVD2AVI 作成されてる Jackie さんから報告していただいて気が付きました。他にも、MC のバグとか RFF (Repeat First Field) フラグビットの扱いをサボってた報いのバグとかも報告して頂いて……。一杯バグ入れてますね〜。
とりあえず、今日の更新はビットストリームの取り扱いのバグ修正と、MC のバグ修正のみです。RFF の方はちょっと根が深いのでもう少し時間を下さい。
さて、御礼のメールも書かなきゃいけないのだけど、英作文は苦手（涙）
唸りながら文面考えてます。何とか今日中に出さないと、もう一通もあることだし。
MPEG-2 にはピクチャヘッダに RFF (Repeat First Field - 最初のフィールド繰り返し) と TFF (Top Field First - トップフィールドが先) とゆ〜フラグがあったりします。
どんな風に使うかというと、TFF はフィールドオーダを設定する為に使って、RFF は 23.976 fps ソースを 29.97 fps で再生する（TMPGEnc の再生時 3:2 プルダウン）為に使います。
まず、具体例あげた方が良いですね。RFF を使ったソースは正しくは次のようにデコードされます。（判り難いかもしれませんが）
| ソース | 1 | 2 | 3 | 4 | …… | ||||||
| TFF | 1 | 0 | 0 | 1 | …… | ||||||
| RFF | 1 | 0 | 1 | 0 | …… | ||||||
| トップ | ○ | ○ | ○ | ○ | ○ | …… | |||||
| ボトム | ○ | ○ | ○ | ○ | ○ | …… | |||||
| デコード | 1 | 2 | 3 | 4 | 5 | …… | |||||
解説します。上の表で、ソースはビットストリーム内でのピクチャです。デコードは結果として表示されるフレームです。トップ＆ボトムはトップフィールド＆ボトムフィールドのことです。
トップフィールドというのは 480 ラインの画面を 0 〜 479 で数えた場合に、先頭行（トップライン）である 0 ラインを含むフィールド（TMPGEnc での偶数フィールド）のことです。ボトムフィールドは最終行（ボトムライン）である 479 ラインを含むフィールド（TMPGEnc での奇数フィールド）です。
さて、ソースのピクチャ 1 は TFF が 1 となっているので、トップフィールド、ボトムフィールドの順で、フレーム 1 として表示されます。
普通はこれだけなのですが、今回は RFF が 1 となっているので、先に表示されたフィールド ―― トップフィールドを繰り返して表示します。この繰り返されたフィールドはフレーム 2 にまわされます。
次に、ソースのピクチャ 2 です。ピクチャ 1 で RFF が指定されたので、既にフレームの片フィールドは埋まっています。ので、このピクチャではフィールドオーダを反転しなければいけません。
TFF を確認してみると 0 になっていてボトムフィールド、トップフィールドの順で表示するようにと指定されていることが確認できます。従ってボトムフィールドをフレーム 2 の残りとして表示し、トップフィールドはフレーム 3 にまわします。
ソースピクチャ 3 に移ります。このピクチャでは TFF 0, RFF 1 が指定されています。これはフィールドオーダは逆転したままで、先に表示するフィールド ―― ボトムフィールドを繰り返し表示するという指定です。
したがって、まずフレーム 3 の残りにボトムフィールドを表示し、フレーム 4 にトップフィールド、ボトムフィールドの繰り返しの順で表示します。ここで、RFF が指定されているのでフィールドオーダは再度反転して元の順（トップフィールドが先）に戻ります。
ソースピクチャ 4 では、TFF 1, RFF 0 ですので、普通にトップフィールド、ボトムフィールドの順でフレーム 5 として表示されます。
……このように、ソース 4 枚のピクチャを、フィールド単位で 3:2, 3:2, と繰り返す事で 5 枚のフレームに変換することができます。23.976 fps のソースを再生時に 3:2 プルダウンすることで、29.97 fps で表示できるのです。
これは映画館上映用のフィルムソースから作成された DVD などで標準的に使用される方法です。この利点は明らかで、ソース fps の減少（4/5 に減らすことができる）によるピクチャ 1 枚あたりの割り当てビット数の増加に伴う画質の向上です。
また、正確なテレシネが実行できる点や、ピクチャをプログレッシブエンコードできるといった利点も見逃せません。MPEG-2 はインタレース対応とはいえ、MP@ML は YUV 4:2:0 形式ですから、その実現にはあるていど無理（インタレース YUV 4:2:0 の導入）がされているのです。
以上規格的に正しい RFF のデコード方法でした。現在の m2v.vfp では RFF が使用されたビットストリームでバグが発生していることから明らかなように、この正しいデコード方法は採用してません（だって面倒なんだよ〜）
どうしてるかというと、RFF は無視して ソースピクチャ == 出力フレームとして処理してます。しかも fps は 29.97 のままで。
つまり、デコード結果は再生スピードが速くなって、再生時間が短くなってしまうのです。また、RFF を使用していない 29.97 fps 部分と RFF を使用した 23.976 fps 部分が混在してるようなソースでは、デコード結果がかなり怪しくなります。
バグを解消するために一番確実な方法は、規格に合致した方法のデコードに切り替えることです。この場合処理方法を考えるのと実際のコーディングが面倒なのを除けば一切問題は発生しなくなります。ただし、ホントに面倒です。
というわけで、手抜き対応その２（その１は RFF を無視）
１つ目の RFF が出てきたら、そのピクチャを２回、２フレームとして出力し、２つ目に出会った RFF ではピクチャを普通に１フレームで出力する。
厳密な処理と比べればかなり楽なので、こっちの対応を採用しようかな〜と考えてます。いや、悩みどころなんですけど。
RFF は一昨日書いたように、手抜き対応その２方針で対処することにした。
……のだけど、それでもまだ ver. 0.3.2 は完成していない。やっぱり read_gop() はもっときれいなコードにしておけば良かったかな〜。関数丸ごと書き直しな勢いになってる。まあ、それでも今日明日にはリリースできるでしょう。
それはそれとして、バイナリビューア（16 進ダンプ表示ツール）が欲しい。以下要求仕様。
上から３つ目までは必須機能。残りはあれば嬉しいけど、無くても構わない機能。色々とバイナリエディタとか探してみたのだけど、この３つを満たすのは見つけられなかった。とりあえず今使ってるのは stirling
FREE だし、一応 2, 3, 4, 5, 7 に対応してるので使用していた。ただ、メモリ展開型なので、2G 以上のファイルは開けない。
非メモリ展開型の BinaEdit というものを見つけたので、こちらに乗り換えようかとしたのだけど、巨大なファイルを見るときには非常に重要になってくる指定アドレスジャンプ機能が無い。すくろ〜るば〜でえっちらおっちら目的のところを探せというのだろうか（'_'）
というわけで（どういうわけだろう）誰か作ってくれる人いないかなという話。
何とか RFF に対応完了。一応予告に間に合ったかな。
配布ページの方の 既知の問題にも書いたけど、厳密な正しい処理じゃなくて手抜きをしてるから問題がでるかもしれないんだけど……。
例えば、基本的には 29.97 fps なんだけど 1 フレームだけ RFF を指定されたピクチャがあって、そこからフィールドオーダが反転して最後まで続くようなストリーム（無いと思うのだけどね〜そんな逝っちまってるのは）だと、TMPGEnc & AviUtl どちらを使っても自動 24fps 化が絶望的になったりする。
これ以外では多分、今の処理方針でも問題は出ないと思うのだけど、ちょっと自信がない。
いや、コピーフレームは完全にデータが一致してるはずだから、自動 24fps 化とかでもきちんとコピーフレームを除去してくれるはずとか期待してるのだけど……。
さて、オーディオストリームの方も少しずつやっていかなきゃね〜。一応 MASSG (MPEG Audio Software Simulation Group) の dist10.tar.gz は 2 年ほど前に入手できてるし、中を見たところ結構きれいなソースだったのであまり苦労せずにできるかも。
ホントのこと言うと、もっと資料が欲しいところ。
何時から公開されてたのか判らないけど、FastTrak66 の Linux 用ドライバを ftp://ftp.promise.com/Controllers/IDE/FastTrak66/LinuxBETA/rel.tgz で見つけたので、試してみた。
上のリンクはソースパッケージへのものだけど、RedHat 6.2 用ならばパッケージ版もあるみたい。
まあ、INSTALL の通りに作業して、モジュール作成終了。insmod ft としてみると……。おお、sdb でディスクが見える。
早速 mount -t vfat /dev/sdb1 /mnt/windata とマウントして……。うん、ファイルも確かに見えてる。バックアップしてない（44G なんで）んだけど大丈夫かな〜と、かなりどきどきしながらファイルを書き込み。リブートして Win 2K から見ても壊れてない。
これなら常用できるね。ただ、ソースパッケージなのに ftlib.o っつ〜のが入ってるのがちょっと……まあ、事情は理解できるけど。
VFAPI での MPEG Audio 対応は後回しに決定。MPEG-2 の I フレーム単位カット編集用 GUI の作成を先にやることにした。
うん。ど〜もこっちの方が MPEG Audio 対応よりも需要がありそうなので。
一応 TMPGEnc でカット編集をする場合の難点である正確なフレームの表示というやつは、今まで作成してきた VFAPI プラグインを使うことで解決できるはずだから、後は GUI 作って、ピクチャ単位でビデオストリームに書き込みを行う関数を作成して、マルチプレクサ作って……。
まあ、初期段階ではマルチプレクサは作らなくてもいいか。PS 内の ES を別個に出力するだけでも、他のマルチプレクサを使用して貰うことで、カット編集自体は可能になるはず。
大体２週間程度で（マルチプレクサ無しの）初期版は完成できるかな。
……とか考えていたのだけど。
どうやらその前に不正なタイムコードをもつ（開くのに時間がかかる）ストリームの方をもう少しなんとかしなきゃいけないみたい。確かに TMPGEnc は 24fps 化とか、範囲選択とか、圧縮開始とかの度に、開いて〜閉じて〜開いて〜閉じて〜と実行してるから死ぬほど時間がかかるんだよね。
そ〜いった目的（汗）の場合には DVD2AVI があるからいいかと思ってたのだけど、要望があった以上は対応しなきゃまずいか。
うん、順調に進めば明日までには Ver. 3.3.4 リリースできるかな。
「大体２週間程度で（マルチプレクサ無しの）初期版は完成できるかな」
とか偉そうに前回書いたのだけど……。問題点に気が付いてしまった。
実を言うと、VC でまともな GUI プログラムを組んだ事が無い。今までどうしていたかと言うと、Borland C++ Builder でお気楽にぽちぽちとコンポーネントを配置して作っていたわけだ。
しかし、私の持っている BCB はもはや化石の様な Ver. 3。色々と問題があるのだけど、その最たるものは _seeki64() や _telli64() が無いため、4G 以上のファイルを扱うのに苦労するというやつだったりする。
「◇○■▽で取り込んだ 5G の MPEG-2 が編集できない」とかゆーのを時々見掛けるのも開発動機の一つだったりするから、当然この点は譲ることができない。
という訳で、VFAPI と同様に VC で作る事になるのだけど……冒頭で書いたような問題点が発覚してしまったのだ。
むう、なるほど Windows 用プログラムのエントリポイントは WinMain 関数なのね。ところでメインフォームをデザインするにはど〜すれば良いの？
……２週間で完成するのかな〜。
気分転換も兼ねて、AUF のページ 作成。色タイミング補正だけじゃ寂しいので、３次補間サイズ変更プラグインを作成して公開。
……まあ、３次補間サイズ変更は本に載ってたアルゴリズムのまま、素直に組んだだけのものなのですごく重かったりする。ので、多分だれも使わないはず。（自分でもつかわなそう）
だってねえ、ノイズ除去フィルタよりも重いリサイズフィルタなんて誰も使いたくはないでしょう。
まともに使えるようにするためには、もう少し高速化する必要があるのだけど……やりたくないな〜。どーやれば SIMD 化できるかさっぱり思い浮かばない。
しかもそれだけ労力を費やしても、あんま画質が良くなる訳じゃないし……。VirtualDub のリサイズってそんなに綺麗かな？ 1.4c で試した限りだと左右端で回り込みがあるからあまり好きじゃないのだけど。
「インテル・アーキテクチャ・ソフトウェア・ディベロッパーズ・マニュアル 中巻：命令セットリファレンス」を読んでる。二度と読みたくなかったのに。
アセンブラなんていう簡単にバグが入ってしかも入ったバグを捕まえるのが面倒な言語にはも〜永遠に関わりたくなかったのだけど、cubic convolution があんまりにも遅いので仕方なく。これがちっと遅いぐらいなら頬かむりしてしらんぷりを決め込むのだけど。
SIMD 化についてなんとかうまく行くかもしれない処理方針に気が付いたので、試してみようかと。まー実際に書いてみたら全然駄目だったという可能性もあるけどね。
しっかし、MMX Pentium, Pentium 2, Pentium 3 で、それぞれで追加された命令ごとのリファレンスマニュアルってないんかね〜。「命令セットリファレンス」は Pentium 3 の全命令がフラットに並んでるので目的のめ〜れ〜を探すのがつらい。せめてカテゴリ毎の索引をつけてくれると嬉しかったのに。
３次補間サイズ変更フィルタ を Ver. 0.2.0 に更新。といっても自分ではほとんどコード書いてないで、ルジさんからもらったソースをマージしただけなんだけど。
SSE 化が済んでから一緒に更新しようかと考えてたのだけど、SSE 化がもう少し時間がかかりそうなのと、貰ったソースを適用しただけでも旧版と比較してすごく速くなってくれたので更新。何とか使える速さになってくれたみたい。
あ〜、補間本体よりもピクセル毎の重みを計算してるところの方が重かったのか。確かに考えてみれば納得。
追記： VC の Processer Pack の新版が 9/28 付で公開されてたんだね。知らなかった。これには、MASM の 6.15 も入ってて SSE2 に対応してる。VC 持ってる人だったら、98DDK から MASM 貰うよりもこれを入れた方が良いかも
３次補間サイズ変更フィルタ を Ver. 0.3.0 に更新。一応 SSE 化。
あまり速くならなかったのだけど、ま〜、仕方がないか。これ以上を目指す場合は重みがゼロの場合に処理を飛ばすとかぐらいしかないのだけど、それをやると場合によっては遅くなることもあるし。
うん、何か良い方法思い付くか、教えて貰えるとかが無い限り（両方ともなさそ〜）放置。決定。
さて、MPEG2 CM カットの開発に戻ることにしよう。某友人 I からせっつかれてる事だし。
一昨日の追記に書いたことだけど、VC Proccessor Pack の 9/28 版、いいわ〜これ。
何よりも、MASM 6.15 と MASM のマニュアル（英語版 Word DOC フォーマット）がついてくるのが嬉しい。
今までは、蒲池 輝尚「初めて読む MASM」（1988 ASCII）やら、古性 考庸 監訳「80386 ハンドブック」（1988 丸善）やら、WEB で検索して引っ掛ったのを参考に見よう見まねで書いてたのだけど、これでもう少し自信を持ってコード書くことができそう。
あと、各 CPU で追加された命令のリストとかも（AMD 系も含めて）載ってるし、ほぼ完璧。
「ほぼ」と書いたのは、私の環境だと少し致命的な問題が発生するからだったりする。その問題というのは、統合環境でデバッグ中に（デバッグプログラムの）不正なメモリアクセスが発生すると、何故か統合環境がフリーズしてしまうというもの。
これ以外には、ホント何も文句はないんだけどね〜。
３次補間サイズ変更フィルタ を更新。ちょい高速化。まだ、何処か速くできるところあるのかな〜。あるんだろうな多分。
むう。重みテーブルは一回しか作らないからそこを SSE 化しても効果は無いはずだし、フィルタ呼ぶ直前でパラメータが変わってないかチェックしてるところはフレームにつき１回しか呼ばれないから静的分岐予測アルゴリズムに適応させた所で効果は無い……はず。
後は SSE のアセンブラコードの部分しか無いけど、あの中をこれ以上最適化するのすごく面倒だし。まあ、いいや。考えても判らないことはこの辺でやめとこ。
さて、MPEG2 のカット編集はさっぱり手をつけて無い。もう１週間たっちゃってるのにね〜。むう、もっと真面目にやらなければ……（といいつつ今は NTSC の色復調方法を調べていたり）
新ページ作成。ITU-R BT.601 について とかいうもの。
最初はこっちの戯言でさくっと片付けようかとか考えてたんだよな〜。途中でこりゃ駄目だと気が付いて、MPEG2 か GVDVC の下にでも置こうかと考えたのだけど、面倒なので独立したページにしちゃうこと決定。今考えるにこれで正解だったかも。分量かなりあるし。
え〜と、できる限り裏を取って、嘘を書かずに済むようにしたつもりだけど、肝心の ITU-R BT.601 は読んでない（致命的だね）ので、嘘を書いてる可能性があります。はい。
なんか怪しいところがあったらつっこみのメールをよろしく。
うん、昨日・一昨日とこんなものを書いてた訳だから、と〜ぜん MPEG-2 の方はさっぱり進展してない。確か最初に書いたのが先々週の金曜だったから……、あと２日か。……絶対に無理だな。
わはは、山ほど嘘ついていたことが発覚。うげげ、同期信号は - 40 IRE でカラーバーストの振幅は 20 IRE だったのか。
A/D 変換例は図を全部作り直して、数字も全部直すはめに。確認を怠っていたから自業自得なんだけど。
さらに、ITU-R BT.601-2 をさる筋の友人が入手したらしいので見せてもらうと、なんと YUV 4:2:0 だけじゃなくて YUV 4:4:4 や RGB 4:4:4 も規定されていた。ので、その辺も全面的に書き直し。
唯一、救いは PC 上での取り扱いに書いた推測がほぼあっていたこと。でもな〜、某 C 社の CODEC はそれなりに拘りをもって、確信犯で作ってるのだろうから、更新は期待できないかも。
ただ、映像作成のプロの方から業務用の機材についての情報がメールで教えていただけたので、それは嬉しかった。うん。あのページ作成して良かった。
と、言うわけで、昨日とはあちこち内容が変わってるので、既に読んだ方も、もいっかい見ていってください。ITU-R BT.601 について です。