2004年07月26日
制限
吉里吉里2/KAG3のムービー機能では次のような制限がある。
・ムービーは常に最前面に表示される。つまり、テキストなどをそれより前に表示することが出来ない。
・通常再生のみサポート。ループ、途中から再生などが出来ない。
基本的に上記制限を解消するために開発を行う。
投稿者 Takenori : 05:16 | コメント (0)
懸念事項
吉里吉里の掲示板を見ていて気付いたのだが、W.Dee氏も最前面以外にも表示出来るようにすることを検討されているとか。
微妙だなぁ。
まあ、かち合ってもいいか。
気にせず前進あるのみ。
投稿者 Takenori : 05:25 | コメント (0)
構成
拡張方法としては、次の2つが考えられる。
・本体に変更を加える
・プラグインを作る
しかし、W.Dee氏は定期的に本体の拡張をされているようなので、あまり本体に変更を加えたくない。
そうなるとプラグインとなるのだが、今回のような用途の物はあまり想定されていないようだ。
吉里吉里で使えるプラグインの種類は次の3つ。
・Susie Plug-in (画像読み込みとアーカイブアクセス)
・WaveSoundBufferで再生可能な形式を拡張するためのプラグイン
・そのほかの吉里吉里専用のプラグイン
そして、そのほかの吉里吉里専用のプラグインは次の2つにわかれている様子。
・トランジション用
・関数追加用
以上のことから考えると、
プラグインで提供する。
プラグインはTJS関数追加プラグイン。
となりそうだ。
後は、利便性を考えて、TJSでクラスを作り、KAGプラグインとして提供するとなるだろうか。
なんか、Cで組まれたライブラリのラッパークラスを作るような感じだなぁ。
組込型に比べれば少し重いかもしれないが、たぶん大丈夫でしょ。(根拠なし)
投稿者 Takenori : 05:33 | コメント (0)
2004年07月28日
DirectShow
はじめは言いたいことはわかるが･･･なんか漠然としているなぁと思っていたが、ヘルプを読み進んで何となく理解した。
DirectShowは与えられたファイルを元に最も適切だと思われるグラフを構築する。
もし、特殊な用途で使用する時は、グラフから一度フィルタやピンの接続を解除し、再度目的のフィルタやピンを接続する。
と言うことか。
ゲームなどの用途でDirectShowを利用するという似たような状況を解説したページを発見。
軽くふれる程度の内容だが、なかなか良い。
投稿者 Takenori : 01:48 | コメント (0) | トラックバック
Doxygen
DoxygenとGraphvizをインストール。
Latexはインストールが面倒なので入れなかった。
まあ、数式を書かないのであれば、Latexは必要ないのでしばらくは大丈夫だろう。
吉里吉里のソースにDoxygenをかけてみるが結構な量だなぁ。
ある程度分割してかけた方が良かったかも。
投稿者 Takenori : 01:56 | コメント (0) | トラックバック
関数プラグインの作り方
吉里吉里の関数プラグインの作り方をすでにあるプラグインのソースを追って調べていたのだが、tvp2win32/base/win32/plugin_kit/basetest/Main.cpp を見ると作り方が解説してある。
しかも、Readmeをよく見ると "/base/win32/plugin_kit/basetest/ は、吉里吉里で使用可能な関数を増やすサンプル" と書いてある。
Readmeは読んだつもりだったのだが･･･もっとよく読んだ方が良さそうだ。
投稿者 Takenori : 02:01 | コメント (0) | トラックバック
クラスプラグインは可能？
ソースやTJS2のドキュメントを見ていて気付いたのだが、関数プラグインだけではなくて、クラスプラグインも作れるのではないだろうか？
関数プラグインはtTJSDispatchを継承して作る。
実際の処理はFuncCallをオーバーライドする。
そして、それをバリリアント型に変換する。
iTJSDispatch2かそれから派生したグローバルオブジェクトを取得し、そのメンバ関数のPropSetを使い、バリリアント型に変換したクラスを登録する。
そうすることで、グローバルな関数として使えることになるようだ。
そして、ここからはソースやドキュメントからの予想。
PropSetは字句を登録しているのではないだろうか？
登録した字句をnewするとiTJSDispatch2のCreateNewがコールされる。
生成されたオブジェクトのメソッドをコールするとiTJSDispatch2のFuncCallがmembernameを伴ってコールされる。
と言うことは、クラスプラグインも何とかなるのではないだろうか？
ただ、組み込みクラスは継承図の構成が異なっているのが気になる。
ファクトリーパターンやプロキシのような作りになっていると言うことだろうか？
やはり、もう少しコードを追わないと可能かどうかわからないなぁ。
クラスプラグインが使えるのなら、関数をまとめたクラスをTJSで作ると言うことはしなくても良くなる。
当然、その方が自然だし、処理も軽くなるだろう。
ソースを追ってもいいが、聞いた方が早いか。
投稿者 Takenori : 02:05 | コメント (0) | トラックバック
クラスプラグインに関するW.Dee氏の考え
可能ですが、かなり面倒です。
ソースのtjsNative.hや「TJS2リファレンス」の「基本的な使い方」が参考になるといえばなりますが、これはTJS2をアプリケーションなどに組み込む際の話で、吉里吉里用プラグインではかなり勝手が違います。
ArrayとかDictionaryとかを作るメソッドはプラグイン側に提供されているのですが、
クラスそれ自身、それとクラスからオブジェクトを作る際のベースとなるtTJSCustomObject (TJSにおける生の"Object") がプラグイン側に提供されていないのでかなり難しいです。
# tTJSCustomObject と同じ動作の物をプラグイン側で実装してしまうならば別ですが...
プラグイン側でクラスを実装できるようにするのは、TJS2に予定しているクラス関連の仕様の改良が済んでからと思っていたので、ちょっと現状では簡単にはできないかな、と思います。スミマセン。
--------以上、引用終わり
つまり、止めた方が良いと言うことのようです。
自分がこう返答する場合は、「十中八九、私ならしない」と考えている場合なので、クラスプラグインはあきらめることにする。
投稿者 Takenori : 11:10 | コメント (0) | トラックバック
プラグインのライセンスに関して
いずれlicense.txtに追加されることになりそうですが、念のためここにメモしておく。
------以下、引用
license.txtの「● オープンソース」のにある「ここで流用とは、このソフトウェアの一部が他のソフトウェアに組み込まれること」(tp_stub.h / tp_stub.cpp が他のソフトウェアに組み込まれること)に該当しますが、プラグインについては特にそこで求められているような「このソフトウェアに含まれるソースを使用している旨をドキュメント等に表記することか、あるいは、このソフトウェアの作者に配布を行う旨を事前に連絡し確認をとることの、どちらかあるいは両方」は求めない方向で行こうかな、と思います。
ただし、tp_stub.h や tp_stub.cpp 以外の 吉里吉里のソースコードを流用する場合は別です。
ライセンスに補足が必要ですね。入れておこうとおもいます。
ただプラグインをGPLも適用可能なライセンスにしておかないと、吉里吉里のライセンスとしてGPLが選択されたときにその吉里吉里とはリンクできないことになりますのでご注意ください。
もっともGPLを選択可能にするのは強制ではありませんし、プラグインのソースを公開することでさえ強制ではありません。
# 吉里吉里のライセンスとしてGPLが選択された事例は未だ見かけた事はありませんが
投稿者 Takenori : 11:23 | コメント (0) | トラックバック
新構成を検討
W.Dee氏の回答を受けて新たに構成を考える。
って、よく考えたら、初期の構成と同じじゃないのかとふと思ったが、気にしないことにする。
1. 関数のプラグインを作ってTJS2のクラスでラップする。
2. 本体に改良を加える。
以上のどちらかで作成することにした。
で、気分的に心地よいのは、やっぱり2.かな。
とりあえずは、本体に改良を加えると言う方向で行こうと決める。
投稿者 Takenori : 11:26 | コメント (0) | トラックバック
2004年07月29日
こういう仕様にしましょう
----以下、W.Dee氏の返答から引用
もし吉里吉里本体に手を加えられるならば、VideOverlayにレイヤへの画像出力機構を持たせるようになるのかな、とか思っています。
VideoOverlay のなんらかのプロパティにレイヤオブジェクトを指定するとそのオブジェクトに動画が出力されるようになると。
いわゆる「オーバーレイ」では無くなるので VideoOverlay という名前とはちょっと乖離してしまいますが、レイヤの指定領域にビデオを勝手に表示する(結果もともとレイヤのそこの領域にあった画像は上書きされる)という意味ではオーバーレイという意味があり、名前はこのままでかまわないとも思います。
----以上、引用終わり
W.Dee氏の考えに沿う形にしよう。
より詳細な仕様は、もうちょっと調査してから決めることにする。
投稿者 Takenori : 01:05 | コメント (0) | トラックバック
DirectShowで実験-サンプルのビルド
実際に実験を行ってから、少し時間が経ってしまったが、メモしておくのを忘れていたので、ここに追加しておく。
まず、やりたいことはオーバーレイを使わずにDirectShowを使ってビデオを再生することだ。
オーバーレイは以前に一度、DirectX7かその辺りの時に、何となく遊んでみたことがある。とは言っても、そのころのことはほとんど忘れてしまった。
そんな感じなので、とりあえずは良さそうなサンプルをDirectX8.1 SDKの中からか探してみる。(DirectX9でもいいのだが、入れてあったのが8.1だったので、そのままにした)
いろいろと見てみたところTexture3Dが一番近そうだ。
Texture3Dはムービーをテクスチャとして使うサンプルだ。
とりあえず、MovTexture3Dと言うフォルダを作り、そこにこの中身をコピーする。
プロジェクトはVC++6の物のようだ。
気にせずダブルクリックしてVC++.NET 2003を立ち上げる。
プロジェクトを変換するかとどうか聞かれたので、すべて変換する。
何はともあれビルド。
> Textures fatal error LNK1104: コンパイラは、ファイル 'libci.lib' を開くことができません。
と出て、失敗。
旧プロジェクトから変換した時、よく出るエラーだ。
LIBCIをリンクしないようにして、再度ビルド。
> Textures error LNK2001: 外部シンボル "_CLSID_FilterGraph" は未解決です。
> ・・・
なんか、リンク時にいっぱいないと言われる。
いろいろと調べたところstrmiids.libを追加する必要があるようだ。
で、追加したらうまくいった。
そうそう忘れていた。
上記のこと以外に、XSDK/samples/Multimedia/DirectShow/BaseClassesをビルドしてライブラリを作っておく必要がある。
これを忘れているとさらにエラーが出たはず。
以上で、とりあえずビルドが通ったので、改良にかかる。
投稿者 Takenori : 05:07 | コメント (0) | トラックバック
DirectShowで実験-サンプルの改造
Texture3Dサンプルとヘルプでしばらく格闘したところ、DirectShowはDoRenderSampleを勝手に呼び出すようだ。(CTextureRendererはCBaseRendererを継承しているので)
そして、CTextureRenderer::DoRenderSampleではテクスチャをロックしてビデオの画像をテクスチャへコピーしている。
つまり、テクスチャをバックバッファにコピーするようにすれば、とりあえず目的は達成できそうだ。
とりあえず、あんまり何も考えずにIDirect3DTexture8*をIDirect3DSurface8*にキャストして、CopyRectsでコピー。
エラー。
当たり前か。
次にLockRectでちまちまコピーすることにする。
試してみると、バックバッファのサーフェイスがロックできない。
BeginScene － EndSceneの中でやっても、外でやってもできない。
if( pBackBuffer->LockRect( &lrDest, NULL, D3DLOCK_NOSYSLOCK ) == D3D_OK ) ってやっても if( pBackBuffer->LockRect( &lrDest, NULL, 0) == D3D_OK ) ってやってもできない。
何か特殊な方法があるのだろうか？
ふと、IDirect3DSurface8::LockRectとIDirect3DTexture8::LockRectの引数が違うことが気になる。
IDirect3DTexture8はテクスチャのレベルを指定するパラメタが多い。
そして、IDirect3DTexture8::GetSurfaceLevelというメソッドに気付く。
IDirect3DTexture8::GetSurfaceLevelを使えば、、IDirect3DSurface8*が得られるようだ。
早速、取得してCopyRectsを試す。
エラー。
フォーマットが違うとでている。
バックバッファーはD3DFMT_X8R8G8B8だが、テクスチャはD3DFMT_A8R8G8B8。
面倒なのでテクスチャをD3DFMT_X8R8G8B8にしてしまう。
で、実行。
うまく表示されたが、上下逆だ。
DoRenderSampleの引数のIMediaSampleからGetPointerを使って得られるポインタはビットマップ形式のようだ。(つまり上下逆)
反転させるためにIMediaSample::GetMediaTypeを使って、サイズを得ようといろいろやるが、画像サイズは元々メンバにあった。
m_lVidHeightやm_lVidPitchを使えばよいようだ。
で、ビットマップの方を下からコピーするようにして反転させる。
表示させてみると・・・うまく表示された。
とりあえず、こんなもんかな。
謎がいくつかあるが気にしない。
バックバッファがロックできないのは結構気になるが。
でも、それよりもう少しDirectShowをさわる部分をいじっていかねば。
投稿者 Takenori : 06:25 | コメント (0) | トラックバック
IRC チャンネル？
IRC チャンネルとはなんだろう？
初めて聞く言葉。とりあえず、ググる。
上２件のページで調べてみる。
IRC普及委員会
IRC users in Japan Home Page
どうやら、インターネットを使ったチャットシステムのようだ。
httpとかtelnetとかftpとかそんなのの一種だろう。細かいことは気にしない。
次にクライアントソフトを落とす。
TakIRCをインストールして使ってみる。
なんかよくわからない。というより、私が全然理解していないようだ。
吉里吉里のページでは、irc:#kirikiriirc にリンクが張られている。
だから、サーバーにirc:#kirikiriircやirc.kirikiriircなどいろいろと試すがうまくいかない。
よくわからないので、もう一個ダウンロードしてみた。
CHOCOA
そして、さらに調べる。
国内サーバーリストというものがあった。
irc.huie.hokudai.ac.jp
irc.media.kyoto-u.ac.jp
irc.tokyo.wide.ad.jp
irc.fujisawa.wide.ad.jp
irc.nara.wide.ad.jp
irc6.nara.wide.ad.jp
wwwの部分をircに変えたアドレスが基本のようだ。より正確に言うなら、サブドメインで切り替えているようだ。
で、#kirikiriirc はどこかのサーバーのチャンネルらしい。
上のアドレスのいくつかと、TRPG.NETのサーバーに#kirikiriircというチャンネルがないか探すが見つからず。
吉里吉里ページのアドレスにIRCをつけてirc.kikyou.infoとしてみるがつながらず。
いったいどこのサーバーに#kirikiriircはあるのだろうか？
---ちょっと追記
コメントにも書いたのですが、よくよく考えたらここにも書いといた方が良いと思ったのでここに追記。
irc.*.wide.ad.jp は相互接続していますので、どれにつないでも #kirikiriirc チャンネルに入れるはずです。
chocoaならサーバを適当に選びまして「コマンド」から「チャンネルに入る」で「#kirikiriirc」と打ち込みますと吉里吉里チャンネルに入れます。
とのこと、なるほど。
上に書いたアドレスの２個目までしか試していなかったかも。
もう１個試していれば見つかっていたのか。
確認すると、irc.tokyo.wide.ad.jpは試していた。
といっても、チャンネルリストを表示で見ただけだった。
で、チャンネルリストでは表示されていない。
チャンネルへ入るで#kirikiriircと入力すれば入れた。
なるほど、そういうことだったのか。
投稿者 Takenori : 09:25 | コメント (3) | トラックバック
2004年07月31日
DirectShow 実験プログラム作成開始
DirectShow 実験プログラム作成開始
Direct Showのヘルプで関係有りそうなところを読んでみた。
何となくわかったので、次は実践。
で、これから作るプログラムの簡単な使用を書いてみる。
---第１段階---
Direct DrawとDirect Showを使う。
Direct Drawのバックサーフェイスに直描きする。
---第２段階---
複数のMPEGファイルをつなげて再生する。(出来れば切れ目なく)
---第３段階---
[通常再生|2回ループ再生|通常再生]と言った感じで、ループさせる。
---第４段階---
オーバーレイとサーフェイス直描きの切り替えが出来るようにする。
---第５段階---
メモリ上へのプリロードしてから再生を開始する。
とりあえずは、上記のような仕様で徐々に拡張しながら実験(学習用)プログラムを作っていく。
まあ、上記のようなのが作れれば、そこそこDirect Showに関する知識も深まっていることでしょう。
投稿者 Takenori : 05:46 | コメント (0) | トラックバック
バージョン管理について悩む
別に適当にやっていても良いのだが、後のことを考えるときちんとやっておいた方がよいだろうということで、バージョン管理ソフトを入れることを考える。
真っ先に思いついたのは、やっぱりCVSだ。
でも、subversionも気になる。
Apache2も入れていることだし、subversionにするか。(すごい安直です)
そういえば、Apache2なんかのインストールメモを残しておくのを忘れていたのでここにメモ。まあ、こういうのはいっぱいあるから別にここに書いとかなくてもいいけど、自分が一番忘れそうだからね。
Perl
Namazu, kakashi, seach-s
MySQL
WinへのApacheインストール方法
mod_phpインストール方法
後は関連する記事などを
Apache2.0関連記事
WebDEV関連記事
Subversion関連記事
別に一覧にしなくても、リンクはつながっているんだけど、一応。
Apache2を使う時、Perlは5.8系を使わないといけないようだ。
で、Perl 5.8系とApache2をインストールした。
NamazuはPerl5.6以上と書いてあるが、以前上位バージョンを使った時はうまく動かなかったのだが、大丈夫だろうか？
まだNamazuでインデックス作っていないので何とも言えないが･･･、うまくいかなかった時はどうするかなぁ。
------以前のメモ書きコピー終わり
で、まずはWebDAVを試してみる。
とりあえず、このページを参考に設定してみる。
日本語ファイル名対応(mod_encodingの導入)だが、何もしなくてもうまくいった。
インストールしてあるApache 2.0.50なら大丈夫なのだろうか？
それとも、利用環境がWinだけだから大丈夫なのか。
@ITの記事にもうまくいく場合といかない場合があると書いてあるし細かいことは気にしない。
mod_encodingの最新版がApache2.0.48用となっていて、バージョンが少し異なるのも気になるので、とりあえず入れないことにする。
まあ、subversionとか入れて問題が出てきたらインストールすることにしよう。
そして、WebDAVを使ってみた感じだが、いい感じだ。
普通にWebフォルダに設定して使ったのだが、ローカルと同じような感覚で使える。
Windowsの共有じゃなくて、こっちをメインに使った方がよいかなぁと思ったりもするが、よく考えるとどっちも同じだな。
次にsubversionインストールするためにをここからDL。
投稿者 Takenori : 05:47 | コメント (0) | トラックバック
Subversionのインストール
ダウンロードしたのはsvn-1.0.6-setup.exe。
インストールページを探すが、Windows上でのSubversionのインストールを解説したよさげなページは見つからなかった。
でも、インストーラーがあるので実行すればよいかと思い実行。
Nextを押しまくっていたらインストール終了。
で、どうするのさ？
このページを見て、自分のPC内のコンフィグを探すが、見つからず。
C:\Documents and Settings\ユーザ名\Application Data\Subversionってフォルダなんてないぞ。
よくわからないがSubversion によるバージョン管理のインストールの部分から少し読んで、おもむろにリポジトリを作る。
そしたら、C:\Documents and Settings\ユーザ名\Application Data\Subversionが出来ていた。
これで上のページと同じようになったのでこのまま進められる。
Apacheの設定をしてブラウザから見られるようになった。
ただし、Subversionの後半の設定はまだ。
TortoiseSVNをインストール。
ViewCVSも入れたいと思うが・・・Pythonが必要なのか。
面倒なのでまた今度にする。
Pythonも面白そうなので一度遊んでみたいが・・・
とりあえずはこんなところか。
DirectShowで遊びたいし。
投稿者 Takenori : 06:49 | コメント (0) | トラックバック
2004年08月01日
バージョン管理システムについてのメモ
使ったことがあるものと、これから使おうとしているものを比較してみる。
ただ、使ったことがあるものは少々バージョンが古かったりするので、現在のものとは違うかもしれない。
後、あんまり詳しく比較はしない。
と言うか、最もよく使う、チェックイン、チェックアウト、ロック、ロック解除ぐらいしか比較していない。
Visual SourceSafe 6.0
チェックアウト＆ロック、チェックイン&ロック解除を持つ。
チェックアウトするとロックがかかり、チェックインするとロックが解除される。
チェックアウト以外に取得というものがあり、ソースはこれで取ってくる。
取得したソースは読み取り専用属性が付く。
編集する際はチェックアウトする。すると、ソースの読み取り専用属性が解除され、リポジトリ上のソースはロックされる。
編集が終わったらチェックインする。すると、ソースに読み取り専用属性が再び付き、ロックが解除される。
読み取り専用属性はローカルで簡単に解除できるけど、そんなことをしてもあんまり意味がないのでしない。
説明を読んでわかる通り、小規模開発向け。
でも、作りがシンプルな分使いやすい。
チェックアウト＆ロックをした人と管理者が休むと作業が止まってしまうこともある。あんまりないけど、その時はとりあえず叫ぶ。
ただ、マージがほとんど発生しないので、精神的に良い。
マージは非生産的な作業の雰囲気を漂わせている上に、かなりの集中力がいるので、ファイル数が多いと相当辛い。
StarTeam 4.2
チェックイン、チェックアウト、ロック、ロック解除を持つ。
チェックイン、チェックアウトとロック、ロック解除が独立している。
当然、ロックしていないと、他の人が同じソースをチェックインして、マージが発生することがある。
ただし、生産性を下げないためにロックはあまりしない。
そのためマージ作業に遭遇するが、それは諦めるしかない。
もし、他の人が同じファイルをいじっているのを発見したら、出来るだけ早くmakeが通る状態にしてチェックインするのが吉。
そうすればマージ作業から逃れられる。チェックインは早い者勝ちなのだ。とにかく細かく早くリリースしよう。
ただ、焦って致命的なバグを入れてしまわないようにしよう。そんなことをしたら、かなり非難されてしまう。それと、チェックインを急いでいるのは出来るだけ周りに悟らないようにしよう。何食わぬ顔をしながら、素早くコーディングするのだ。
また、周りがどのような作業をしていて、どのファイルをさわっているかに常に気をつけておこう。同じファイルをいじる時期は出来たらずらしたい。かち合う場合はとにかく素早くコーディングだ！
また、ロック機構があるので、担当者に休まれたら叫ぶという状況は発生しうる。
なんか、いいとこなしのような印象を与えてしまうかもしれないが、実際はそんなことはない。
いろいろと機能盛りだくさんだし、それほど悪くはないシステムだ。
にしても、StarTeamってBorlandだったのか。違ったような気がしたが。
そもそも私が使っていたのは4.2とだいぶ古かったので、変わってしまったのかもしれない。
Subversion, CVS
コミット(チェックイン)、チェックアウトを持つ。
まだ使ったことはないので、よく知らない。
ただ、ロック機構がないので担当者不在で叫ぶことはない。
それに、フリーだ。
ただし、CVSはテキストを扱うことを主眼に作られているため、制止画や動画などの扱いは苦手らしい。
Subversionはマニュアルによるとバイナリファイルもうまく扱うようだ。
なお、この項は今後使っていくことで書き換えるかもしれない。
マージへの福音
辛く不毛なマージ作業。そのマージ作業を劇的に楽にしてくれるツールがある。
WinMergeだ。日本語版はこちら。
このツールがあるとマージはかなり楽だ。一度使うとやめられない。
とりあえず、マージする予定があるのならインストールしておこう。
テキストのdiffをとるにも使えるし。
投稿者 Takenori : 05:57 | コメント (0) | トラックバック
DirectShow 実験プログラム第１段階
とりあえずは、以前自分が作ったDirectDrawのプログラムと吉里吉里のソースとDirectShowを使った動画再生とフレームビットマップ取得方法のサンプルソースを参考に作る。
まずは、VCでプロジェクトを作って、draw.libをリンクに加え、Direct Drawの初期化部分を作る。
でも、なんでVCはあんなにAboutダイアログ好きなのだろう。私は、ほとんどの場合使わないのだが。。。
コーディングしながらふと気付く。DirectX5ぐらいのヘルプはないだろうか？
VC.NETのヘルプを見ても、そのあたりの関数は消えている。MSDNを入れれば復活するかなぁ。
そうだ、Cマガの付録から探せばいいんだ。
で、探すとあった。
DX5.2とDX7のヘルプとサンプルソースを入れる。
でも、DX5.2の日本語ヘルプはなくて、なぜかDX3のが入っていた。
まあ、DX7のヘルプがメインになるだろうから大丈夫だろう。
サンプルなどを見ていて思い出してきた。
このころはCOM丸出しだったんだった。
DX7使うにはdxguid.libも必要な様子。
フルスクリーンじゃないとバックバッファ使えないんだった。(本当にそうだったかなぁ？)
とりあえずは、DirectDrawを初期化してから、オフスクリーンバッファのポインタを取得して、そこへ書き込むまでは出来た。
予想外に手こずるなぁ。
DXMediaSDKのヘルプも必要そうなのでコピーしておく。
でも、英語版しかなかった。
まあ、それはともかく次はDirectShowだ。
上述のページによると・・・
streams.hとそれに必要なライブラリがサンプルのディレクトリ内にあり、ビルドするにはSDK内のdxsdk\samples\Multimedia\DirectShow\BaseClassesをINCLUDEディレクトリに追加し、 baseclasses.dswをビルドして得られるstrmbase.libとstrmbasd.libをリンクできるようにしておかなければならない。
・・・とある。
本当なの？と言うか、これ使ってしまっていいの？
後、吉里吉里は固めたファイル内からムービーを読み込むためにMicrosoftから提供されているasyncio.h/.cppとasyncrdr.h/.cppを使っているとか。
吉里吉里のkrmovieのプロジェクトを見てみると、strmbasd.libをリンクしていた。
それに、streams.hもインクルードしている。
やっぱり、必要なようだ。
よくヘルプを見ると、8以前のバージョンでは上記ライブラリはバイナリで提供されていたようだ。
DirectShowについて再びいろいろと調べる。少し理解が深まった。
そして、出来れば、吉里吉里の実装に近い形態で作りたいと思い、コードを追う。
IDirectDrawSurfaceが取得できれば・・・と思って、いろいろと調べるがよくわからず。と言うか、取得方法がない気がする。
結局、Dee氏に質問することにした。
結論はメモリへのポインタとして取得することしかできないとのこと。
まあ、DirectDrawだけだと自由度が低いし、Lock遅いって言うし、そう言う実装になりそうだなぁ。
---それといろいろと聞いたのでメモ
聞いたときのバージョンは吉里吉里２ 2.22 rev.2/ KAG3 3.22 rev.2
オーバーレイクラスにレイヤーを渡し、そのレイヤーへビデオを書いてもらうような作りにする予定だが、そのレイヤーを渡すメソッドでは、TJSオブジェクトが渡されることになる。
つまり、実体はiTJSDispatch2。
そこから、tTJSNI_Layerを得るには、iTJSDispatch2::NativeInstanceSupportをコールする。
paramがプロパティに渡されたtTJSVariant型のオブジェクトだとしてparam.AsObjectNoAddRef()->NativeInstanceSupport(TJS_NIS_GETINSTANCE, tTJSNC_Layer::ClassID, (iTJSNativeInstance**)& tTJSNI_Layer型変数);でtTJSNI_Layerを取得できる。
tTJSNI_Layerで画像そのものへのポインタを得るには、
const void * GetMainImagePixelBuffer() const;
void * GetMainImagePixelBufferForWrite();
tjs_int GetMainImagePixelBufferPitch() const;
などを使う。
レイヤそのものは画像バッファしか持っていないし、DIBセクションであることもDirectDrawのSurfaceであることも期待できない。
ピクセルバッファのみへのアクセスしかtTJSNI_BaseLayerを通じては提供されていない。
DirectDrawは画面解像度の切り替えの時に使用して、あとは最終的な画像を画面に転送する際に(指定によっては)使用するが、そうでもなければ吉里吉里はいっさい使っていない。
レイヤには画像を書いただけだと何も起こらないので、書き込んだ後はtTJSNI_BaseLayer::Updateをコールしなければならない。
tTJSNI_BaseLayer::Updateはメインスレッドから呼ばないと変になるので、メインスレッドから呼ぶような実装にしなければならない。
つまり、別スレッドからイベントを投げて、ウィンドウのメッセージキューで処理すると良い。
TimerImpl.cpp (タイマ) で UtilWindow というのを使って実際にそういうことをやっているので、参考にすると良い。
tTJSNI_BaseLayer::Updateレイヤに変更が有ったという通知をするだけで、実際に描画が行われるのはその後、すべてのイベントが処理し終わった後になる。
イベントがほとんどない場合で、十分高速なPCだと、Updateを30fpsでコールすれば、描画サイクルも30fpsになる。
KAG のクリック待ちのアニメーションや文字表示のタイミングでタイマは使われている。そうでもなければKAGだとタイマは動いてないはず。
吉里吉里の Timer クラスで実装されているタイマーはWindowsの物ではなく、スレッドが一つ立ち上がってて複数のタイミングを管理しており、スレッドは次のタイマのイベントの時間が来るまでSleepで眠ってる。ただ、それだと精度が妖しいので timeGetTimeで補正している。
---メモ終わり
吉里吉里の実装に関するメモは分離して保存しておいた方がよいかも。
続く・・・
投稿者 Takenori : 07:10 | コメント (0) | トラックバック
ファイルの解凍
+Lhacaは時々解凍できずに落ちることがある。
今日はbz2を解凍しようとしたら落ちた。
少し前は1GB超のファイルを解凍しようとしていたら落ちた。
で、cygwinでも入れるかー、とやや落胆しながら考えていたのだが、ふとeoを入れてみた。
すると難なく解凍できた。
解凍はこれからeoにするかな。
+Lhacaは圧縮用だ。
ファイルが壊れていないかどうか確かめるためにMD5を確認する必要があった。
特に何もツールを入れていなかったので、Perlで組むかと、やや面倒臭げに考えるが、以前コマンドラインのツールを会社でDLして使ったことを思い出す。
早速ググって見つける。
これ。
出来た出来た。
投稿者 Takenori : 12:47 | コメント (0) | トラックバック
boost regex++をBCB6に入れる
boostを取ってくる。
展開して、libs/regex/build に移動して、
| make -fbcb6.mak make -fbcb6.mak install |
boost以下のインクルードファイル類はBCBのIncludeディレクトリーへ手でコピー。(なぜmake installでやってくれないのだろうか)
でも、makeはBorlandのやつが使われるようになっていたのか。って、他のmakeはまだ入れていないか。
後、実際に使うのはもう少し先になりそうだ。
投稿者 Takenori : 12:58 | コメント (0) | トラックバック
2004年08月02日
DirectShowっていったい・・・
私は馬鹿なのだろうか？
DirectShowのヘルプとサンプルを見ると何となくわかったような気になる。
でも、コーディングの時になると、やっぱりわからない。
たぶん、それでもほぼ期待した動作をするコードを書くことは出来るだろう。
何かが引っかかる。
グラフビルダーにムービーファイルを渡すと、最も基本的な構成でフィルタグラフを構築してくれる。
自分で構築したいときは、AddFilterを使ってフィルタを追加し、ピンを接続する。
でも、ピンの接続先は指定しない。勝手につないでくれる。
よくヘルプを見るとメディアタイプを指定することで、グラフビルダは正しい位置にフィルタを挿入できるとある。
GraphEditを少しいじってみて、ヘルプを読み直す。
ああ・・・、了解了解。
よく見ると接続先を指定している。
もう少し実験すれば確証が得られそうだ。
Texture3Dサンプルの場合
まず自作のCTextureRendererをグラフビルダーにAddFilterで追加している。
次にグラフビルダーのAddSourceFilterをコールすることで、ファイルを渡されたグラフビルダーがメディアを理解し、残りのフィルタグラフを自動的に構築するようにしている。この時点ですべてつながっているのではないかと思われるが、サンプルを見た感じでは、つながっていないようだ。
そして、CTextureRendererの入力ピンをCTextureRendererからFindPinで取得、ソースフィルタの出力ピンをソースフィルタからFindPinで取得し、その2つのピンをグラフビルダーのConnectでつなげている。Connectは必要であれば、間に適切なフィルタを挿入する。
つまり、グラフビルダーがどこまで自動的に構築できるかをよく認識し、自動的に出来ない部分を手動でつないでやる。と言うことのようだ。
IGraphBuilderとIFilterGraphで、フィルタグラフへのフィルタ追加＆グラフ構築ができる手は限られている。
IFilterGraphはAddFilterとConnectDirectの2つ。
IGraphBuilderはConnect、Render、RenderFileとAddSourceFilterだ。
ちょっとメモ
メリット値
モニカ
続く・・・
投稿者 Takenori : 05:29 | コメント (0) | トラックバック
2004年08月03日
DirectShow 実験プログラム第１段階 - 2
かなり長くなってしまったので分離する。
なんか計画性は皆無だな。
メモ
超高速描画の謎--以前読んだ気もする・・・
DirectShowを扱う部分のコードを吉里吉里のからコピペして、改良していく。
とその前に、コメントとルールを決めておくことにした。
基本的にはDoxygenで自動的にドキュメント(関数リファレンス)を吐かせたいから、Doxygenの書き方には従う。
で、後は項目や細かい書き方だな。
以前、会社で作ったものを参考にしながら、自分の書きたいように作り直す。(こうゆう規約を作るのは、自分が多かったなぁ・・・)
ヘッダーコメントは//スタイルよりも/**/の方が書く量が減るし、書き始めが左に少しずれるので/**/を使うことにした。
そんな感じでだいたい決めた。
そのうち内規として上げておこう。
で、早速コーディングだと意気込んで。
まずはプロジェクトにDirectShowに必要なライブラリなどを加える。
そして、コーディング・・・よくわからない。
ヘルプとサンプル、ソースコードを何度も見直す。
そのうち何とかわかってきた。
とりあえずここにある程度まとめる。
吉里吉里のコードIStream周りを追う。深い。止める。
今回は、ファイルが独立しているので、IFileSourceFilterですませることにした。
ここでふと、Texture3Dを改良したプログラムで音が鳴っていなかったことに気付く。
そこで、GraphEditでシミュレートしようと思うが、独自に拡張したフィルタを追加する方法がわからない。GraphEditのヘルプを見ればいいんだろうが面倒だなぁと思っていると、実行中プロセスのフィルタグラフを見る方法があると書かれている。
そのためには、実行中オブジェクト テーブル (ROT)にプログラムで登録する必要があるらしい。
ここってハッと気付く、Texture3DのソースでなんとかROTと言う関数があって、よくわからない処理をしていたことを。
そう言うことだったのか。
今後は、DirectShowのプログラムを書くときは、デバッグ用にROTへの登録処理を書くことにする。
ちょっと話がそれたが、Texture3Dではそのままでグラフを見ることが出来るようなので、GraphEditで見る。
サウンドの出力がない。
とりあえず、練習用にこれにサウンドの出力を追加してみるか。
まず、DirectSoundのフィルターがなんかよくわからなかったので、IAMDirectSoundかな？と思い、おもむろにグラフビルダーにQueryInterfaceしてみる。後で気付くが、これははっきり言ってアホな行為です。
たぶん、IAMDirectSoundはフィルターではありません。DirectSoundフィルタのインターフェイスの一つです。
しかも、IGraphBuilderにQueryInterfaceしても見つからないと思われる。
まあ、このあたりのことはさらに理解が深まったときに書くとして、結果としてどうやったかを書きます。
CoCreateInstanceでCLSID_DSoundRenderを使い、DirectSoundフィルターを生成します。
フィルタグラフにDirectSoundフィルタを追加します。
MPEG-I Stream SplitterフィルタをフィルタグラフにFindFilterByNameで見つけます。
後は、両者のピンで合致するものを検索してつなげればできあがりです。
見事に音が鳴りました。
にしても、インターフェイスの継承関係を表したクラス図と、各インターフェイスが所持しているインターフェイスがわかる図がほしいなぁ。
どこかにないだろうか？
昔、macromedia DirectorのXDKを使ってXtra(プラグイン)を作るために、そんな感じの図を書いた記憶が・・・
DirectShowで似たようなものを書くのはちょっとしんどいな。便利そうだけど。
落ちていないかなぁ・・・うーむぅ。
まあ、それはいいとして、この実験でDirectShowについての理解がかなり深まった。
続く・・・
投稿者 Takenori : 07:00 | コメント (1) | トラックバック
DirectShow 実験プログラム第１段階 - 3
長くなったので、またまた分割。
ある程度やった内容に沿って、分けた方が良かったのではないかと、反省を始める。
まあ、今後はそうしようと言うことで今回はもう気にしない。
でも、この実験プログラムうんたらの前は分けている。
おいおい退化かよ。
投稿者 Takenori : 08:23 | コメント (0) | トラックバック
Texture3D(改)の最適化
Texture3D(改)は重い。
MPEG Video Decoderから得たIMediaSampleをテクスチャにコピーし、それをまたバックバッファーにコピーしているので、かなり重いだろう。
でも、吉里吉里でも似たようなことになる。
まずは、テクスチャへのコピー処理を小手先で最適化する。少し軽くなった。でも、それほど軽くない。と言うか、重い。
MPEG Video DecoderからRGB24で受け取り、それをX8R8G8B8にコピーしている。
はじめから、MPEG Video DecoderにX8R8G8B8で吐いてもらえば、もっと処理を軽くできるのではないだろうか？
ヘルプのMPEG-1 ビデオ デコーダ フィルタ項を読む。
MEDIASUBTYPE_RGB32がサポートされている。
と言うことは、何とかなりそうだ。
さらに次のような記載がある。
このフィルタは、DirectDraw サーフェスへのデコードも可能である。
DirectDraw サーフェスが使えれば、このコピー処理の固まりは全部すっ飛ばせるのか・・・でも、今回は出来ない。ささっと諦める。
さらによく考えると、MPEG Video Decoderに途中のバッファに書いてもらえばよいのではないだろうか？
そうすれば1回コピーがなくなる。つまり、コピー処理が2/3になる。これはいい。
MPEG Video DecoderにRGB32で中間バッファに書き込んでもらえれば、ほとんどの処理はしなくていい。
吉里吉里ではこの中間バッファがレイヤーに当たるだろうから、かなり手間いらずだ。
でも、拡縮する場合は・・・ぐぉ、中間バッファに書き込んでもらう部分は複雑になりそうだ。
しかし、コピー回数を1回増やすのは避けたい。
まずはMPEG Video Decoderに直接書き込んでもらう方法を調査だ。
軽く調べるがこれはちょっと本腰を入れてヘルプを読まねばならなそうだ。
がんばって読むか。
投稿者 Takenori : 08:45 | コメント (0) | トラックバック
2004年08月04日
シーケンス図が書きたい
DirectShowのヘルプのデータフローの項を読みながら思う。シーケンス図が書きたい。
Visioがあれば、あまり好きではないがVisioでさくっと書くのだが、あいにく持っていない。
で、やっぱIIOSSかなと思い。
おもむろに最新版JavaをDL。もちろんSDKの方。
で、次にIIOSSをDL。
Javaをインストールした後、IIOSSのインストール方法を見ながらインストールする。
IDEはヒープサイズの初期化のところでエラーが出て起動できなかったが、とりあえずはMEFが使えたらよいので気にしないことにした。
これで、いろいろと図が描けるぞぅ。
投稿者 Takenori : 08:45 | コメント (0) | トラックバック
拡縮デコード
デコーダーに直接指定したバッファへ書き込みを行ってもらうことは可能なようだ。
それには、自前のアロケーターを準備すれば良いようだ。
任意位置への拡大縮小描画もできそうだ。
でも、任意位置って使えるのかなぁ・・・
まあ、使う場面はあることはあるか。
別にそうしなくてもいいような気もしないでもないが。
投稿者 Takenori : 09:17 | コメント (0) | トラックバック
Texture3D(改)をメインに
サンプルのTexture3Dを改良していった方が簡単だと思い、その方向で行くことにした。
DirectDrawでいろいろやったのは何だったんだろうと言う考えが、頭をよぎるが気にしないことにする。
で、まずは必要のない3D関連の処理を取り、TextureをSurfaceにする。
デコーダーの出力形式をRGB32にするのは以外と簡単で、CheckMediaType内で受け入れる形式をRGB32にすれば、RGB32で出力してくれるようになった。
それと、MPEGファイル名が直値だったのをプログラムの実行ディレクトリ+ファイル名(直値)とした。
とりあえず、これでだいたい準備は整ったかな。
ヘルプも読んでだいたい理解したので、次はピンとアロケーターの作成だな。
投稿者 Takenori : 09:50 | コメント (0) | トラックバック
バージョン管理
サンプルをいろいろといじるようになってきたので、バージョン管理でもしようと思い立ち、TortoiseSVNをさわる。
リポジトリの内容を見やすいようにViewCVSを入れようとこことここを見る。
参考にしてインストール。
おお、いい感じに表示された。
RapidSVNも入れようとしたが、なぜかDL出来なかった。後でまた試すことにする。
WinMergeをまだ入れていなかったので、ついでにインストール。
マージするときのプログラムに設定しておく。
投稿者 Takenori : 10:38 | コメント (0) | トラックバック
2004年08月05日
ピン、アロケーターの振る舞いの確認
次の手順で進める。
Texture3Dのフィルター部のソースを分離＆整理し、ピンとアロケーターを実装する。
ただし、まずは分離＆整理を行う。
次に何もしないラッパーとして働く ( オーバーライドするが何もしない ) ピンとアロケーターを作り、動作を確認する。
後、もしかしたら、メディアサンプルも実装する必要があるかもしれない。
投稿者 Takenori : 06:50 | コメント (0) | トラックバック
最適化にハマる
このページやこのページを読みながら最適化について少しはまる。
と言うか、元々そう言うことにハマりやすいたちで、今回も例に漏れずハマりかけております。
でも、まだ傷は浅くもう元の道に戻っています。
と言うより、コード量が少なくて最適化の余地がまだあまりなかったり。
投稿者 Takenori : 09:33 | コメント (0) | トラックバック
ソースの整理
レンダーを別ファイルに分離して、ソースの整理を行う。
でも、サンプルとはいえ、グローバル変数多すぎ。
ちょっと考えないと。
リファクタリング・リファクタリング。
投稿者 Takenori : 10:05 | コメント (0) | トラックバック
2004年08月07日
さくっと分離
レンダーを別ファイルに分離して、ソースの整理を行って、ビルドが通った。
グローバル変数はそのまま。
やっぱめんどうだし、そんなに多くないから今はいいやって感じで。
で、次はアロケーターとピンですね。
投稿者 Takenori : 07:50 | コメント (0) | トラックバック
ピンとアロケーターの実装
参考ソースを今まで作ってきた物にあうように若干修正して(ほとんどそのまま、でも、オーバーライドした関数は単にスルーようにした)、ビルド。
デバッガで動きを追ってみる。
次は、アロケーターがDirect Draw Surfaceを返すように改造だ。
いよいよ核心ですな。
でも、CMemAllocatorではなく、CBaseAllocatorを継承した方がよい気がするなぁ・・・
メモリは確保せず、持っているサーフェイスのポインタを渡すだけだし。
でも、要求されたサイズがサーフェイスのサイズを上回っていたらどうするか・・・
エラーにするか、それともメモリ確保をして、多段コピーするようにするか。
デコーダーに渡す時に丸める処理を入れるから、上回ることはそんなに多くないだろうし、エラーにしても他のアロケーターが使われるだけだろうから、たいして問題はないでしょう。まあ、そのときは多段コピーで性能が落ちるけど致し方ない。
投稿者 Takenori : 08:36 | コメント (0) | トラックバック
デコーダーがダイレクトSurfaceに書き込み
アロケーターをCBaseAllocatorから継承するように書き換え、いくつかのメソッドを変更。
なんとか、デコーダーがダイレクトにSurfaceへ書き込んでくれるようになった。
負荷もだいぶ軽くなった。
まあ、640*480*32bppのコピーが1回減ったので当たり前と言えば当たり前。
でも、出力はBmp形式なので、上下逆だ。
吉里吉里はどうなんだろう？
たぶん、上下反転にはなっていないだろうなぁ。
ドキュメントを見た感じもそうはなっていなさそうだし。
吉里吉里より先にDirectShowで上下反転せずに出力できないか調べるか。
出力先の矩形のTopとBottomを入れ替えると逆転しないかな。
マイナス値を使ったり、上のような方法で反転する仕様って言うのは時々あるし。
StretchBltとかそうだし。
で、いろいろ試すが、どこでメディアタイプを設定するのかよくわからない。
もちっと真剣にヘルプを読むかな。
投稿者 Takenori : 10:08 | コメント (0) | トラックバック
2004年08月08日
デコーダーで上下反転
BITMAPINFOHEADERのbiHeightの項を見ると、
ビットマップの高さをピクセル単位で指定する。biHeight の値が正である場合、ビットマップはボトムアップ DIB であり、左下隅が原点となる。biHeight の値が負である場合、ビットマップはトップダウン DIB であり、左上隅が原点となる。
と書かれている。
つまり、VIDEOINFOHEADERのメンバ、bmiHeader.biHeightをマイナス値にすれば、上下反転は実現できそうだ。
でも、BITMAPINFOHEADERの説明の最初に『AVI RIFFファイルの・・・』とか書かれているが、気にしない。
とにかくやってみよう。
と書いたものの、どこでAM_MEDIA_TYPEを設定すればいいのかよくわからない。
レンダーのSetMediaTypeで指定してみるがうまくいかず。って、よく考えたら、レンダーは自前で用意しているんだから当然か。
他に、レンダーのCheckMediaTypeの中に入れてみたり、アロケーターのAllocでMediaSampleに設定してみたり、GetBufferの中でやってみたり、独自のMediaSampleを作ったりしたがどれもうまくいかない。
ネットでいろいろ検索するも有用な情報は得られない。
で、再度いろいろと考えてみる。
Allocの中やCheckMediaTypeの中で行われるのはおかしい。
接続時か、それより前に設定されるべきだ。
そうしないと使えるかどうかわからないはずだ。
そして、ピンのところを見ていると・・・Connectの引数にAM_MEDIA_TYPEを渡せるようになっている！これだ！
途中の試行錯誤は割愛して、手順を説明すると次のようになる。
まずは、普通に接続する。
CheckMediaTypeの時に渡されるMediaTypeで、OKを返した物のコピーを取っておく。
接続が完了したら、デコーダーとレンダラーの接続を切る。
コピーしておいたMediaTypeのVIDEOINFOHEADERのメンバ、bmiHeader.biHeightを *= -1;してマイナスにする。
そして、このMediaTypeを使い、Connectする。
すると、上下が反転された(画面上では反転していない)画像が出てくる。※普通のBMPは上下が逆に格納されている。つまり、上下反転したら反転していないBMPが得られる。
同じ箇所でrcTargetを使えば、拡大縮小なども出来るかと思ったが、うまくいかなかった。
このあたりはまだまだ調査が必要そうだ。もしかしたら、デコーダーでは出来ないかもしれない。でも、効率面を考えると出来るようにしてあってもおかしくないが・・・
まあ、とりあえずは上下反転できたのでよしとしよう。
次は複数ファイルの連続再生だな。
グラフを一から再構築すればすぐに出来そうだが、そうせずに出来ないかなぁ。
ま、いろいろ調べよう。
投稿者 Takenori : 02:03 | コメント (0) | トラックバック
DirectShowメーリングリスト
DirectShowについて語ろうと言う、DirectShow関連の開発に関するメーリングリストがあった。
とりあえず登録しておく。
でも、ログに検索機能がないのですごい見づらい。
途中まで順番に見て行っていたが、見つからずやめた。
何で検索がないんだろう？
MyPageとかに登録すれば使えるのか？
過去ログ全部落として、ローカルでインデックス作って検索するかなぁ・・・かなり嫌だけど。
投稿者 Takenori : 02:40 | コメント (0) | トラックバック
2004年08月09日
ソースの整理とイベント化
上下反転の実験用コードの削除と、連続再生用に少しだけコードを整理する。
Texture3Dでは再描画がメッセージではなく、メッセージループでメッセージがないときに描画&Sleepと言う構成だったので、レンダーのDoRenderSampleがコールされ、サンプルが得られた時点でIMediaEventSinkインターフェイスを使ってメッセージを送信するように変更した。( メッセージはOnRenderEndで送る方が良いかも )
なお、定義済みのイベントではそのような目的の物はなかったので、独自に定義した。
ヘルプに独自定義に関する文章は見つからなかったが、DirectShowのイベントが定義してあるEvcode.hにEC_USERが定義してあったので、たぶんこれを使ってユーザーイベントを定義することになっているのだろうと勝手に解釈し、#define EC_UPDATE (EC_USER+1)と定義した。(ウィンドウメッセージにもWM_USERって言うのがあるし)
よく調べるとDirectX8.1の英語ヘルプのには次のように書かれていた。
Filters can define custom events with event codes in the range EC_USER and higher.
どうやら、上記のような使い方で問題ないようだ。
投稿者 Takenori : 04:38 | コメント (0) | トラックバック
ファイルの差し替え
複数ファイルの連続再生だが、どうやらメモリ上からの再生と同時にやった方が簡単そうだ。
ファイルグラフを再構築するのであれば、話は違うかもしれないが、ファイルを切り替えるにはソースフィルタを作らなければならなそうだ。
まあ、メモリ上からの再生もあるので、このあたりのことはあまり調べていないんだけど。
と言うわけで、次はメモリ上からの再生(ソースフィルタ)の作成に移ることにする。
ソースはAsync フィルタ サンプルと吉里吉里のが参考になりそうだ。
ループ再生はイベントさえ実装してしまえば全然余裕と言うか、すでにループ再生しているので、もう、やってもやらなくてもどっちでも同じだ。
何というか、DirectShow一巡りという感じがしてきた。
パーサー、スプリッター、デコーダーは作らないが、両端のフィルタは作る(作った)ので、だいたいの用途では事足りそうだ。
投稿者 Takenori : 06:15 | コメント (0) | トラックバック
2004年08月10日
高速化への実験
今までのことを整理していてふと気付く。
DirectDraw Surfaceを使えばさらに高速化できるのではないかと。
とは言っても、直接使うことは出来ない。
吉里吉里の仕様上、最終的にはメモリ上にイメージがなくてはならない。
しかし、これは最終的にメモリ上にあれば良いと言うことでもある。
つまり、DirectShowにDirectDraw Surfaceへレンダリングさせ、それを再びメモリへコピーしてこようという作戦だ。
明らかに非効率的な方法のように感じるが、これによって少しCPU負荷が下がる可能性がある。
最近のグラフィックスカードはMPEG再生支援機能という物がだいたい搭載されている。
MPEGのデコードは前フレームとの差分や逆離散コサイン変換などがあり結構重い処理だ。
そして、MPEG再生支援機能とは動き補償やIDCTなどをさすようだ。
当然、MPEGムービーは入力データ量よりも出力データ量のほうが遙かに大きくなる。
あくまで推測だが、、MPEG再生支援機能によって、この少ないデータ量をグラフィックスカードへ送り、グラフィックスカード内で伸張されるのではないかと考えられる。(このようになっていればかなり効率が良い)
つまり、CPUの処理量とメモリコピーの量がかなり軽減されるわけだ。(推測だけど)
しかし、この後でVRAMからメインメモリへのコピーを行わなければならない。
当然これは負荷がかかる。しかも、その後またメインメモリからVRAMへのコピーが発生する。
結局のところハードウェアによってなくなった分とVRAMからメインメモリへのコピーでどちらが重いかと言うことになる。
うーん、微妙ですね。
たいして速くならない気もする。
まあ、興味があるのでちょっとやってみようって感じですね。
投稿者 Takenori : 08:22 | コメント (0) | トラックバック
2004年08月12日
Oleview
IMpegVideoDecoderのことが気になったので、OLEViewで調べてみるが、インターフェイスが見つからなかった。
ハテ？
DirectShowのインターフェイスはどこにあるんだろう？
もちっと真剣に探すかな。
うーん、IMpegVideoDecoderにはそれほど関心がないので、ほっとくか。
OLEViewのことはすっかり忘れていたが、なぜか突然思い出した。
COMのことに関しては、Visual C++プログラマのためのCOM入門がそこそこわかりやすいかも。
まあ、私はmacromedia DirectorのMOAで泣いたので、COMについてはそこそこ知っていたから、本当にわかりやすいかどうかはわからなかったり。
でも、OLEViewについての解説があるので、それはそれで良いかも。って言うか、この本の存在自体しばらく忘れていたんですが。
次こういうことがあったときにOLEViewをすぐ思い出せるようにここにメモ。
って、そん時はこの文書も忘れてそう。
投稿者 Takenori : 06:56 | コメント (0) | トラックバック
DirectDrawSurfaceへの描画方法の調査
ビデオレンダリングフィルタを使えば、DirectDrawSurfaceに描画出来るようだが、そうしてしまうと、描画タイミングを得る方法がわからない。
あるのかもしれないが、調べた限りではわからなかった。
IDirectDrawMediaSampleAllocatorとIDirectDrawMediaSampleを使えば、デコーダーにDirectDrawSurfaceへ直接描画させられそうであるが、これはどうすればいいのだろうか？
どのメディアタイプで接続すれば良いのかがわからない。
アロケーターに呼び出しがかかるのは、レンダー接続時のCheckMediaType呼び出しより後だったはず。
つまり、その時点で受け入れるメディアタイプをどうするかが問題だ。
いや、他ので実験してみればよいのか。
いけるかも。
投稿者 Takenori : 07:09 | コメント (0) | トラックバック
メーリングリストのログDL
やはり、DirectShowのメーリングリストのログから検索したくなり、メーリングリストのログをDLすることに。
DLするために簡単なPerlスクリプトを書く。
以下のような感じ。
※このままでは実行できません。
これでしばらく実行しておけばローカルにログのコピーが置ける。
ローカルにたまったらNamazuでインデックスを作ろう。
$target_url = 'www.freeml.com';
$base_url = 'http://www.freeml.com/message/directshow@freeml.com/';
$target_object = 'message/directshow@freeml.com/';
$start_num =;
$end_num =;
use Win32::Internet;
local $INET = new Win32::Internet(); # WinInetのインスタンスを得る
if( defined( $INET ) ) { # 成功
local $HTTP;
$INET->HTTP( $HTTP, $target_url ); # HTTPのインスタンスを得る
if( defined( $HTTP ) ) { # 成功
$HTTP->ConnectBackoff(2000); # リトライの間隔 (in milliseconds)
$HTTP->ConnectRetries(100);
$HTTP->ConnectTimeout(10000); # in milliseconds
$HTTP->ControlReceiveTimeout(10000);
$HTTP->ControlSendTimeout(10000);
$HTTP->DataReceiveTimeout(10000);
$HTTP->DataSendTimeout(10000);
for( $i = $start_num; $i <= $end_num; $i++ )
{
print "Reading page - $i\n";
$send_command = sprintf("%07d",$i);
{
my $REQ;
$ref_page = "http://" . $target_url . "/" . $target_object . $send_command;
print "Open " . $ref_page ." ... ";
$HTTP->OpenRequest( $REQ, $target_object . $send_command, "GET","", "","text/*\0image/gif\0image/jpeg\0\0",INTERNET_FLAG_RELOAD ); # HTTPのリクエストを生成
if( defined( $REQ ) ) { # 成功
print "Success.\n Reading...";
sleep(1);
$REQ->SendRequest(); # リクエストを送る
$file = $REQ->ReadEntireFile(); # 返ってきたデータを読む
$REQ->Close(); # リクエストを閉じる
{
open( FOUT, ">$send_command.html" ) or die "cannot open file!";
print FOUT $file;
close( FOUT );
}
}
else {
print "Fail.\n"
}
}
}
$HTTP->Close();
}
$INET->Close();
}
投稿者 Takenori : 09:20 | コメント (0) | トラックバック
Namazu Perl5.8で動かず
DLしたメーリングリストログにNamazuをかけようとしたが、すぐ落ちてしまった。
やはり、Perl 5.8系では動かないのだろうか？
いろいろと調べたりするのが面倒なので、Perl 5.6系が入っている方のマシンでインデックスを作ることにした。
インデックスさえ作ってしまえばこっちのものだしね。
投稿者 Takenori : 11:42 | コメント (0) | トラックバック
2004年08月13日
IDLファイル
COMのインターフェイスを定義(宣言？)したIDLファイルがあることを思い出した。
IMpegVideoDecoderのインターフェイス定義もあるかと思い、grepをかけたが見つからなかった。
IMpegVideoDecoderに関する情報は全くないなぁ。
投稿者 Takenori : 06:27 | コメント (0) | トラックバック
Asyncサンプル
メモリから読み込む場合、このサンプルがほとんどそのままっぽい。
Base部分は吉里吉里と同じ？
とりあえず、memfileのソースを読むが、やっぱり簡単そうだ。
でも、BaseやFilterを見ると･･･って、いつものようになるのだろうか？
Filterを軽く見た感じではそうでもなさそうだ。
Baseがいろいろとやってくれているのだろう。
でも、Baseのソースを見ると・・・いろいろとややこしそうなことをしている。
面倒だなぁ。
Baseはあんまり見ずに、そのまま流用でいいかな。
吉里吉里ソースを見直すとIStreamを渡すようになっている。
つまり、メモリ用のIStreamのなんかを作ればいけるのか？
ファイル用のIStreamはSHCreateStreamOnFileをコールするだけでいけるようだ。
でも、COMってどうやって作るんだっけ？
すっかり忘れてしまった。
投稿者 Takenori : 09:23 | コメント (0) | トラックバック
マルチメディア ストリーミング
IDirectDrawMediaSampleAllocatorのことについて調べていて、
IDirectDrawMediaStreamを発見する。
どうやら、IDirectDrawMediaSampleAllocatorを使うには、IDirectDrawMediaStreamを使わなければならいなような雰囲気だ。
しかし、IDirectDrawMediaStreamはインターフェイス一覧にない。
なぜだ？
うーん、MicrosoftのDirectDrawをなくしたいと言う思惑だろうか？
まあ、使用禁止インターフェイス一覧になかったら気にせずに使おう。
そして、IDirectDrawMediaStreamの項を見ているとマルチメディア ストリーミングへのリンクがあった。
マルチメディア ストリーミング？
そんなのあったっけ？と思ったら、ヘルプ付録にあった。
うーん・・・普通のところに書いていて欲しかった。
まあ、とにかくマルチメディア ストリーミングの項を読まねば。
・・・
例によって例のごとくよくわからない。
いや、よくわからないと言うか、今回のような構成で使用できるのかどうかがわからない。
マルチメディア ストリーミングはどうやらファイルを与えて、任意のサンプルを得るための仕組みのようだ。
つまり、適当につなげて･･･と言うような用途には利用できないのかもしれない。
マルチメディア ストリーミングの入力はファイルかモニカを使用するようだ。
モニカについてはよくわかっていない。
調べた結果、オーバーレイかマルチメディア ストリーミングを使用しないとDirectDrawへ直接書き込めなさそうだ。
しかし、MPEG-1 ビデオ デコーダ フィルタの
＞ このフィルタは、DirectDraw サーフェスへのデコードも可能である。
と言う一文がかなり気になる。
何らかの方法でDirectDraw サーフェスへ直接書き込めそうなのだが・・・
とりあえずは、そのことを気にとめておいて、メモリ上からの再生とオーバーレイの切り替えを先にやろう。
オーバーレイ、マルチメディア ストリーミング、モニカはその過程でわかっていくだろう。
投稿者 Takenori : 09:40 | コメント (0) | トラックバック
2004年08月14日
ＭＳＤＮをインストール
COMの部分が日本語化されていないかなぁと言う淡い期待を抱きながらMSDNの2004/07をインストール。
やっぱり、英語のままだった。
仕方ない、英語を読むか。
吉里吉里のコードを見て、IStreamについてはだいたいわかったが、IMonikerについては手掛かりがない。
MSDNを入れるついでに一緒に入っているSampleソースもコピーしておいたので、Grepをかけるが、それっぽいのは見つからなかった。
ふと思い立ち、DirectShowのサンプルに対してGrepをかけたら、いっぱい出てきた。
モニカはCOMオブジェクトを一意に識別する仕組みっぽい。
で、マルチメディア ストリーミングで使われるモニカはデバイス モニカかファイル モニカとなっている。
モニカはよくわからないし、いろいろと面倒だなぁ。
とりあえず、マルチメディア ストリーミングはほっとくか。
メモ (ちょっと関係ない)
DirectShowのビデオキャプチャプログラミング
投稿者 Takenori : 01:23 | コメント (0) | トラックバック
ソースフィルタの変更
asyncio.h/.cppとasyncrdr.h/.cppをそのままコピーしてきて、吉里吉里のCIStreamReaderとCIStreamProxyを別ファイルに分離して、それをインクルード。
VC.NET 2003でビルドするとasyncio.cppでビルドエラーが。
単に型チェックが厳しくなっただけのようだ。
asyncio.cppの422行目のCreateThreadへ渡す関数ポインタを(LPTHREAD_START_ROUTINE)にキャストしたらビルドが通る。たぶん、これで大丈夫だろう(あまりこういうことはしない方がいいけど)。
ビルドが通ることを確認したので、ソースフィルタを変更する。
と言っても、AddFilterでCIStreamReaderをグラフに追加し、その出力ピンとレンダーをつなぐだけ。
IStreamはとりあえずSHCreateStreamOnFileでお手軽に生成。
でも、SHCreateStreamOnFileに渡すファイル名はなぜかマルチバイト文字セット。
仕方なく、WideCharToMultiByteで変換する。
なんで、ワイド文字列（Unicode）じゃないのだろうか？
シェル系はワイド文字列が多かったはずだが・・・あれ？逆だったかな？
まあ、いいか。どっちでも。面倒だけど。
で、前回と同じように再生されることを確認。
なんか、かなりあっさりと出来た。
次はいよいよメモリからの再生。
でも、そんなに難しくはなさそう。
IStreamを継承したクラスを作って、ぽんっと渡せば済みそうだし。
投稿者 Takenori : 07:25 | コメント (2) | トラックバック
2004年08月15日
連続再生について
今日はとあるイベントに行った後、アキバへ行ったりしていたので進捗がないが、昨日考えたことをここに記しておく。
遅延なく連続再生するためにメモリ上にデータを置こうと思っていたが、そんなことをしなくても、ディスクに一度アクセスすればキャッシュがきいてほとんどの場合遅延なく読み込めるのではないかと思う。NT系のディスクキャッシュは強力だし。
で、それより問題になると思われるのはグラフの再構築だ。
もし一から構築しなおすと、完全につながらないのではないかと考えられる。
何となくだが、グラフの構築はそこそこ時間のかかる処理のように見える。
そこで、どうするか？ だ。
簡単に思い付くのはフィルタグラフを複数作っておくという物だが・・・ 複数作っても大丈夫なのだろうか？ また、うまく切り替えられるのだろうか？
次善の策としてはソースフィルタの差し替えだ。
すべてを作り直すのではなく、次のムービーのソースフィルタのみを事前に準備しておき、切り替え時にその部分のみつなぎかえると言う方法だ。
どっちにしても、ソースコードを整理しないといけないので、どちらを選択してもいいのだが、ソースフィルタの差し替えで済むのならそれが一番なので、まずは差し替えを試してみることにする。
投稿者 Takenori : 10:09 | コメント (0) | トラックバック
2004年08月16日
ソース整理・構成の変更
CIStreamProxy、CIStreamReader、IStreamはCMovieに、グラフ系のはCPlayerに入れる。
HRESULTからAMGetErrorTextでエラーメッセージを作ってくれるexceptionクラスも作っておくことに。
でも、まだ整理中。
さっさときれいにしないとねぇ。
と言うか、もっと早くやっとけよ。って気が。
でも、他のユーティリティー的なのはどうするか？
グラフ関連のが多いから、そう言うクラスを作ってまとめるかな。
うーん、行き当たりばったりだけどいいのかなぁ。
少し、きちんとモデリングした方がいい気がする。
まあ、吉里吉里に組み込む時にやるか。
そうしよう。
投稿者 Takenori : 07:55 | コメント (0) | トラックバック
2004年08月17日
CComPtrの代入時の振る舞い
COMのインターフェイスを管理する時はATLのCComPtrを使うと楽だ。
ソースはatlcomcli.hにある。
で、代入時の振る舞いがちょっと気になったので調べてみた。
中ではAtlComPtrAssignが呼ばれている。
その中を見ると次のような感じ。
if (pp == NULL)
return NULL;
if (lp != NULL)
lp->AddRef();
if (*pp)
(*pp)->Release();
*pp = lp;
return lp;
やっぱ代入元もAddRefされてるんすね。
と言うことは、呼び出し元管理のインターフェイスは代入後Release呼んどいた方が良さそうだ。
投稿者 Takenori : 02:16 | コメント (0) | トラックバック
ソースの整理2
エクセプションクラスは組み込めた。
そのおかげで例外処理部がきれいになった。
ユーティリティー的なのは全部CPlayerに入れてしまうことにした。
そして、MPEG依存部分 ( フィルタ名を直指定で検索している箇所がある ) をなくしていく。
しかし、ソースの整理と同時にやると面倒なことになる可能性があるので、とりあえずは従来の処理を有効にしておく。#if #else #endifで分けておく。(リファクタリング時に機能追加しないのは基本らしいし)
ソース整理はもう少しかかりそうだ。
ビルドして動かす間でしばらくかかるので、時々中だるみする。
やっぱり、細かくやっていった方がいいな。
投稿者 Takenori : 10:29 | コメント (0) | トラックバック
2004年08月18日
ある程度整理できた
一通り整理して、ビルドが通り、動くところまでいく。
でも、いくつか問題が。
ソースフィルタにQueryInternalConnectionsがインプリメントされていないので、そこからスプリッターが取得できない。
とりあえずは問題ないが、再接続時に困る。
フィルターを列挙してそれで何とかなるのかな。
まあ、やってみよう。
他にもまだまだきちんとしていないところが・・・
MPEGに依存している部分や、関連が混み合っている部分がある。
まあ、ビルドが通るようになったので、少しずつ整理していこう。
投稿者 Takenori : 10:53 | コメント (0) | トラックバック
2004年08月19日
接続しているピンの取得
接続しているピンを取得するには、IPin::QueryInternalConnectionsではなくIPin::ConnectedToを使えばいいようだ。
QueryInternalConnectionsはインプリメントされていない場合があるが、ConnectedToにはそのようなエラーは定義されていない。
たぶん下位の部分で実装されているのだろう。
これで、スプリッターのピンの問題は解決した。
次はソースフィルタを差し替えれば、次のムービーが再生されるはず。
投稿者 Takenori : 07:54 | コメント (0) | トラックバック
ソースフィルタの動的再接続
ヘルプの動的再接続のソースを参考に、と言うかほとんどそのまま実装してみる。
が、いきなりQueryInterfaceでインターフェイスがないと返ってきて終了。
何ーぃ。
まあ、サンプルはソースフィルタではなく、途中のエフェクトフィルタだったので若干異なるのかもしれない。
でも、このIPinFlowControlがないと動的再接続が出来ないのだが・・・
ヘルプを読むと次のように書かれている
---以下引用
フィルタ開発者へ : 動的な再接続をサポートするパーサー フィルタとキャプチャ フィルタでは、その出力ピン上でこのインターフェイスをサポートしなければならない。通常、その他のタイプのフィルタでは、このインターフェイスを実装する必要はない。
---引用終わり
ソースフィルタはサポートしていなくても良いと言うことだろうか？
そもそも、ソースフィルタを差し替えるには他の方法があるような気がしてならない。
さてどうしたものか。
基本的にソースフィルタを差し替えたい場面はムービーの終点になる。
つまり、すでにストリームにはデータは流れていないはずだ。
なら、そのままはずしてしまえばよいのではないだろうか？
とはいうものの、やっぱり危険な香りがするので、IMediaControl::Stop()を事前に呼び出し、フィルタを停止状態にしておくことにする。
しかし、この場合ムービーのつなぎ目に隙間が生じてしまう可能性がある。
まあ、隙間が出来たら、ソースフィルタのみを停止し、つなぎかえれば何とかなるのではないだろうか。そのときはそのときにいろいろと考えよう。
で、IMediaControl::Stop()を呼び、IPinFlowControl::Block()は呼ばずにIGraphConfig::Reconnectを実行してみたのだが、入力ピンがIPinConnectionをサポートしていないと返ってきて終了。
・・・
なんですとー。
まあ、毎度のことなんだけど・・・
よし、自分でDisconnectを呼んで、その後また自分で繋ごう。
で、やってみたらなんかうまく再生されない。
GraphEditで見てみると・・・
めためたです。（涙
本来は次のようにきれいにつながっています。
でも、よく見てみると、スプリッターから先がぶった切れているだけのようだ。
なら面倒だが、再度繋げば大丈夫なんだろうか？
でも、そうすると一から構築するのと大差ない気がするのだが・・・
さてどうした物か。
とりあえず、どの辺りでぶった切れているのか調べると、ソースフィルタをDisconnectした後にすでに切れてしまっているようだ。
うーん・・・
明日考えよう。
投稿者 Takenori : 08:48 | コメント (0) | トラックバック
2004年08月20日
グラフの再構築
再接続は少し面倒そうなので、もう一度一から作る方法を試してみることにした。
作ってみてみると・・・つながっているけど、隙間が空いていないのかどうかわからない。
まあ、つながっていないムービーをつなげてもわかるわけないか。
まずはつながっているムービーを分割して用意する必要がありそうだ。
バックに音楽が流れていたらなおよしだが、それはかなり厳しそうだ。
音楽がとぎれなく聞こえるようにするのは可能なのだろうか？
専用の物を作らないと厳しそうだが・・・最近のPCなら難なくやってのけてしまうのだろうか？
とにかくやってみないことにはわからないな。
次に全体をループさせる(1->2->3->1・・・と言う感じ)ように作ってみるが、なぜか同じ物を使おうとしたら適切な中間フィルタがないと言ってくる。
フィルタグラフが削除された時に何かされているのだろうか？
自分で事前にグラフからフィルタを削除したり、Disconnectしたり、いろいろとやってみるが結果は変わらず。
少し考えてふと気付く、ファイルの位置が終端に達しているからでは？と。
とりあえず、IStream::Seekで位置を先頭に移動させる。
が、効果なし。
IMediaPosition::put_CurrentPositionで先頭に移動させても効果なし。
なんなんだろうか？
投稿者 Takenori : 09:00 | コメント (0) | トラックバック
フィルタグラフの複数生成
ヘルプを見ていると、どうもフィルタグラフは複数存在していても良いようだ。
それなら、初めに複数のフィルタグラフを生成しておき、順番に再生していけばうまくいきそうだ。
で、早速試す。
うまくつながっているけど、完璧につながっているかどうかはわからないなぁ。
そこで、アニメのOPを5秒ずつに分けた3つのムービーを準備し、再生してみた。
が、やっぱりつなぎ目で音がとぎれるし、絵も一瞬ぼやける。しかし、MPEGなんだから、その絵が完璧に一致しないのは仕方ないだろうと思う。
問題は音だが・・・やっぱり一瞬とぎれてしまうよなぁ。
完全に繋ごうと思ったら、ソースフィルタからデコーダーへ流れるデータをとぎれないようにしないといけない。
そうするとソースフィルタを工夫しないといけないのだろうか？
そもそもそこまで必要かどうかと言う問題がある。
ムービーをつなげて作る場合、シーンが切り替わるところにムービーの接続点を持ってくるだろう。そうすれば、たいして違和感なく表示される。
また、バックに音楽を流す場合は、ムービーとは別に音楽を流せば何とかなるのではないだろうか。
つまり、完全につながっていなくても大丈夫な気がする。
ま、作り手の工夫次第っすね。
投稿者 Takenori : 09:10 | コメント (0) | トラックバック
オーバーレイの対応
レンダーがデフォルトの物でいいので、グラフ作成部分がすごい簡略化された。
で、再生！
・・・ ウィンドウが4つ出来た！！
やったね！っておい。
オーナーウィンドウや位置を設定しとかないといけないようだ。
設定すると問題なく表示できた。
これでとりあえず目標は達成だな。
次は吉里吉里への組み込みだ。
でも、その前にどのような構成にするか検討しないと。
なんとなく、KAGのソースを見てみる。
ウィンドウがムービーオブジェクトを持っているんすね。
KAGの方の改造はそれほど大変ではなさそうだ。
そして、ふと気付く。
KAGに構文を追加しようと思ったらパーサーをいじらなければならないのではと。
でも、ほとんど予約語追加と対応する処理を記述するだけとかで出来るんじゃないかなぁと期待を抱く。
何となく見た感じだとbisonは使っているけど、flexは使っていないような感じだったけど・・・
ま、その辺は追々だな。
初めはKAGでTJS直打ちすれば済むし。
投稿者 Takenori : 09:28 | コメント (0) | トラックバック
ダブルバッファリング
最新の吉里吉里をチェックアウトして、メイクしている間、どのような仕様にするか考えていて思い出す。
デコーダーに直接レンダリングさせるのならダブルバッファリングしないといけないんだったと。
でも、どうやればいいのだろう？
たぶん、メディアサンプルかアロケーター辺りをいじればいいんだろう。
で、また実験することになった。
投稿者 Takenori : 10:26 | コメント (0) | トラックバック
2004年08月21日
ダブルバッファリングの実験
CMediaSample::SetPointerを使えば出来そうだ。
ヘルプには、
このメソッドは IMediaSample インターフェイスを通しては使えない。サンプルを作成したオブジェクトは (CMediaSample を通して) このメソッドにアクセスできるが、他のオブジェクトはアクセスできない。
とある。
そこで、自前のアロケーターにCMediaSampleを保持しておくようにし、新しいバッファを設定する関数を追加した。
そして、CBaseRenderer::DoRenderSampleで、サンプルのポインタをすげ替えたら、うまくいったようだ。
描画部分はダブルバッファにしていないが、交互にバッファが使われているのを確認した。
これでダブルバッファリングの問題は解決した。
投稿者 Takenori : 07:10 | コメント (0) | トラックバック
2004年08月22日
ムービー内移動
連続再生は止めて、ムービー内の任意のフレームへ移動できる機能を実験してみた。
単純に一部の区間をループし、クリックされると次へ移行、また次の区間でループするという物。
複数ムービーをつなげるよりもスムーズにつながった。
まあ、元々一つのムービーなんだから当然と言えば当然かもしれないが。
ただ、かなり離れたフレームへ移動する場合もうまく行かどうかは不明。
でも、たぶんなんとかなるでしょう。(根拠なし)
ただし、この実験では独自レンダーから、フレームごとにイベントを発行しているので、フレームの切り替わりを取得できるけど、オーバーレイのレンダーを使った場合は取得できない。
たぶん、なんとかできそうな気がするけど、今のところ不明。
投稿者 Takenori : 09:44 | コメント (0) | トラックバック
吉里吉里をメイク
kirikiri2/src/core/environ/win32/bcb6/tvpwin32.bprを使ってメイクしてみる。
インクルードファイルがいくつか足りないと出た。
前もらったやつからコピーし忘れていたようだ。
再度メイク。
ライブラリがいくつか足りないと出た。
コピーし忘れていたようだ。
再度メイク。
boost関連でリンクエラーが出る。
1.31.0にパッチを当てずにライブラリを作っていたので、今度はパッチを当てて、makeしインストール。
しかし、やはりboost関連でリンクエラーが出る。
なんだろう？
バージョン違いかな？
---以下追記
バージョン管理されている最新のソースのmakeにはboost 1.30が必要なようだ。
1.31.0だとなぜか通らない。
なお、このときの最新のリリースバージョンは吉里吉里 2.23 β3。
投稿者 Takenori : 12:48 | コメント (0) | トラックバック
2004年08月23日
なにげにFlashの方も見てみる
COM ( ActiveX ) ですな。
メッセージはサブクラス化(?)しているように見えたが、コメントアウトされている。
でも、これがフックって言っていたやつですな。
フックという呼び方の方が正確なのだろうか？
Codianではフックと書かれている。
サブクラス化とフックは厳密には異なるのだろうか？
何となく違うようだが今は細かいことは気にしないことにした。
っていうか、これはまた面倒ですな。
Flashのレイヤー描画は考えないことにしよう。
投稿者 Takenori : 06:43 | コメント (0) | トラックバック
ムービー拡張仕様(仮)
VideoOverlayクラスのインターフェイスの拡張仕様を考える。
次のような物にしようと考えているが、追加削除がありそうな臭いぷんぷん。
メソッド
close ( メディアを閉じる )
open ( メディアを開く )
play ( 再生開始 )
setBounds ( 再生矩形の位置とサイズを指定 )
setPos ( 再生