I'm probably late since your last post about VMR9 is two weeks old.

Sorry if I'm replying to the newer post, I hope it's ok for you.

Quote:
I've decided to ditch VMR-9 for a few reasons:
1. It's horribly implemented. You can't use the debug runtimes with it (The debug device doesn't expose the IDirect3DVideoDevice9 interface which VMR-9 needs for rendering). I've also read all sorts of horror stories on the Internet about it leaving resources and being difficult to reset the device.

I don't remember experiencing any issue with the debug runtimes, so I looked for IDirect3DVideoDevice9 via MSVC. Well... there's no match in my entire solution!!! I don't know what the graph builder does internally, but in my code I don't even touch that interface.

I'm starting wondering if we are playing in the same ballpark. Just to be sure, how did you get the DirectShow headers+lib? I'm using Windows SDK Feb 2007 and I've been forced to modify the SDK headers in order to compile my project.

AFAIK this is a known issue, related to the process of moving DirectShow from the DirectX SDK to the Platfom SDK, without removing a dependency of a file which no longer exists (dxtrans.h). Since usually we should not edit the SDK headers, I suppose if you had changed them, you would remember that!

Can I assume we are compiling against the same DirectShow? I'm not 100% sure but if I downloaded an entire Platform SDK just for DirectShow, then I probably experienced some problems compiling against my old DX8 SDK folder.

If we aren't compiling against the same version, give a try to the Platform SDK, then open qedit.h and comment any reference to dxtrans.h. Then every time you include qedit.h, add the following defines:

#define __IDxtCompositor_INTERFACE_DEFINED__
#define __IDxtAlphaSetter_INTERFACE_DEFINED__
#define __IDxtJpeg_INTERFACE_DEFINED__
#define __IDxtKey_INTERFACE_DEFINED__
#include "qedit.h"

This trick seems to work.

Quote:
2. It requires a D3D device to use and requires the device to be multithreaded. I really don't like the idea of that, multithreaded devices in D3D9 are A Bad Thing, and multiple devices is a very bad idea. There's no way (that I can see) to tell VMR-9 to not use a D3D device and to render into a memory buffer like plain DirectShow.

You're right, but I suppose it would be weird if VMR9 allowed to render into a memory buffer, as VMR9 should be about the GPU performing as much operations as possible.

I wonder if in multicore days it's better to pay the price of a multithreaded device or let the cpu decode video and manually update data to a surface. The problem I see is some video formats output planar YUV data. I don't know if plain DirectShow will return an interleaved RGB buffer, but such a conversion is definitely going to have an impact on performance.

Quote:
3. It's taken me 3 days to get something nearly working.
4. I don't see what benefits it gives me.

As for point number 3, while I was writing my VMR9-based code I started thinking I was living in dumbville. It took some time to get that thing working. Maybe the problem is not my dumbness, but VMR9 itself.

The benefit should be faster decoding and simpler code (!!!!). Actually if the scene does not consume much GPU time, VMR9 does its job flawlessly.

Quote: Original post by undead
I'm probably late since your last post about VMR9 is two weeks old.

Sorry if I'm replying to the newer post, I hope it's ok for you.

That's fine, I don't really check my older entries [smile]

Quote: Original post by undead
I don't remember experiencing any issue with the debug runtimes, so I looked for IDirect3DVideoDevice9 via MSVC. Well... there's no match in my entire solution!!! I don't know what the graph builder does internally, but in my code I don't even touch that interface.

It's not used by my code directly; DirectShow fails in the SetD3DDevice() call with E_NOINTERFACE, and from googling that's because the debug runtime's IDirect3DDevice9 doesn't expose the IDirect3DVideoDevice9 interface, which SetD3DDevice() must query for internally.

Quote: Original post by undead
I'm starting wondering if we are playing in the same ballpark. Just to be sure, how did you get the DirectShow headers+lib? I'm using Windows SDK Feb 2007 and I've been forced to modify the SDK headers in order to compile my project.

AFAIK this is a known issue, related to the process of moving DirectShow from the DirectX SDK to the Platfom SDK, without removing a dependency of a file which no longer exists (dxtrans.h). Since usually we should not edit the SDK headers, I suppose if you had changed them, you would remember that!

Can I assume we are compiling against the same DirectShow? I'm not 100% sure but if I downloaded an entire Platform SDK just for DirectShow, then I probably experienced some problems compiling against my old DX8 SDK folder.

If we aren't compiling against the same version, give a try to the Platform SDK, then open qedit.h and comment any reference to dxtrans.h. Then every time you include qedit.h, add the following defines:

#define __IDxtCompositor_INTERFACE_DEFINED__
#define __IDxtAlphaSetter_INTERFACE_DEFINED__
#define __IDxtJpeg_INTERFACE_DEFINED__
#define __IDxtKey_INTERFACE_DEFINED__
#include "qedit.h"

This trick seems to work.

I've got the Windows Server 2003 Platform SDK (Which was the one to download with VC2005 Express at the time), and the March 2008 DirectX SDK. I've not needed to modify any SDK headers, everything seems to have worked so far.

Quote: Original post by undead

Quote:
2. It requires a D3D device to use and requires the device to be multithreaded. I really don't like the idea of that, multithreaded devices in D3D9 are A Bad Thing, and multiple devices is a very bad idea. There's no way (that I can see) to tell VMR-9 to not use a D3D device and to render into a memory buffer like plain DirectShow.

You're right, but I suppose it would be weird if VMR9 allowed to render into a memory buffer, as VMR9 should be about the GPU performing as much operations as possible.

I wonder if in multicore days it's better to pay the price of a multithreaded device or let the cpu decode video and manually update data to a surface. The problem I see is some video formats output planar YUV data. I don't know if plain DirectShow will return an interleaved RGB buffer, but such a conversion is definitely going to have an impact on performance.

To be honest, I haven't bothered profiling this. But there's definitely a performance impact, D3D is single-threaded by design (All calls need to go through one point to get to the card), so using multi-threading just causes synchronisation stalls.

Quote: Original post by undead

Quote:
3. It's taken me 3 days to get something nearly working.
4. I don't see what benefits it gives me.

As for point number 3, while I was writing my VMR9-based code I started thinking I was living in dumbville. It took some time to get that thing working. Maybe the problem is not my dumbness, but VMR9 itself.

The benefit should be faster decoding and simpler code (!!!!). Actually if the scene does not consume much GPU time, VMR9 does its job flawlessly.

Point 3 is a bit moot really; It's pretty much working now, so I can't argue that it'll take time to finish when it's already mostly there.

As for point 4; the code is simpler - but the DirectShow base classes abstract away a lot of the horrible stuff already, and I'm not entirely convinced that it'll be faster. If you're using VMR-9 to to render to a texture, then the GPU is already going to be busy. Trying to muli-thread a GPU sounds like a bad idea to me - it's not designed to be multi-threaded. CPUs on the other hand work well with multi-threading, and there's more of them (Usually dual-core) thus it makes more sense to me to do video decoding entirely on the CPU.

Quote: Original post by Evil Steve
It's not used by my code directly; DirectShow fails in the SetD3DDevice() call with E_NOINTERFACE, and from googling that's because the debug runtime's IDirect3DDevice9 doesn't expose the IDirect3DVideoDevice9 interface, which SetD3DDevice() must query for internally.

That's weird! My only call to SetD3DDevice is inside the allocator/presenter class. I tried 5 minutes ago with d3d9 set to debug runtimes via DirectX control panel and compiling my project in debug. I can step through my code, I get S_OK as the return value and the final rendering is just fine.

Quote: I've got the Windows Server 2003 Platform SDK (Which was the one to download with VC2005 Express at the time), and the March 2008 DirectX SDK. I've not needed to modify any SDK headers, everything seems to have worked so far.

The problem lies in qedit.h, which refers to dxtrans.h.
You probably don't include qedit.h, so you don't need that trick to fix compilation issues.

I need qedit.h because of IMediaDet, which can be used to determine the number of streams and their type.

Quote: As for point 4; the code is simpler - but the DirectShow base classes abstract away a lot of the horrible stuff already, and I'm not entirely convinced that it'll be faster. If you're using VMR-9 to to render to a texture, then the GPU is already going to be busy. Trying to muli-thread a GPU sounds like a bad idea to me - it's not designed to be multi-threaded. CPUs on the other hand work well with multi-threading, and there's more of them (Usually dual-core) thus it makes more sense to me to do video decoding entirely on the CPU.

I'm not a DirectShow expert but if a video renderer is the default on a specific platform (i.e. EVR on Vista) doesn't that mean another device is automatically created?