Custom AP of vmr9

I want to play a movie in a 3D scenario or use the movie as a texture.
There are two ways: Write a video render to take over the final output of the filter graph and copy the video data to our private texture, use it as appropriate (mainly in the main loop related to d3d ).
The other is to use vmr9. Vmr9 allows us to provide Allocator-presenter ourselves to fulfill some special needs. We provide our own A/P. vmr9 will call the AP's presentimage function for actual rendering. We can bypass the video data to the private texture here.
The first method is troublesome, because the video decoding formats are various and you have to handle them yourself. For example, YUV, rgb565, rgb32, and yuy2 are messy. When I play a movie with the output of yuy2, The activemovie window pops up because my video render only receives the RGB format.
In the latter way, all the above vmr9 has been done for you. All you need is a stretchrect call!
The SDK contains an example of multivmr9 (samples/CPP/DirectShow/vmr9/multivmr9/multiplayer) and gameplayer (samples/CPP/DirectShow/vmr9/multivmr9/multiplayer, another example is vmr9allocator (samples/C ++/DirectShow/vmr9/vmr9allocator. Gameplayer constructs a movie Wall. The effect is cool.
In these examples, d3d is a subsidiary of the video playback process. We now want to reverse the problem: d3d is the main one, and video playback is the secondary feature, usually 3D rendering. Video Playback can play independently and copy the decoded video to a texture, when 3D scenes think of it, they can be used directly.
OK. Let's take a look at vmr9allocator. It seems that the following points can be modified.
1. Pass d3d and d3ddevice to callocator when constructing
2. In the initializedevice function, call allocatesurfacehelper to create a private texture.
3. Copy the video to private arts and sciences in presentimage
4. Improve the getvideotexture interface and allow the d3d part to obtain the Video Texture for rendering.

This is indeed the case, but I encountered some problems during actual operations. It took me two days to solve them!
1. allocatesurfacehelper always fails
2. the bypass video is intermittent.

First, I don't need to allocate a texture surface marked with vmr9allocflag_texturesurface. I just need to allocate offscreen surfaces. So I did this: lpallocinfo-> dwflags = vmr9allocflag_offscreensurface; (this is also done in gameplayer, and there is no problem), and then call allocatesurfacehelper, the result will always fail!
The second problem is more serious. I can only get a limited number of images.

Later on the Internet (http://www.gamedev.net/community/forums/topic.asp? Topic_id = 380264, http://www.gamedev.net/community/forums/topic.asp? Topic_id = 455515) You need to use the setmixingprefs method of the ivmrmixercontrol9 interface to set the mixerpref9_rendertargetyuv flag. In this way, vmr9 no longer needs the texture surface, but only needs to leave the texture surface, and does not switch the render target. So we can get a complete and continuous video. However, it must be a Windows XP SP2 or later System (http://msdn.microsoft.com/en-us/library/ms788177.aspx ).
After my experiment, there was no result. Later I found that the call sequence of setmixingprefs was very critical! Once you put the wrong position, not only can not achieve the effect you want, It may be worse. I encountered the following problems:
1. If no interface is found, e_notimpl is returned.
2. Get the interface and set mixerpref9_rendertargetyuv, which has no effect.
3. Set mixerpref9_rendertargetyuv and call allocatesurfacehelper with vmr9allocflag_texturesurface as a flag will fail.

The call was finally put before the renderfile. After advisesurfaceallocator and advisenoworkflow were called, this was done. However, an inexplicable error occurred while playing the rmvb file (to be checked ). I am worried that, after doing so, there will be some encoding format problems during playback (if its decoding filter only outputs the RGB format ?), Here we illustrate some of its limitations: http://msdn.microsoft.com/en-us/library/ms788177.aspx.
When I checked the source code of gameplayer and multvmr9 DLL, I found that it is not as well as above, but it can still be used normally. It is obvious that some of my usage is incorrect.

Here we will refer to the step for customizing a/P using vmr9. Because vmr7 is used by default in Windows XP, we need to add vmr9 to the filter graph. You can refer to the related documentation in the SDK. That method is acceptable, but it is troublesome. The preceding examples are as follows:
1. Create a filter graph
2. Create a vmr9 instance and add it to graph.
3. Set vmr9 to renderless Mode
4. query the ivmrsurfaceallocatorpolicy9 Interface
5. create custom A/P
6. We recommend vmr9 use your A/P (call ivmrsurfaceallocatorpolicy9: advisesurfaceallocator)
7. Provide Allocator notifier to your A/P (advisenoworkflow)
8. Call renderfile or other methods to intelligently create the remaining Graph
9. query imediacontrol, imediaevent, and other interfaces for future use.
10. When you delete the filter graph, stop the graph, disconnect all the pins of vmr9, and set its A/P to null.

The document is in the vmr9multi_help.htm under samples/C ++/DirectShow/vmr9/multivmr9. I think this document is clearer than the DirectShow SDK.