VideoMixingRendererでまたやってしまった

すでに鬼門となりつつあるVideoMixingRendererです。透過率サポートの動画フォーマットを作成したのはよかったものの、

DirectShowを経由した時に透過率の部分が消えてしまうようになっていたのでその部分を修正するために処理を改良していた時の出来事です。

結局VideoMixingRendererはあまりうまく使えないらしい、という結論に行き着いてしまいましたが・・・

VideoMixingRendererにRGB形式で出力するフィルタとYUV形式で出力するフィルタでは動作が違うらしい

ちなみに、MPEGは後者(YV12)です。MPEGでテストしていたのでそれで再生できるようにVMRの処理を組んでいたのですが・・・

独自フィルタの方は自前でYUV=>RGB変換をやっているため、VMRにはRGB形式(RGB32またはARGB32)で出力されます。

すると、今まで組んでいた処理でVMRがレンダリングを行わなくなってしまったのでした・・・。何故に・・・？

ちょっと気持ち悪い点としては、CBaseVideoRendererを使ってMPEGを再生しようとすると負荷率が画面に直接出力するタイプのVideoRendererを使う時に比べて８割増し位になることがあります。

条件としては

ビデオレンダラで受け付けることができるフォーマットがRGB形式のみ

自前(ソフトウェア実装)でYUV=>RGB変換を行うことを前提でYUVフォーマットを受け付ける

といったものがあります。通常のビデオレンダラではグラフィックカード上で行われているYUV=>RGB変換がソフトウェア上で行う(前者の条件の時はColorSpaceConverter行う)ため、

その分の負荷がCPU側に移動してそれが現れるからなんですが・・・。

加工の自由度では圧倒的にCBaseVideoRendererを使う方が上です。この場合はサンプルを画素の状態で取得できることが大きいです。描画の同期には気をつけて。

そもそもRenderlessの場合、一時的にDirect3D9の処理を乗っ取ってデコードを行うので、その部分の対応コードと同期処理にかなり手間が必要になります。

それ用の対応コードを作ったつもりが、まさかYUVの出力でないとうまく動作しないものだった、ということに気がついてしまってどうしようかと思います。

さらには、デコード用のテクスチャ作成の時にテクスチャに透過率がいるかどうかの情報をどこから取得するのかの説明が曖昧になっているのも厳しい点だと思いました。

Windowedの場合は普通のVideoRendererと同じように扱えばいいだけですし・・・。

メモリの受け渡しのせいで1回分のメモリコピー処理が無駄になるのが弱点ですが、それでもデコードされた各フレームの処理の容易さ(描画エフェクトなど)を考えれば

ゲームでのビデオデコードにはこの方法が有利であることが最終的な結論となりました。

この処理を実装したことでADVシステムでは安定して透過率付き動画処理を扱えるようになりました。

一応自分でタイミング処理を作っては見たのですが、再生の同期が外れた時の処理があまりよくないようなのでDirectShow経由での再生を使用することにします。