Re: 動画の使い方について2 ( No.1 ) |
- 名前:通 日時:2008/08/22 13:06
>(1)
ゲーム内のFPSと動画のFPSはあっていますか?
関連するかどうかは未調査ですが、
違うとやはり不安定になる気がします。
>(2)
「動画の使い方について」のほうでIWさんも
言っていますが、再生時の準備による処理に
よる物ではないでしょうか?
#これもどの様に動画をシークしているかによる
#気がします。
>(3)
ビットレートが低ければその分画像は軽くなり
再生にいたるまでの処理は多少軽減されると思います。
が、(1)の回答がズバリだと問題が出るかもしれません。
>(4)
一番軽いのは「無圧縮AVI」です。
無圧縮AVIはBMPイメージの連番なので
サイズはより大きくなります。
#拡張子aviのファイルがすべて
#無圧縮AVIとか限らないので注意
>(5)
これは他の人にも測定してもらったほうが良い様な
VGAで無謀ならはっきりいって無理のレベルでは
無いかと思われます。。。
|
Re: 動画の使い方について2 ( No.2 ) |
- 名前:IW 日時:2008/08/22 21:56
>1
動画の再生は一般的にリアルタイムな時間で制御されます。
瞬間的に重い処理が走ったりしてそのフレームだけ時間がかかったりすると
次のフレームの動画がその分飛んでしまうことがあるかもしれません。
>2
動画の最後まで再生したらシークで最初に戻して再度再生する。
これで綺麗につながらない場合、動画データを最後まで読み終わったら
間髪入れずに先頭を読みに行くよう、動画の読み込みをスケジューリングすれば
いいような気がします。
面倒なら普通に2本動画読み込んで、一方を先頭で再生準備だけして待機させ
もう片方の再生します。
その再生が終わったら待機していた方を再生させるとかで(1フレームくらい
止まってしまうかもしれませんが)ある程度綺麗につながるかもしれません。
>3
軽くなると思います。
でも多分解像度も合わせて下げた方が顕著に軽くなるかと思います。
>4
環境に(略)。
aviはコーデックにも依るので比較はできませんが、WMV/MPEGとでしたら
MPEGの方が軽い気がします。
が、どのデコーダを使っているのかで変わってくるかもしれません。
>5
デュアルコアで、CPU使用率が50%ということは片方の CPUはフル稼働している
ということですか?
高ビットレートなのでしょうか?
# 今までPCゲームで背景を動画にしたゲームがあったかどうか、あるなら
どんな感じだったのか調べてみてはどうでしょうか。
|
Re: 動画の使い方について2 ( No.3 ) |
- 名前:管理人 日時:2008/08/24 02:23
反応が遅くなり申し訳ありません
現在の動画再生処理は制御が大雑把で外部コーデックに頼らなくてはいけないものだったので、
Ogg Vorbis のように内部にデコードコードを含められるよう、Ogg Theora のライブラリを
組み込んでみました。
これによって今後 Ogg Theora を使用する限りはコーデック周りの問題になやまされることもなく、
またフレーム単位の制御が可能になったので、まだ未整備ですがループもスムーズに行うことが
(後々)可能になると思います。
( PlayMovieToGraph にループ指定が出来るようになると思います )
ただ、処理負荷は恐らく今までより上がりますので(少なくともメディアプレーヤーで動画を
再生する場合よりも負荷は高いです)、背景に 640x480 の動画を使用しようとすると
かなり高速なCPUが必要になると思います・・・( 一応デコード処理は別スレッドで行って
いるので2コア以上のCPUでしたら結構いけると思うのですが、逆に1コアのCPUだと
かなりキツイです・・・)
力及ばずで申し訳ないのですが、これだけはビットレートを下げたり、解像度を落とす等の
対処をして頂くしかありません。orz
Ogg Theora 動画を再生できるようにしたバージョンはこちらにアップしましたので、
よろしければダウンロードしてください。
http://homepage2.nifty.com/natupaji/DxLib/DxLibVCTest.exe //VC用
http://homepage2.nifty.com/natupaji/DxLib/DxLibBCCTest.exe //BCC用
(中身を既存のライブラリのファイルに上書きして、BCCをお使いの
場合は『再構築』、VCをお使いの場合は『リビルド』をして下さい)
Ogg Theora 動画へ変換するソフトは少ないのですが、とりあえずこちらが使い易そうです
http://cowscorpion.com/MultimediaTools/FreeAnime.html
あと、動画のループのテストプログラムもこちらにアップしましたので宜しければ
ご覧になってみてください。
現状ループ時は再生時よりも処理負荷が高いので、CPUパワーが足りないと
一瞬と待ってしまいます。(ただ、これは今後ループすることを前提にした処理を
実装することで改善される可能性大です)
http://homepage2.nifty.com/natupaji/temp/MovieLoopTest.zip
> 1
今までの動画再生処理は完全に DirectShow 任せなので、何が原因かはわかりません
> 2
元々 DirectShow の動画再生処理はスムーズにループ再生するというシチュエーションを
想定していないと思いますので、一度停止して再生準備を行って再生、という手順に
時間がかかっているのだと思います。
現状のバージョンでは IW さんの案が有効かもしれません。
> 3
恐らく軽くなります。これは今回実装した Ogg Theora でも同様のことが言えます。
> 4
恐らく一般的なフォーマットの中で一番軽いのは mpg です。
因みに avi は wav と同じで avi だからといって1形式ではありませんのでご注意を。
(wav は大抵の場合無圧縮の生PCMデータですが、avi の場合は無圧縮動画であることは自前で用意
しない限りまずありません)
> 5
ターゲットの環境をどれくらいに設定するかによります。
現状では 640x480 の動画を使用する場合、ビットレートやフレームレートにもよりますが、
弾幕STGを同時に動かすことを考えると恐らく 3GHz 以上のシングルコアCPUか
2GHz 以上のマルチコアCPUが必要になってくると思います。
因みに一番処理負荷軽減の効果があるのは解像度を落とすことです。
その次に効果があるのはフレームレートを下げること・・・・
|
Re: 動画の使い方について2 ( No.4 ) |
- 名前:管理人 日時:2008/09/01 10:01
ループ再生に対応しました。
PlayMovieToGraph の第二引数に PlaySoundMem の第二引数と同じように
DX_PLAYTYPE_LOOP とすれば綺麗にループ再生されます。
(ただ、音の長さと動画の長さが違うと綺麗にループできません)
http://homepage2.nifty.com/natupaji/DxLib/DxLibVCTest.exe //VC用
http://homepage2.nifty.com/natupaji/DxLib/DxLibBCCTest.exe //BCC用
(中身を既存のライブラリのファイルに上書きして、BCCをお使いの
場合は『再構築』、VCをお使いの場合は『リビルド』をして下さい)
一応がっちり整備したのは Ogg Theora の再生部分だけですが、
avi や mpg 等の外部コーデックを必要とする動画の再生部分も
ループするようにしたので(再生を停止して、ファイルの先頭にシークして、
再度再生、というコードを入れただけですが・・・) もしかしたら
Ogg Theora 以外の動画ファイルのループ再生も少しマシになっているかもしれません。
|
Re: 動画の使い方について2 ( No.5 ) |
- 名前:Dixq 日時:2008/09/02 15:18
急に帰省することになり、しばらくPCが使えませんでした、
皆様お返事が遅くなり申し訳ないですm(_ _;)m
通様、IW様、管理人様、丁寧なアドバイスありがとうございます。
>(1)
>ゲーム内のFPSと動画のFPSはあっていますか?
一応あっています。
ゲームは60FPSで、動画は30FPSと60FPSのものを両方試してみました。
>動画の再生は一般的にリアルタイムな時間で制御されます。
なるほど、関数の仕様を見ると、どうも連続したフレームで順番に描画するのではなく、
その時間にあった描画すべきデータをとってくるような印象ですね。
>(2)
>管理人様
ループ再生への対応ありがとうございます。非常に助かります。
(2)の問題はこれで解決させていただこうと思います。
>(3)
なるほど、ビットレートをさげ、FPSを下げ、解像度を下げたほうがいいようですね。
シューティングにおいて、飛んでいるキャラクタはキレイなのに
背景が汚いとマッチしない恐れがありますが、
その辺どの位にすればいいか試行錯誤でやってみようと思います。
>(4)
>一番軽いのは「無圧縮AVI」です。
この件なんですが、こちらで無圧縮AVIを用意して再生したところ、
再生すらまともに出来ないです・・・。
300Mbpsということで、この勢いで読み込みが出来ていないのでは・・?
と言う印象を受けるのですが、どうなのでしょう。
素人が勝手に推測すると、読み込みの早さは早くなっても、読み込む量が膨大になるので、
結局遅くなってしまうのではと思ったのですが、
どうでしょうか?
今用意してみた動画が42GBもの容量だったので、
無圧縮AVIはとても無理ではありますが・・。
>(5)
>高ビットレートなのでしょうか?
そこまで高ビットレートでもないです。
1000〜2500位で試しました。
>ターゲットの環境をどれくらいに設定するかによります。
確かに仰る通りですよね。
Crysisのように、一部のPCユーザーにしか遊べないようなゲームにしてしまえば
キレイな映像をもとめることができるでしょうが、
なるべく2Dシューティングごときでそこまで絞りたくないのが本音です;
今の四聖龍神録ですら重いと言われ、2D弾幕STGなら東方を基準にされてしまいがちだと
思うので、どうにか軽く出来ないか試行錯誤してみます。
今回動画を使おうと思ったのは、
3Dモデリングソフトや3D景観ソフトでレンダリングした動画を
ゲームで使いたかったからです。
DXライブラリで本格的な3D背景を表現したいと思い、このような選択をしました。
何とか実現してみたいと思っています。
また、今回色々とDXライブラリの機能を拡張してくださりありがとうございました。
大事に使わせていただこうと思います。
|
Re: 動画の使い方について2 ( No.6 ) |
- 名前:通 日時:2008/09/02 17:04
>一番軽いのは「無圧縮AVI」です。
確かに言葉足らずですね。
再生が一番軽いのはという意味です。
無圧縮の為、コーデックやその他の
デコード処理に影響されません。
>3秒程度の動画
とあったのでエフェクト系に使う短い動画なら、
無圧縮でも問題ないと思いましたが。。。
#色抜きも面倒だし。
ただ、用途と長さの問題だとは思います。
ゲーム中のストーリームービなどを、
流すのに無圧縮AVIは。。。
まぁ、ありえないでしょうね。。。
>42GBもの
基本的に環境をきちんと考えるなら、
XP以前のOSのFSでは読めないから
2G越えのファイルはNGです。
|
Re: 動画の使い方について2 ( No.7 ) |
- 名前:Dixq 日時:2008/09/03 21:28
>エフェクト系に使う短い動画なら、
なるほど、確かにエフェクトに使用するならよさそうですね。
用途に応じて使い分けようと思います。
>2GB超え
体験版をウェブで公開することも考えるとちょっとこれでも無謀な容量ですね;
なるべく処理も容量も軽くなるように頑張ろうと思います。
|
Re: 動画の使い方について2 ( No.8 ) |
- 名前:管理人 日時:2008/09/07 23:38
> なるほど、関数の仕様を見ると、どうも連続したフレームで順番に描画するのではなく、
> その時間にあった描画すべきデータをとってくるような印象ですね。
折角フレーム単位の制御が出来るようになったので、フレームの進行もプログラム側で
制御できるようにしまてみました。
http://homepage2.nifty.com/natupaji/DxLib/DxLibVCTest.exe //VC用
http://homepage2.nifty.com/natupaji/DxLib/DxLibBCCTest.exe //BCC用
(中身を既存のライブラリのファイルに上書きして、BCCをお使いの
場合は『再構築』、VCをお使いの場合は『リビルド』をして下さい)
以下の関数を追加しました。
// ムービーのフレームを進める、戻すことは出来ない( ムービーが停止状態で、且つ Ogg Theora のみ有効 )
int AddMovieFrameToGraph( int GraphHandle, unsigned int FrameNum ) ;
// ムービーの総フレーム数を得る( Ogg Theora でのみ有効 )
int GetMovieTotalFrameToGraph( int GraphHandle ) ;
注釈の通り Ogg Theora 限定の機能ですが・・・
AddMovieToFrameToGraph でフレームの進行をプログラム側で制御することが出来ます。
ただそうなると音との同期は難しくなるので、停止状態でのみ有効です。
(なので描画目的の無音ムービーで使う感じです)
因みにファイル末端までカレントフレームが移動しているときに AddMovieFrameToGraph で
フレームを進めると0フレーム目に戻ります。
|
Re: 動画の使い方について2 ( No.9 ) |
- 名前:Dixq 日時:2008/09/18 07:08
おぉ、ありがとうございます。
これでますます動画を扱うことの出来る幅が広がりました。
色々と試してみようと思います。
ありがとうございます。
|