今日はひまだったのでnvplayerのタスク一覧と問題点を検証していた。 まずタスク一覧を列挙してみると、
フレームワーク関係のものとしては
デバッグ機構
タグ解析
フォーマット解析関係
ファイルサポート判定関係
サポート優先順位
Waveボリュームモードの実装
URLを開く処理
階層型リスト(CDPlayerおよびDVDに対応するため?)
個別のものは
QuickTimeの対応
Flashの終端判定
Flashの縦横幅取得
といったことが考えられた。
全体的なものとしては未だ先に延ばせる問題が多いので順調に先延ばしにして来たのだが、ちょっと一覧を見てみると
デバッグ機構に
関してはそろそろやっておかないと完成した後にデバッグ機構が出来てもしかたが無いので、これに関しては、今週中に済ませてしまおうかと考えている。
多少汎用化しておいて今後もつかえるようなのを作ろうかと思っているが、COMで作ると文字列がBSTRに成るのが実は利便性を損ねる可能性があるのが厄介なところである、普通のライブラリ形式でもいいのだが、実行時に動的にデバッグ機構を働かせるかと決めたいため、静的リンクはしたくないというのが本音ではある。
まあ、仕方ないのであきらめてBSTRで行くかな〜とか、別にconst char*でもいいといえばいいかな〜とか、ごにょごにょ
タグ解析・フォーマット解析は
今までのnvplayerではGUI側に持っていたが、今回も同じ手法で行くと、GUIの方が肥大化するため、これに関しては各DLL毎に持たせるというのが普通に考えればわかりやすい手法ではある・・・
が、無駄な処理が増えるのも事実ではあるので、悩みどころではある。 また別の見方をすると、Flashはタグ解析は無いし、Realもよくわからんし、QuickTimeもタグのようなのがあるのかすら知らないので、実際に実装するのは以前のままのDirectShow関係だけであるので、タグやフォーマット解析インターフェースを各DLLにも足せるようにしておいて、今の部分はそのままGUIにつけておいて、GUIの方で処理できない場合だけ各DLLに問い合わせるという方法でいいような気もしている。
おそらくこの手法で行きそうな予感・・、移植も面倒だし
Waveボリュームは
各DLLでのボリュームの変更が対応されていないものの場合にはWaveを変えるという動作で解決しようかと思っていたが、モードをWaveボリュームモードと内部ボリュームモードにわけて、それをGUI側で切り替えてやるのがいい気がしてきたな・・・ 内部モードの場合は対応していないメディアの時はいまのFlashやRealのように操作できなくなるようにしてWaveの場合はそのままって感じでって方がスマートに解決できると思うので、この問題はGUI側で吸収の方向で決定だと思われる。
悩むポイントとしてはどのような切り替えUIをつけるか?といったところである。とりあえずは設定ダイアログかメニューで切り替えだな〜、これは思い立ったときにやってしまえるな、一応Waveボリュームの変更イベント受け取れるようにして、ボリューム値の保存・復帰処理もつけるのがいいだろう。
URLを開く処理は
つけるしかないが、単純にファイルを開くまで、存在チェックが行えないので、オープンエラーが起きる可能性が増すっていう所が問題なのだが、まあこれはやってみてから決めよう・・・
現在は、ファイルリスト読み込み時や、保存時、ファイル再生直前にファイルの存在チェックを入れているため、URLは開けないようになっている。直す点としてはURLの場合とURLでない場合で処理を分けるしかないというのが鬱だな(ぉ
階層型リストは先送り・・・
とりあえず、半分まで考え進んだが、先送りと予感だらけであんまり進んでいるようには感じられないのは気のせいであるということにしておこう。
個別の問題としては
QuickTime・・・
QuickTime・・・
QuickTime・・・
これ鬱だ・・・
今までの実験の結果おそらくBuilderトラップであると推測される(ぉ、完全には確認が取れていないが、BuilderのFormの上に作成しようとすると謎の「浮動小数点演算エラー」がおきる。処理内容的にはQuickTimeのサンプルと全くといっていいほど同じ処理をしていてサンプルのほうでは動くので、いや〜な予感がぷんぷん漂う。
仕方が無いので自前でウインドウクラス登録してウインドウ作ってそこの上にQuickTimeを載せるというベンチを取ってみるというのが当面の課題か・・・
これで動くとさらに鬱だよな・・・動かないと頓挫レベルだな。
というか、長すぎ日記じゃねぇ(笑
つーか、頓挫