相変わらずなんかおかしい。smmp のデバッグビルドで実行すると、終了時に TwinVQ DS フィルタの ASSERT メッセージが出るが、smmp のリリースビルドで実行した場合は、ASSERT メッセージが出ない。タイミングの問題なのかもしれないが、原因がさっぱり分からない。
AAC parser filter for DirectShow のライセンスを再度確認。AAC parser filter のドキュメントを見ると、"Code ideas and snippets taken from the faad2 source code." と書かれている。FAAD2 のライセンスは GPL である。GPL のソースを参考にした場合に、GPL にする必要があるかどうかが問題だ。
なんかバグってる。このフィルタを使ったプログラムを終了しようとすると、フィルタがまだ動作中だという ASSERT メッセージが表示されてしまう。原因がさっぱり分からない。
Visual C++ 7.0 以降では __super というキーワードが使えるようになっていたようだ。C++ では、親クラスにアクセスするときは、親クラスの名前を指定する必要があったが、しかし、__super を使えば、わざわざ名前を指定しなくとも良い。MS の独自拡張だというのが気になる点であるが。
曲名などを取得できるようにしようと思い、IAMMediaContent を実装してみたのだが、なぜか動かない。調べてみると、NonDelegatingQueryInterface() をカスタマイズしていないのが原因だった。
ISampleGrabberCB で取得される時間がおかしい件を調査中。mpg123dsf の動作を調べてみると、こちらを使っているときも正しい時間が取得できなかった。行き詰まってしまった。
smmp で ISampleGrabberCB を使って再生位置を取得しているのは、以前書いたように、再生速度を変更すると正しい再生位置が取得できないからである。.wav 以外のファイルを再生したときに、再生速度を 2倍にすると GetCurrentPosition() で取得する位置の進み方は 4倍になってしまうのである。正しい再生位置を取得できる方法はないのか？
IAMMediaContent2 というものがあるようだ。プレイリストを取得するインターフェイスのようだ。.zip などのアーカイブファイルを読み込んで、プレイリストを返すフィルタを作ってみるのもおもしろいかもしれない。（参考：Windows Media メタファイルの活用）
ISampleGrabberCB で取得される時間がおかしい件は原因判明。CBaseOutputPin::DeliverNewSegment() にメディアタイムを渡す必要があるのに、ストリームタイムを渡していたのが原因だった。mpg123dsf だけでなく、mpg123dsf が参考にしていた AAC parser filter for DirectShow もバグっていた。
ライセンスが気になっていた CParserFilter は、上記 AAC parser filter for DirectShow がオリジナルのようだ。こちらは GPL ではないようなので、TwinVQ や MS のサンプルソースを GPL と混ぜて使えるかを心配する必要はなさそうである。
クララが立った・・・じゃなくて、音が鳴った。
smmp でのシークがどうもうまく動かない。ISampleGrabberCB で取得される時間が、シーク後にリセットされてしまう。
ピンのメディアタイプを合わせたはずなのに、上流の File source (Async.) に接続できない。どうしてかな、かな？
mpg123 and MAD DirectShow Filter のソースを見ると、CTransformFilter を改造した CParserFilter を継承してパーサフィルタを作っている。入力がプッシュ型ではなくプル型になっているのが最大の違いのようだ。入力ピンには CPullPin を改造した CPuller を使っている。
CTransformFilter を継承してプル型のフィルタを作れないかと考えたが、可能なのかよく分からない。CBaseFilter を使う気力はなかったので、CParserFilter を使わせてもらったところ、無事、上位フィルタに接続できた。
今度は下流の Default DirectSound Device に接続できない。調べたところ、設定する情報が足りなかったようだ。IMediaType::SetType(), IMediaType::SetSubtype(), IMediaType::FormatType(), IMediaType::Format() をちゃんと設定したところ、ようやく接続できた。
数日かけてようやくフィルタグラフが構築できた。あとは、TwinVQ のデコーダルーチンを組み込めば完成か？
CParserFilter のライセンスが気になる。mpg123dsf のライセンスは GPL？ MS のサンプルソースを改造したものは GPL と混ぜて使える？ さらに、TwinVQ のデコーダのサンプルソースは GPL と混ぜて使える？
かなり前から作ろうと思っていた、TwinVQ DirectShow Filter を本格的に作り始めることにした。これができれば、自分の smmp や、Windows Media Player でも .vqf が再生できるようになる。ま、できあがっても TwinVQ はとっくの昔に廃れてしまったので使う人はほとんどいないだろうが。
パーサ + デコーダを１つのフィルタで作ろうと思うのだが、CTransformFilter を継承する形で作ればいいのだろうか？
いろいろ試行錯誤の結果、cygwin1.dll 無しで動作する、SH4 用の objdump がコンパイルできた。
$ CC='gcc -mno-cygwin' BFD_HOST_64_BIT='long long' BFD_HOST_64_BIT_DEFINED=1 BFD_HOST_U_64_BIT='unsigned long long' ./configure --target=sh-hitachi-elf --host=i686-pc-mingw32 --disable-nls
なぜか configure で 64bit 整数型が認識できていないようだったので、強制的に定義したらコンパイルが通った。
ELF 形式に対応した、SH4 用逆アセンブラが必要になった。gcc の付属ツール(?)の objdump で逆汗できるのではと思い、cygwin 上で試してみたら、対応していないアーキテクチャだと言われ、使えなかった。
SH4 用クロスコンパイラの objdump を使えば逆アセンブルできそうだと思い、バイナリを探してみたが、見つからなかった。自分でコンパイルする必要がありそうだ。
「フリーソフトウェア徹底活用講座(5)」を参考にコンパイルしてみた。
まずは、cygwin のインストーラから、binutils のソースをインストールする。また、コンパイルには、flex と bison が必要なので、これもインストールしておく。/usr/src/ に、binutils のソースが解凍されるので、そのディレクトリに移って、以下のコマンドを実行。
$ ./configure --target=sh-hitachi-elf --disable-nls $ make
binutils ディレクトリに、objdump.exe ができあがるので、strip をかけてから適当なディレクトリにコピーすればよい。なお、上記のページに従って、--target=sh-hitachi-coff を指定してしまうと、ELF 形式は使えない。--disable-nls を指定すると、メッセージが英語のみになってしまうようだが、iconv などが必要なくなり、cygwin1.dll と objdump.exe さえあれば動作するようになる。
gcc -mno-cygwin を使って、cygwin1.dll が必要ない objdump を作ろうとしたが、どうもうまくいかない。
先月の spam メールの集計結果。着信拒否にならなかった spam が少なくとも 2180通。そのうち、@nifty の迷惑メールフォルダーでも Spam Mail Killer でも spam として認識できなかったものは 7通(0.3%)。今月も @nifty の迷惑メールフォルダーの判別ミスが少し多かった。