Restored the d3d surface rendering option for mft_h264_decoder. To do this, we need...
commit845e795cff3c6fdc2202f559ee3f1e899f4d101c
authorimcheng@chromium.org <imcheng@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
Tue, 14 Sep 2010 00:16:47 +0000 (14 00:16 +0000)
committerimcheng@chromium.org <imcheng@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
Tue, 14 Sep 2010 00:16:47 +0000 (14 00:16 +0000)
treedb7dc6b0932037ab2c5d0c4e2754f61d45b60972
parentc11fd96976bb5f32bebe14a146b00f16a5928b19
Restored the d3d surface rendering option for mft_h264_decoder. To do this, we need to pass in the window to be drawn to when we create the device. Thus the decoder's constructor now takes an extra argument HWND.

Things to do in upcoming patches:
- move files to media/video and change name to XXXdecode_engine
- refactor, add helper methods in the unittest
- handle the "device lost" case during rendering (this can happen if screen resolution changed after creation of device, for example)
- implement the context interface and have the decoder output d3dtextures
BUG=none
TEST=compile, decoder's unittest still passes

Review URL: http://codereview.chromium.org/3331026

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@59309 0039d316-1c4b-4281-b951-d872f2087c98
media/mf/mft_h264_decoder.cc
media/mf/mft_h264_decoder.h
media/mf/mft_h264_decoder_example.cc
media/mf/test/mft_h264_decoder_unittest.cc