今回の m2v.vfp の更新はバグ修正のみ。TS 対応は今のところさっぱり進んでいない。一応サンプルとか資料はあるけど、週末は遊びほうけていたもので。
最近 MPEG-1 とかもコマ送りして表示したいかなという欲求が出てきたのだけど、やっぱりそれは TS の表示に対応できてから考えることにしよう。
一応今日は恒例のアレがあるので、多少は作業が進む予定。通常より 20 分ほど余計に時間があるらしいし。
あー作業が進まない。中途半端に処理速度とか汎用性とかを気にしてしまうのがいけないのだと判っているのだけど、どうしても考えてしまう。今週はちまちまとコードを書いては消し、書いては消しを繰り返していたので未だに TS の DEMUX ルーチンすら完成していない。
そのうちこんなことをしていたら時間がどんなにあっても足りないからとりあえず突っ走ってしまえ〜と汚いコードを書きはじめるのがいつものパターンだったり。いい加減このループから抜け出したい。
現時点でどこまで進んでいるかというと、TS の PID をどうやって決定するかで煮詰まっているところ。VIDEO ES を持ったプログラムの ID を一つ決定するのが目的なんだけど、アクセスユニット一つでは決定できないし、PES パケットを再構成してからとか考えてもプログラムはごちゃ混ぜになってるだろうから、一つずつチェックする場合にはいちいち戻らなきゃいけないし。
さらに嫌なのはそこまでして複数のプログラムがある場合に対応したとしても、結局１つの映像ストリームしか扱えないから、たいていの場合は TS の先頭にあるアクセスユニットの PID を使う場合と全く変わらないってところ。結局映像ストリームをもつプログラムを別に抽出しておく手間が必要なのは変わらない。
なら楽なほうで作れば良いのだろうけど、MPEG-2 VIDEO と音声（LPCM）が別プログラムになってる場合とかにも分離してやらなければいけないのが気に食わないので、ぐるぐるぐると考えだけがまわってまとまらない。ああ本当に嫌になる。
連休の間に動くところまでもっていくつもりだったのだけど、どうやらそれは無理だったようだ。まだ半分も出来上がっていない。
土曜日は寝倒して、日曜は気分がのらず、月曜はなんとか手を動かしたものの、今までの方針では無駄が多すぎることが判明してソースコード破棄。やってることに進歩が無い。できれば今度の廃棄を最後にして、今日中には DEMUX が動くように……なるといいな。
今までの分を破棄したとはいえそれなりの量のコードが書きあがってはいるのだけど、テストを済ませていないのでどの程度の進捗とかいうことは言えない。最初はこんなに苦労するとは思ってなかったんだけどな〜。毎度の事だけど見積もりが甘かった。
つい昨日から仕事の方が忙しくなってしまった。趣味のコードに掛ける時間がどんどんと削られていってしまう。半分自業自得のようなものなので誰にも文句は言えないのが悲しいところ。
せめて今作成中のあれを何とかしたいのだけど、そろそろ DEMUX が書き終わるかもといったレベルなので公開できるのはかなり先になってしまいそうな感触。まだ先頭のゴミを無視する所が残ってるんで。
PES_packet_length - A 16-bit field specifying the number of bytes in the PES packet following the last byte of the field. A value of 0 indicates that the PES packet length is neither specified nor bounded and is allowed only in PES packets whose payload consists of bytes from a video elementary stream contained in Transport Stream packets.ISO/IEC 13818-1 : 2000 (ITU-T H.222.0)
だそうで、一体だれがこんな例外規定（下線部）を作ったのだか。今まで PES packet の長さは 65536 以下だと思い込んでいたというのに、あっさり否定されてしまってどうしたらよいものやら。
ようやく動かせるレベルに到達した TS DEMUX のデバッグ中に気がつくのだから嫌になってしまうね。解決策は思いつくけど、コードの修正が膨大になりそうであれだ。
referer の解析結果で検索から飛んでくる場合と通常のリンクを見分けるのが面倒だったので、昨日実家に戻った際に新スクリプトに置き換えてきた。こういうときいちいち現場にいって作業しなければいけない windows 系はいやだな〜と思いつつ諸々の事情で未だに unix への置き換えを実行できてないとか、いっそ VNC を入れてしまうべきかなとか、いやいやそれではセキュリティがとか色々あるけれどもそれは本題ではなくて。
google や lycos の場合 utf-8 が使われていれば ie=utf-8 とか oe=utf8 とか入っているので簡単に見分けることが可能で、uconv/ruby に掛けて Shift_JIS (実際には CP932) に戻すことができるのだけど、MSN の検索からきた場合のキーワードのエンコーディングが判らない。ひょっとしたら cp=XXX がついてる場合だけ該当 CP で、それ以外は全部 UNICODE なのかとも思うのだけど、サンプルが少ないので確信が持てないでいる。
で、なんとなく昨日のアクセスの内訳。google からの検索（google.yahoo 含む）が 423 件でその他（通常リンク含む）が 526 件。圧倒的に google からのお客さんが多いんだけど、これは google ユーザが多いのかそれとも google しかこのページをインデクシングしてないのかが微妙なところ。ついでに一般リンクからだと AviUtl のページから飛んでくる方が 180 件前後でトップ。
某掲示板での話題を受けて、MPEG2 以下をちょこちょこと更新。TS 対応にケリがついたらとか書いてしまったけれど、実際のところ作業は完全に止まっていたりする。
ちと別方面でまったく関係ないことをやっていたりするので今週はシュガー待ちの間もあまり作業を進めることができなかった。来週もかなり少し忙しい予定なので、ますます作業が遅れそうな予感がしている。
this->thread = _beginthreadex(); でスレッドを作成しておきつつ、スレッドの最後で delete this; とかしてて、しかもデストラクタ内部で WaitForSingleObject(this->thread, INFINITE); とかしてる罠。終わるわけ無いじゃん。
非常にほほえましいミスなので見つけた時には思わず笑い出してしまった。あー人に見つけられる前に自分で見つけることができて良かった。
とりあえず _beginthreadex() 時にスレッド ID も記録しておき、デストラクタでは スレッド ID と GetCurrentThreadId() を比較するして、一致してないときのみ WaitForSingleObject() するように修正。 非常に泥縄。
2/17 日に更新された doxygen-1.2.14 でウィンドウズ環境での日本語サポートにも問題が無くなった模様。ソースを Shift_JIS で書いといて OUTPUT_LANGUAGE=Japanese を指定するだけで問題なく日本語のドキュメントが作成可能。
これで、今までのように OUTPUT_LANGUAGE=English で、html_header で文字コードを直接指定という回避方法をとらなくても済むようになった。
前回の改造で google の検索キーはほぼ化けなくなってくれたのだけど、それでも一部化けるものがある。調べてみたところ、特に utf8 等が含まれていなくても utf でエンコードされている場合があるらしい。
QUERY_STRING は "hl=ja&q=m2v%E3%80%80%E3%83%84%E3%83%BC%E3%83%AB&lr=lang_ja" な感じで、検索キーを utf8 から Shift_JIS にすると「m2v ツール」となるのだが……。
さてどうやったらこれの文字コードを判別できるのだろう。化けてるのは一部なので、今のところは無視してしまってるのだが、気になって仕方がない。
不具合報告がもう一件入ったので、MPEG-2 VIDEO VFAPI Plug-In を 0.5.8 に更新。変更点は closed_gop フラグへの対応と、壊れたストリームでもそれなりに誤魔化して表示するように修正。
TS 対応を諦めたという訳ではなく、あくまでも優先順位を変更しただけ。実質的には完全に作業はストップしてるけど、決して断念した訳ではないのだ。
W32/Klez というウィルスが生息しているらしい。多分 GNB さんの所と同じ人が感染してしまったのだと思うのだけど、私のところにも１通来ていた。
これだけなら無視しとけば済む話なのだけど、このウィルスは迷惑なことに From 欄と To 欄をアドレス帳から適当にシャッフルして新規メールを作成するらしく、From 欄が kazhiro@a2.ocv.ne.jp のウィルスメールが届いたという連絡が既に２件。その内１件は海外の方からだったりするので、慣れない英語で弁解のメールを書く必要まで発生してくれた。
速攻でダメ出しされてしまったので、MPEG-2 VIDEO VFAPI Plug-In を 0.5.9 に更新。closed_gop 対応時に入れてしまったバグの修正がメイン。完全にテスト不足だったな〜。
一応報告してもらったバグは潰したつもりなのだけど、きっとまだ見落としてるバグはあるんだろう。えーと、なにか不明な動作をすることがあったら、連絡をお願いします。
GOP 先頭の B ピクチャが前の GOP を参照しているのに、closed_gop フラグが付いてたら、一体どうすれば良いのだろう。
ざっと思いつくのはこれくらいだけど、折角対応したのにまた 0.5.7 以前の処理にもどすのも面倒なので、最後の方法で我慢してもらう誘惑にかられている。この方法だと私は何もしなくて済むので。
なんでも、MediaWare Solutions の MyFlix XE でカット編集すると、出力後のストリームでは最後の GOP ヘッダの closed_gop フラグを強制 ON にしてくれるらしい。もちろんその GOP 先頭の B ピクチャは前の GOP の P ピクチャを参照したままで。浩さん報告＆サンプル提供ありがとうございます。
そういう状況で書き換えられた GOP にシークすると、当然のことながら先頭の B ピクチャをデコードしようとして「不正な処理を……」で死んでしまう。これにどうやって対応しろというのだ〜〜。
M2-Edit Pro とかからの印象だと MediaWare Solutions ってもっと厳密な所だと考えていたのに、なんとなく裏切られたような気分。