By Jeremiah Morrill on 12/23/2008 7:43 PM

My buddy, who is learning Silverlight and MVVM, has been using the new Chart controls from the Silverlight Toolkit.  The road block he was having was being able to data bind a collection of collections to a Chart's series.  This was difficult because the Series property of the Chart does not play nice.  So me being such a wonderful friend, I whipped up a quick attached behavior to allow this.

Here is the usage:

 Charting:Chart x:Name="chart"...

Read More »

By Jeremiah Morrill on 12/18/2008 11:04 AM

I have added a DVD player over the weekend that supports interactive menus into the WPF MediaKit.  This is very preliminary, so its not fully featured and surely has some bugs.  One bug that is killing me is the DVD video will appear to be choppy at some points.  I don't think this is a problem with WPF or D3DImage performance.

If you look at the code and say "Wow, you coulda made the DVD graph a lot easier", well you're...

Read More »

By Jeremiah Morrill on 11/16/2008 4:00 PM

I just added the ability to use anything derived from my D3DRenderer class (ie MediaUriElement), to be used as a VisualBrush, on any thread.  If you've ever tried using the VisualBrush on these elements from another thread, you'll find that it does not work.  This fixes that with a method on D3DRenderer called CloneD3DRenderer.  There is also a new DP on the D3DRenderer called IsRenderingEnabled, so if a particular instance of the D3DImage you need to stop rendering to save some processing cycles,...

Read More »

By Jeremiah Morrill on 11/14/2008 9:26 AM

I just committed some bug fixes to CodePlex.  I now support MTA and STA graphs.  Before I only supported MTA because a DirectShow thread that came through the VMR9Allocator (in PresentImage) needed to touch some of the COM objects.  This was overcome by making the VMR9Allocator inherit from the DispatcherObject and any calls that need to touch the COM objects are dispatched.  Hopefully this fixes any RaceOnRCW MDA errors anyone...

Read More »

By Jeremiah Morrill on 11/7/2008 5:15 AM

I don't have a whole lot of time, even for this post.  Been bombarded with work.  I still wanted to share my latest concoction.

Simply put, I am able to grab the Direct3D shared Surface the Vista DWM uses (undocumented API) to paint all Direct3D based windows.  Once I have that, I am able to use it as a "VisualBrush" in WPF or I can copy the Direct3D Surface to system memory for very high frame rate captures.and you can stream it out too.to Silverlight even!  This idea is similar in concept...

Read More »

By Jeremiah Morrill on 11/3/2008 9:04 AM

I've been working a MediaDetector control...

Read More »

By Jeremiah Morrill on 9/21/2008 1:32 AM

I just did a few bug fixes to the source code based on everyone's findings (Thanks!).  So now the Volume should be working right.  I get hWnd messages for graph events now.  The DispatcherTimer is still in there, but only drives the media position right now.  I've also added a WMF SDK C# translation.  This is because I wanted to add to write some WPF controls with streaming capabilities.  Video chat maybe? =P

-Jer

...

Read More »

By Jeremiah Morrill on 9/17/2008 2:33 AM

Finally got everything up on Codeplex.  Been very busy at work, but I'm happy to get this out to you all.  This should support "Any CPU" compilations, so 64bit is supported.  Of course you need 64bit DirectShow filters that any given media needs...So the sample application is set to x86 for now to provide the most compatibility.

Not all of Direct3D has been translated, just the stuff I needed.

http://www.codeplex.com/WPFMediaKit

...

Read More »

By Jeremiah Morrill on 9/15/2008 8:20 AM

So I've decided to drop the SlimDX dependency from the WPF MediaKit.  There's a couple reasons for this.  SlimDX is written in CLI/C++, so it has a hard dependency to 32bit or 64bit code.  This means that you cannot build your application as "ANY CPU" and have the JITter run automatically as 32 or 64bit code.  With SlimDX, you either have to install both 64bit and 32bit assemblies in the GAC, or swap out the 32bit assembly with the 64bit one (or vice-versa).  There's also a issue I was having with...

Read More »

By Jeremiah Morrill on 9/7/2008 2:42 PM

I run Vista x64 on my development computer, so it's pretty easy for me to test compatibility with 32bit and 64bit when I'm coding.  While coding some more on the WPF Media Kit last night, I decided that I wanted the WPF MediaKit to support 64bit too.  This of course is impossible with the MDX libraries.  The MDX libraries are written in .NET 1.1 and compiled for 32bit only.  Weak huh?  So based on a suggestion from one of you guys, I checked out SlimDX, which is a managed wrapper for DirectX.  The...

Read More »

By Jeremiah Morrill on 9/5/2008 3:16 AM

One big bug in the "WPF MediaKit" that I've really been putting off has handling the Direct3D device when it's lost.  Well I think I've got it licked!  See, a standard IDirect3DDevice9 will be lost (meaning you can not use it anymore and all resources in the default pool have to be recreated) in many different scenarios.  For instance if you change your display resolution, or if you switch to another user or even hit ctrl-alt-del.  In Vista, I use the IDirect3DDevice9Ex, which is simply amazing. ...

Read More »

By Jeremiah Morrill on 9/4/2008 6:11 AM

I'm notorious for showing off things before they are done.  So keeping with my notoriety, I have decided to give a sneak preview of the WPF MediaKit.  Keep in mind most things are largely untested.  I don't restore a lost D3D Device just yet and don't expect the sample application to be pretty.  I did spend a lot of time commenting everything, so it shouldn't be too bad to navigate.

Right now I have two "example" controls, the MediaUriElement and the VideoCaptureElement.  I just threw the VideoCaptureElement...

Read More »

By Jeremiah Morrill on 8/30/2008 11:48 AM

In my last post about the WPF MediaKit library, I mentioned a little about the design goals and architecture.  I have two distinct, but complimentary class hierarchies.  The "MediaPlayerBase" class tree wraps DirectShow COM functionality into a DispatcherObject, running in it's own Dispatcher.  The "MediaElementBase" wraps the "MediaPlayerBase" into a nice XAML friendly, data-bindable FrameworkElement.

Today the class inheritance looks like this:

On the DirectShow centric side

DispatcherObject->MediaPlayerBase->MediaSeekingPlayer

...

Read More »

By Jeremiah Morrill on 8/27/2008 2:13 PM

A few of you have emailed, wondering if I'm still alive, or if I'm working more D3DImage video player.  The answer is "YES!".

I have been very busy with work, but I found some time here and there to work on what I am calling (for the lack of a better name), the "WPF Multimedia Library".  Sounds pretty self explanatory, no?  The quick synopsis, it's a lib to quickly and easily create custom video/audio players in WPF.  And hopefully some XAML enabled sound processing controls, though I have to check to see if I can release that part(it may be part of a closed source app).

So, yeah, the multimedia library, I mentioned quick and easy?  I suppose those are both subjective terms, but I have been spending a lot of time refactoring and massaging the architecture to make it as easy as possible.  Let me explain a little of where I'm at.

COM and DispatcherObject sitting in a tree...

The first thing I wanted to tackled was a tidy way of communicating with our DirectShow COM objects.  See, COM is subject to threading apartment rules of Single-Threaded-Apartment or Multi-Threaded-Apartment.  To be said simply an object created in STA can only be accessed via the same thread that created it.  An object created in MTA can be called from any *MTA* thread.  An STA thread can not talk to an MTA object and vise-versa.

So this MTA/STA ish sounds like a problem in WPF because it uses an STA UI thread and you don't want to create the DirectShow COM objects on the UI thread for threat of blocking the UI thread (bad!) when you make blocking calls to the COM objects.  But couldn't we create all the COM objects under an MTA thread?  Yes, but the WPF STA thread won't be able to access them (see previous paragraph).  The problem is solved by sub-classing DispatcherObject and running the Dispatcher on it's own thread.  To access your COM safely, you use the familiar WPF Dispatcher->Invoke/BeginInoke.  So now all COM functionality (DirectShow in this case) is neatly wrapped up in it's own DispatcherObject.  Here is an example factory method:

/// ...

Read More »

By Jeremiah Morrill on 8/17/2008 6:34 AM

I have been toiling more with the XNA libs, trying to get the...

Read More »

By Jeremiah Morrill on 8/12/2008 2:28 AM

The new D3DImage in WPF opens up worlds for WPF.  Direct3D content rendered with WPF...it doesn't...

Read More »

By Jeremiah Morrill on 8/11/2008 11:52 AM

Everyone grab a copy of .NET 3.5 SP1, its RTM.  For this RTM release I have a...

Read More »

By Jeremiah Morrill on 5/21/2008 2:41 PM

I've been playing around with the new WPF 3.5 SP1 beta lately and I wanted to test the performance of the new WriteableBitmap in comparison to the VRE.

The test simply copies the same pixel buffer to the WriteableBitmap or the VRE at a specific interval.  This way we can see the raw CPU it takes to just update pixels.

For this test, I use a 1280x720 (720p) pixel buffer at around 30FPS.  On my quad-core system,...

Read More »

By Jeremiah Morrill on 4/28/2008 8:24 AM

Pavan released his now popular ElementFlow control about a month ago.  Dissecting his code was both a pleasure and very educational (It was written much nicer than my version).  The coolest part was how he sub-classed a Panel and overlayed a Viewport3D on top.  Being a sub-class of Panel, you have all the nice built in WPF functionality that goes along with it, such as using ItemsControl class...

Read More »

By Jeremiah Morrill on 4/19/2008 8:33 AM

I've spent a lot of time tuning up the VRE to be as flexible as possible as to support advanced media scenarios, such as DVDs.  Things are not easy given the nature of DirectShow, WPF and the MediaElement (the 3 essential ingredients of VRE).  For weeks I have been pondering on the new features Microsoft is releasing for WPF, such as the pixel shaders, new WriteableBitmap and the Direct3D interop.

The Direct3D interop...

Read More »

By Jeremiah Morrill on 4/16/2008 6:11 AM

So I have pretty much finished the DirectShow Renderer, which is a glorified SampleGrabber and I started testing the DVDs with it.  For some reason Microsoft's DVD Navigator filter will only play the FBI warning and stop.  I swapped out MS's DVD navigator with CyberLink's and it played fine!  I did some tests with the "Dump" filter from the DirectShow SDK and it only did the FBI warning also.

Could this be some anti-piracy feature of Microsoft's DVD Navigator when the graph has a 3rd party...

Read More »

By Jeremiah Morrill on 4/15/2008 5:00 AM

In my last post I talked a little about how I was modifying the VRE to support it's own DirectShow Renderer.  This is to get around how crappy/inflexible the SampleGrabber really is.  The DirectShow renderer I have made is really just a glorified SampleGrabber which is very simple and probably won't be more than 20 LoC when it is finished.  This should, in theory make the VRE compatible with...

Read More »

By Jeremiah Morrill on 4/13/2008 4:02 AM

If you've been reading this blog this week, you probably noticed am attempting to make a WPF control that allows a developer to play DVDs rendered WPF.  I had some reasonable success, but the project had to be hard-coded way to much.  For instance I required 3rd party DVD filters and two (count them, TWO!) FFDShow filters to even make the DirectShow graph work.  The problem lies in the design of the VideoRendererElement.  I expected to always be able to use the SampleGrabber filter to get samples...

Read More »

By Jeremiah Morrill on 4/10/2008 9:22 AM

Here's the video of Interactive DVD menus working.  I made it out to be hard, but really it was so easy I don't want to say.  Should work fine on 3D too!

BTW, If it looks choppy, that's the encoding.  Local its smooth and I have it down to 5% CPU now :)

 

By Jeremiah Morrill on 4/10/2008 7:09 AM

I was asked by some peeps about how the multi-media pipeline (DirectShow) works and also how it relates to WPF.  I've decided to write a little post to cover all this.  I've tried to keep it as high level has possible.

DirectShow

DirectShow is the multimedia framework in Windows.  Most media players that run on windows use DirectShow, including Windows Media Player.  Ever wonder how you can install a DiVX codec and all of a sudden you can play those (legal I hope) DiVX AVI files?  How...

Read More »

By Jeremiah Morrill on 4/10/2008 3:11 AM

Here is a video of what I was able to do so far with the VideoRendererElement and a DVD.  I'm showing the DVD title screen so you know it truely is the DVD and not some rip.

*UPDATE*  Woo, got it down to 8% CPU usage, but I still have some unnecessary overhead I can get rid of.

 

By Jeremiah Morrill on 4/9/2008 3:53 AM

I've read quite a few posts (and lots of bitching) about how the MediaElement does not support DVD playback.  With the VideoRendererElement, this should be possible...but not without its hurdles.

It seems as the authors of the DVD decoder filters don't like you creating a sample sink (ie SampleGrabber filter), probably for obvious reasons, such as pirating.  I need this sample sink so I can feed the VideoRendererElement some samples to render.

I have come across some commercial DVD filters...

Read More »

By Jeremiah Morrill on 4/5/2008 2:18 AM

I've spent some time this weekend working on the VideoRendererElement, cleaning up the source, commenting, bug fixing, etc.  The source-code is now correctly in CodePlex so you can now browse it.  I also made a few breaking changes to the API to support flagging a sample as a keyframe, so compressed...

Read More »

By Jeremiah Morrill on 3/31/2008 4:23 PM

I keep going on and on about performance of the VideoRendererElement...well because I think it's important that peeps know.

As you can see in this video that the webcam is indeed in WPF space (reflection).  It is doing 640x480x30FPS live from the camera.  I show the Task Manager running about about 4 - 6% CPU.  Playing the webcam in regular graphedt.exe (not in WPF) yields about 4% CPU usage.  So most of the CPU tax is on the webcam driver itself, making VideoRendererElement almost nothing...

Read More »

By Jeremiah Morrill on 3/30/2008 11:12 PM

The VideoRendererElement..well I'm sure some of ya'll are tired of hearing about it.  But the beta is on Codeplex with a sample that shows you how to get a capture source (webcam) in WPF along with the GDI and compressed sample example.

There's some bugs left it in..and definitely a little refectoring needed.  I don't think the VideoRendererElement should inherit from Control, but maybe FrameworkElement.  I need...

Read More »