Login
 
Archive
Links
Search
Blog List
There are no categories in this blog.
 
Mar 25

Written by: Jeremiah Morrill
3/25/2008 4:24 PM

When I first started using WPF, the first thing I messed with was the MediaElement, after all, I am a nut for video.  I found the MediaElement only allowed you to supply a source Uri to your media.  It sadly did not allow any API access to write your own custom video.  WriteableBitmap was more of a convenience API and marked certain death for any high-performance application.  What if somebody wished to add a web camera to their application, in which they wished to encode and display the video at the same time (ie video conferencing)?  What a developer wished to add custom effects to the video before its rendered?  What if the developer had their own, non-DirectShow library for video.  There was no efficient way to do this in WPF and MediaElement still stands as king of rapid raster updates.

I started this blog off with a proof-of-concept that allowed people to inject their own DirectShow filters and submitted it for the community's approval.  Since then, I have had a swarm of emails of people telling me:  1.) It's great.  2.) It's hard to use 3.) I can't get it to work 4.) I don't know a damn thing about DirectShow.

Besides that, it has had a fairly high number of views on the WPF forums and it still is the most popular page on my blog.  I believe I even saw a company using it in their software at Mix08.  I'm not positive, but when they pulled up explorer, I saw filenames that looked very similar and their app did have custom video in it.  It gets me excited to think that people use this stuff!

I mentioned in a earlier post that I was planning on a new version of the MediaBridge.  I finally started work on it and it is coming along nicely.

Here are a list of "features" the VideoRendererElement will have.

1.) Single componentized WPF element

2.) Simple API.  You do not need to know DirectShow!  Though you can still use DirectShow if you like, just pass the output of a DirectShow graph (via SampleGrabber if you like) to the VideoRendererElement for output.

3.) You can write uncompressed or compressed samples to the VideoRendererElement.  Because I use DirectShow in the background, I allow a developer to copy not only uncompressed RGB pixels over, but YUV or even MPEG4, JPG, WMV, etc samples to be decompressed.

4.)  This can also be used as a high-performance "WriteableBitmap" if you wish.  Now you can use your old GDI code again.

I plan on giving this a home on codeplex when I feel the code is worthy.  Please feel free to submit any questions/feedback.

-Jer

Tags:

1 comments so far...

Re: VideoRendererElement or WPF MediaBridge v2.0

hi jer,

do you great job here on video in wpf.

I have successfully written an directshow filter which provides data that is rendered in a WPF MediaElement as well as in the Windows Media Player (wmp11). Unfortunately, I registered a significant difference in the performance. The same video stream need much less CPU when it's played on the wmp than in the MediaElement. Consequently, I tried to include the wmp as an ActiveX-Control in my wpf application. That works, but i lose most of the wpf features on this control.

5 streams á 25 fps need about 40% CPU using Windows Media Player.
1 (!) stream á 25 fps need about 64% CPU using WPF's MediaElement.

In both cases I expect the same DirectShow graph, and so no differences in decoding load. Moreover, there are no overlays or reflections used in the wpf application that might have an influence on the CPU load.

I found an article with about the same problem here: http://www.dotnetjunkies.com/WebLog/jritmeijer/archive/category/2799.aspx

Do you have an idea what the reason is for this difference between wmp and MediaElement?

I hope you keep on researching on this topic...
chris

By chris on   4/4/2008 4:09 AM

Your name:
Title:
Comment:
Security Code
Enter the code shown above in the box below
Add Comment    Cancel  
  Minimize
Text/HTML Minimize
Copyright 2007
Downloaded from DNNSkins.com