Hi,
I am wondering what would be the best way to handle programs which rely on the Video Mixing Renderer 7 (quartz.dll) as it's supposed to be available on XP and later, but Wine contains only an implementation of version 9.
The program I am speaking of is Silverlight which uses the VMR 7 Interface to create a filter graph and then queries for the IAMCertifiedOutputProtection interface. I am currently using a hack fix to get around this by returning a VMR9 instance when a VMR7 is requested and implementing the missing subinterfaces (which are only part of VMR7). This solution is clearly not perfect and I am searching for a better way to get around this issue.
The most similar way to Windows would be to completely rewrite the current implementation of the VMR9 as VMR7 using DirectDraw, which would take a lot of time and most probably end up in having a lot of duplicate code. I am wondering whether using d3d9 for VMR7 would also be an acceptable solution. We could move all the d3d9 related stuff to a separate file so that VMR7.c and VMR9.c only offer the version specific interfaces and use the same code internally. This shouldn't be a big problem since the differences between the VMR7 and VMR9 interfaces are often only very small. Though it would not completely fit the behavior of windows.
I am open for other ideas on how to solve the problem, but as Silverlight does not even use the VMR7 object for playing the video but only to check for the graphic driver certificate I don't think it would justify to rewrite everything using Direct Draw if there are no other programs needing this interface.
Best Regards, Michael Müller
On 15 October 2013 21:52, Michael Müller michael@fds-team.de wrote:
The most similar way to Windows would be to completely rewrite the current implementation of the VMR9 as VMR7 using DirectDraw, which would take a lot of time and most probably end up in having a lot of duplicate code. I am wondering whether using d3d9 for VMR7 would also be an acceptable solution. We could move all the d3d9 related stuff to a separate file so that VMR7.c and VMR9.c only offer the version specific interfaces and use the same code internally. This shouldn't be a big problem since the differences between the VMR7 and VMR9 interfaces are often only very small. Though it would not completely fit the behavior of windows.
I'm not very familiar with quartz / VMR, but I guess the main question would be how applications can tell the difference between a d3d9 and a ddraw implementation. On the other hand, the amount of d3d9 specific code in vmr9.c looks pretty manageable at first sight.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2013-10-15 22:12, schrieb Henri Verbeet:
I'm not very familiar with quartz / VMR, but I guess the main question would be how applications can tell the difference between a d3d9 and a ddraw implementation.
It looks like there are some ways an application can create its own DirectDraw object and pass it to VMR-7: http://msdn.microsoft.com/en-us/library/windows/desktop/dd375451(v=vs.85).as... . But that's just my conclusion from reading MSDN for 5 minutes, so I might be wrong.
Other things to look for is API methods that accept or return an IDirectDraw* object, or COM aggregation tricks which would allow applications to QueryInterface DirectDraw objects from VMR-7 objects.
I could also imagine that VMR-7 supports additional pixel formats like YV12. D3d9 usually supports only YUY2 and UYVY surfaces. In ddraw, support for YV12 overlays is fairly widespread, and some drivers offer additional overlay formats.
Hello,
On 10/15/2013 09:52 PM, Michael Müller wrote:
I am wondering what would be the best way to handle programs which rely on the Video Mixing Renderer 7 (quartz.dll) as it's supposed to be available on XP and later, but Wine contains only an implementation of version 9.
The program I am speaking of is Silverlight which uses the VMR 7 Interface to create a filter graph and then queries for the IAMCertifiedOutputProtection interface. I am currently using a hack fix to get around this by returning a VMR9 instance when a VMR7 is requested and implementing the missing subinterfaces (which are only part of VMR7). This solution is clearly not perfect and I am searching for a better way to get around this issue.
The most similar way to Windows would be to completely rewrite the current implementation of the VMR9 as VMR7 using DirectDraw, which would take a lot of time and most probably end up in having a lot of duplicate code. I am wondering whether using d3d9 for VMR7 would also be an acceptable solution. We could move all the d3d9 related stuff to a separate file so that VMR7.c and VMR9.c only offer the version specific interfaces and use the same code internally. This shouldn't be a big problem since the differences between the VMR7 and VMR9 interfaces are often only very small. Though it would not completely fit the behavior of windows.
if the differences are small then there are different options to reuse the common parts: - Use the same object (struct) for both VMR7 and 9. Just set the correct vtbl pointers during object creation.
- Use a separate struct for the common parts and include it in both objects. Kind off like it is done at the moment with the BaseRenderer and the other Base* stuff.
- If it is feasible to have VMR7 implemented in d3d9 you could even make VMR7 a small wrapper around VMR9. Aka COM aggregate the VMR9 object and just implement the parts you can't forward.
I am open for other ideas on how to solve the problem, but as Silverlight does not even use the VMR7 object for playing the video but only to check for the graphic driver certificate I don't think it would justify to rewrite everything using Direct Draw if there are no other programs needing this interface.
I have an old kids education game that uses both ddraw and quartz that doesn't works. I'll check if it uses VMR7. If yes it is worthwhile to do it right as it is a whole class of such multimedia apps from the early days.
bye michael
Hi,
On 10/16/13 3:22 AM, Michael Stefaniuc wrote:
Hello,
On 10/15/2013 09:52 PM, Michael Müller wrote:
I am wondering what would be the best way to handle programs which rely on the Video Mixing Renderer 7 (quartz.dll) as it's supposed to be available on XP and later, but Wine contains only an implementation of version 9.
Being one of the guy who did the work on vmr9 and generally had a pretty good working knowledge of quartz I am willing to bet that the actual work to be done is fairly small. But there will be a lot of COM wrapping to be written. Not to hard but busy work. Looking briefly at the vmr7 interfaces, they seems basically the same as the vmr9 ones, but with different parameters.
I bet you could even get away with renaming vmr9.c to vmr.c and implementing 7/9 both in the file pretty easily.
-aric
-
Aric Stewart -
Henri Verbeet -
Michael Müller -
Michael Stefaniuc -
Stefan Dösinger