January 13, 2004
VideoForWindowsは遅いということが判明
卒研ネタ。
AVIからフレーム（=DIB)を抜き出す処理を、いままではVideoForWindowsというレガシーなライブラリを使って書いていた。つい先日、先輩氏から同じ処理をDirectShowで書いたコードを頂戴したので、さっそく今までのVideoForWindowsなコードに置き換えた。そして、興味本位で双方の処理速度を計測してみた。
下に示すのは、VideoForWindowsなコードと、DirectShowなコードの双方に、同じAVIから1000枚のフレームを抜き出す処理をさせた結果。1フレーム目から1000フレーム目までを順番に抜き出していくシーケンシャルなアクセスと、乱数で生成した番号のフレームを抜き出すランダムなアクセスとを試した。
リソースとして使ったAVIはこのようなもの。
CODEC : Indeo5
-quality : 85
-keyframe : 15フレームごと
-その他、scalability, transparency等のオプションは使わず
Size : 640*480
内容 : サッカーの試合
| VideoForWindows | DirectShow | |
| シーケンシャル | 54953(ms) | 34734 |
| ランダム | 53390 | 37812 |
双方の間にはおよそ1.5倍もの差が生じている。これだけの差が付くというのは意外だった。DirectShowのほうが遅く作られたライブラリであることから、より洗練された実装がされているということは分かる。だが、もっともCPU時間を喰うであろう、AVIのバイナリをデコードしてDIBを作る部分の処理はIndeo5のCODECがやっているはずで、双方とも同じものを使っているとおもわれる。処理全体としてこれだけの違いが出るのはどうしてだろう。暇なときに調べてみようとおもう。
卒研で実装中のシステムは、VideoForWindowsなコードは捨てて、DirectShowオンリーで行くことを決定しました。
Trackback
You can ping this entry by using http://windy.ac/MT/mt-tb.cgi/309 .
Comments
まあ、あれですね、あんまり正確な記憶じゃないんですが、VFWは16ビットコードが紛れ込んでたりするのでそのせいじゃないでしょうか。最近のCPUとOSは16ビットコード区間に出入りするときにえらい時間くいますので。
鋭い御指摘。
調べてみると、VideoForWindowsはWindows3.1の時代からあるライブラリのようで、
http://www.nifty.com/webapp/digitalword/word/017/01724.htm
レガシーな１６ビットコードが足を引っ張っている可能性は大だと思います。
RSS Feed