WPF MediaKit: Now with 100% more EVR

Skip to first unread message

Jeremiah Morrill

Mar 6, 2009, 1:39:41 AM3/6/09
to wpf-di...@googlegroups.com
Sorry for the long winded email.  I'd usually make use my blog, but I think I've got a bigger audience here lol. 

I've just added support for the EVR renderer in the WPF MediaKit.  The EVR is the new(ish) video renderer that is used by the MediaElement.  The EVR has a lot of benefits/features, but mainly very precise sample presentation, *much* more tolerant against dropping of frames and most importantly, you need it for decent integration into MediaFoundation, DirectShow's successor.  MediaFoundation, thus far in Vista, has been gimped...not really meant for mass consumption or general use.  But with Windows 7, it's supposed to be the sh!t with the whiz bang hardware accelerated en/decoding.  I didn't want to miss that boat and leave WPF out in the DirectShow dark ages...

To support the EVR, you gotta write something called a "Presenter", which is a plugin that you write for the EVR.  I'm sure you can guess what the presenter does...I tried to write it in C# at first because I thought it would make me cool.  But it didn't make me cool, it just made me angry.  A lot of the MediaFoundation COM objects don't QueryInterface correctly so the CLR was having a fit.  I started to eff with with vtables, which worked well, but I threw in the towel as the code became quite disgusting and near impossible to manage.

Microsoft has a great C++ EVR presenter sample in the Windows SDK, which is for a Win32 app, but it has all the boiler plate (so big props to them).  After a few days of massaging that, I got it transformed into something consumable for WPF MediaKit.  It wasn't too difficult, but the way the EVR wants to render queued samples and the way WPF wants to hold reference to the D3D surface do not work together.  So I ended up copying the surface being presented to a single d3d surface that is used to render to the WPF D3DImage.  I also added automatic support for 32bit and 64bit, so the CLR will pick the right dll (Presenter32.dll or Presenter64.dll)  Not sure if it will work on XP, but I did add support for D3D9 (not just D3D9Ex).

I will say that the EVR seems to eat up a little more CPU than the VMR9, but the more fluid video on 1080p is well worth it IMO.  I was able to actually play some 1080p content smoothly that even WMP couldn't do! (Alexander from the WM HD showcase)  Right now I only added support for my MediaUriElement (MediaElement clone).  To enable the EVR its like this:

            <MediaKit:MediaUriElement x:Name="mediaPlayer"
                                   Stretch="Uniform" VideoRenderer="EnhancedVideoRenderer" />

I'm still working out some bugs, but I'm real excited about this!


Peter O'Hanlon

Mar 6, 2009, 4:44:15 AM3/6/09
to wpf-di...@googlegroups.com
Wow. Fantastic stuff - I can't wait to play around with it. Very nice indeed; a big thumbs up from me.
Peter O'Hanlon

Jeremiah Morrill

Mar 6, 2009, 7:48:26 PM3/6/09
to wpf-di...@googlegroups.com
Thanks Peter.  I don't know if many will find it a major utility right away, unless they are a really big videophile or making some sort of WPF Media Center type app or noticed issues with the VMR9.  I'll try to get a pure MediaFoundation player up in there asap..

BTW sorta OT, are there any other parts of WPF with more memory leaks and instabilities than the MediaElement?  A company informed me they just found a memory leak in MediaElement that occurs only on multi monitor systems..the leak causes 100% CPU usage with a freeze and a crash if you are lucky after only 5 minutes.  If you disable all monitors but one, the problem goes away.  Microsoft has allegedly confirmed this leak and will be fixed at a time I am not sure I can disclose, but it definitely will not happen this week or next. ;)  Where's the MediaElement love MS?

Reply all
Reply to author
0 new messages