views:

342

answers:

5

It's hard to put this into the title, so let me explain.

I have an application that uses Direct3D to display some mesh and directshow(vmr9 + allocator) to play some video, and then send the video frame as texture to the Direct3D portion to be applied onto the mesh. The application needs to run 24/7. At least it's allowed to be restarted every 24hours but not more frequent than that.

Now the problem is that directshow seems to be giving problem after a few hours of playback, either due to the codec, video driver or video file itself. At which point the application simply refuse playing anymore video. But the Direct3D portion is still running fine, mesh still displayed. Once the application is restarted, everything back to normal.

So, I'm thinking of splitting the 2 parts into 2 different process. So that when ever the video process failed to play video, at least I could restart it immediately, without loosing the Direct3D portion.

So here comes the actual question, whether it's possible to pass the texture from the video player to the direct3d process by passing the pointer, aka retrieve the texture of another process from pointer? My initial guess is not possible due to protected memory addressing.

I have TCP communication setup on both process, and let's not worry about communicating the pointer at this point.

This might be a crazy idea, but it will work wonder of it's ever possible

A: 

If you separate it out as a separate process then I suspect this would not be possible, but if it were a child thread then they would have shared memory addressing I believe.

EBGreen
That's the purpose of separating them. Currently the player is running on a separate thread from the direct3d. How about if the texture is stored on the video memory?
faulty
Not sure how the video memory is mapped with respect to the process/thread memory space. Just isn't something I've ever had to deal with.
EBGreen
A: 

Now the problem is that directshow seems to be giving problem after a few hours of playback, either due to the codec, video driver or video file itself. At which point the application simply refuse playing anymore video.

Why not just fix this bug instead?

Paul Betts
Not possible, video driver and video codec are not within our control. The problem is random too. Very hard to narrow down. We did try to figure out the most stable driver version and codec through trial and error, but it still perform differently from pc to pc even with the same hardware. :(
faulty
A: 

Passing textures doesn't work.

I'd do it using the following methods:

  • Replace the VMR with a custom renderer+allocator that places the picture into memory
  • You allocate memory for pictures from a shared memory pool
  • Once you receive another picture you signal an event
  • The Direct3D process waits for this event and updates the mesh with the new texture

Note you'll need to transfer the picture data to the graphics card. The big difference is that this transfer now happens in the Direct3D app and not in the DirectShow app.

You could also try to use the VMR for this. I'm not sure if the custom allocator/renderer parts will allow you to render into shared memory.

This is exactly what I did, and have been doing all these while(vmr9 + allocator). It doesn't split the DirectShow from Direct3D into 2 processes. Whenever DirectShow failed, I still need to restart the whole app
faulty
A: 

Maybe you could use the Sample Grabber in your DirectShow host process to get the image as a system memory buffer. Then you could use WriteProcessMemory to write the data into a pre-agreed address (which you setup over TCP or something) in your Direct3D app.

Lucas
+1  A: 

Yes you can do this with Direct3D 9Ex. This only works with Vista and you must use a Direct3DDevice9Ex. You can read about sharing resources here.

Jeremiah Morrill
Our earlier requirement was to be backward compatible with XP, which wasn't possible. Now since Win7 has popularize, redesigning the software to run on DirectX10 will allow resource sharing, which solve my problem. Thanks for your input too.
faulty