Video Mixing Renderer 7
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(a)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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSXcdLAAoJEN0/YqbEcdMwOoIP/24iI2LCQrTfbKQbd4Qew4ea HNVTvBLrh1OT7QHVK7dVXbvfbh6PjMJDuHdGv0Pkoex7R3vr+YRYkZJPPZTonNfo l2eQlcCjbSwBxl6Y8SD/CulrEJiL10N1s2Bs9AlNXq0TtM7dbDelyAY6nBWQkZSj oGPpkYfLE20yJQhH+dMlHvD56YICwDO+vGWqV6BDe/93xWBAFUQP8Xyjx1D2QjQO Hfke4Oi9B9Ge8AWg0J7pLp+Z1RfTlbH/akJ8KR/bJQ6LKeCfjkm9Y5Wl8A1U9jVP fJcXP9L44c8MJOyh062yPFrWJlJzev0usDorgxVZATiIsO2M8GgCyTpZBa77fIth TAwHbWKi/0AhV1AWU+Qq4Zi/9A6xfd2jFMVWOJsvviloYwCyOe6pnwAr+tnhewq8 R6dPBP5bDcv4U35sP0+d06rjt8QH7wA0190K9Rc5UusdUAeam7uFe2TB2DyD0Ncl N/vFrBGnN/3HiQl6GxsDvHvyBu87xa8lZJ3GfUHqm7sENRfk312ypurYFtAhi4qN 8d0KjnKRY2wnt1EclL1ZD3qVpfpuFbJTgLi7NfBIE8rrTfbMSDaIJ3d1zwpUn7ms qAgT5jCDanJYsdJZoykPfd/93rOnFzL6IEYMk6Bbjrggv6jlsZCFs6UCXdsHDGvK oz6sXgH4B6xFVXOmDTb/ =e4lK -----END PGP SIGNATURE-----
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
participants (5)
-
Aric Stewart -
Henri Verbeet -
Michael Müller -
Michael Stefaniuc -
Stefan Dösinger