|
|
Apr
19
Written by:
Jeremiah Morrill
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 is very interesting to me. We can render a D3D scene directly into WPF for composition. Well...DirectShow and Direct3D have a very close relationship via the VMR9 and EVR. With custom allocators and custom presenters, we can render video from DirectShow, directly to D3D. This means we can finally have a solid method of doing custom video in WPF. No hacks, no trickery and no mess. I could have had DVDs in WPF finished by now. I could support hardware accelerated decoding of some media types (such as MPEG2 via DXVA). Possibly even Blu-ray video if the copy protection doesn't get in the way. I could also focus my time better on bringing cool multi-media features into WPF instead of jumping through hoops to get the basics going. This is all contingent that the new D3D interop performs well. I have queried some folks about the D3D, but all is quiet...Maybe my forum questions will yield some results. In the mean time, I'm taking a break on further development until I learn more. The CTP should be out soon...right? -Jer
Tags:
10 comments so far...
Re: VideoRendererElement - Development Temporarily Suspended
Please release on Codeplex what you have so far. I realy need a WPF render so I can build my own graph. Need to playback VOB/MPEG and DigitalTV DVB. I have working graphs (with regular render).
Please :-)
By Ken on
4/22/2008 3:16 PM
|
Re: VideoRendererElement - Development Temporarily Suspended
The problem with the code I have for the VRE is that it is mad hard-coded. I really couldnt believe how much extra crap went into supporting VIDEOINFOHEADER2. For one, it had to have some custom settings for the ALLOCATOR_PROPERTIES, then the EVR was doing a dynamic media change on my filter (it wanted to change the 720x480 to 760x480), causing even more issues.
None of this would be a problem if I didn't have the COM STA issue in talking to the filter-graph WMP makes after it is created.
I believe the current VRE will work for you with a little more hacking. Install FFDSHOW and in the codecs, enable all the uncompressed formats (RAW) at the bottom of the list in the configuration. Next build your graph like: mpeg source->decoder->ffdshow->sample-grabber. FFDSHOW can convert your VIDEOINFOHEADER2 samples to a nice RGB32 or whatever colorspace you want using the supported VIDEOINFO.
Hope this helps.
-Jer
By Jeremiah Morrill on
4/23/2008 4:20 AM
|
Re: VideoRendererElement - Development Temporarily Suspended
Jerry! Love your work. Your original MediaBridge example allowed me to build a wpf-based PVR app (http://pvr.sichbo.ca)
I agree custom allocator/presenter with Direct3d is a nice way to go, I had tried this a couple years ago before WPF was released, wrapping 720x480 video on a cube, and zooming in/out with keys... playback was surprisingly smooth.. but got frustrated as hell when I couldn't resize the win form and restart MDX 1.0/2.0 "scene" without it all "locking up", threading locks galore didn't help. Then WPF came along, then MediaBridge came along, and then everything I needed to build my app was in place.
I'm not sure that, even if we did have video texture, it would perform any better than building the graph "..Demux->Video Decoder->Avalon EVR".. like we do with bridge approach.
I will have to keep an eye on Direct3d interop in wpf. I had wondered about d3d+wpf for a while... My thought is "MS have a cripple direct3d in wpf, why cant we get a scene handle, or send video textures to it." That would be ace and wouldn't need a registered .ax at all.
By Simon on
4/28/2008 10:00 AM
|
Re: VideoRendererElement - Development Temporarily Suspended
Hi Simon,
Your PVR looks wonderful! You might want to try the VRE because you can create your own graph and pump samples into it w/o having to worry about the COM STA issues. This means you can tell your TV tuner interface to change channels w/o having to re-init the graph.
The MS guys said with the new D3DImage we will be able to get a native D3D surface pointer (w/ some reflection). I don't want to get too excited before I see the functionality/performance, but I agree that could be wonderful! We would also have more control and maybe kill the video tearing on some systems...Even use the VMR9 for XP.
-Jer
By Jeremiah Morrill on
4/28/2008 10:11 AM
|
Re: VideoRendererElement - Development Temporarily Suspended
Hi! got this from a Microsoft blogg abot .NET 3.5 SP1, wish is realy intresting. Maybe an DirectShow and a Allcator onto Direct3D surface...
--- clip ---
WPF Interoperability with Direct3D
.NET 3.5 SP1 adds support to efficiently integrate Direct3D directly into WPF. This gives you more direct access to the hardware and to take full advantage of the Direct3D API within WPF applications. You will be able to treat Direct3D content just like an image within an application, as well as use Direct3D content as textures on WPF controls.
http://weblogs.asp.net/scottgu/archive/2008/05/12/visual-studio-2008-and-net-framework-3-5-service-pack-1-beta.aspx
By Ken on
5/13/2008 12:45 PM
|
Re: VideoRendererElement - Development Temporarily Suspended
Hi Ken!
Sadly, the D3DImage is not in this beta release, but should come in the next beta (I'm speculating). This is the feature that gets me the most excited, but I can't say I'm dissapointed...the pixel shader support will keep me busy for a minute!
By Jeremiah Morrill on
5/13/2008 1:33 PM
|
Re: VideoRendererElement - Development Temporarily Suspended
Yes a saw that (after psoting...) that is not in the beta. But when relesed or beta2. I think it will be real intresting to se what we can do.
By Ken on
5/14/2008 12:43 AM
|
Re: VideoRendererElement - Development Temporarily Suspended
Thanks Jer - sichbopvr's coming along, it'd be nice to have various hardware on hand for testing!
I haven't actually encountered any problems with needing to rebuild graphs. My approach used 2x dedicated graph treads, one (or more) created by the app for Capture Device(s)->StreamBufferEngine(s), the second created by MediaElement "as needed" for playback. We can call the various IMediaPosition/Position, IStreamBufferMediaSeeking2/Position and IGraphBuilder.Pause/Run methods from the main WPF thread without any problem. I don't use MediaElement's control methods other than volume, and "Stop()" to destroy the graph cleanly--attempting to release a MediaElement graph yourself will produce all kinds of not-fun.
I hope the guys at MS can speed up WPF a little bit for existing hardware (dream on.. *cough*) Standard Def performance is "ok" on a 128mb nvidia (hardware rendering) for instance, but 1080i samples run slow as molasses.
- Si
By Simon on
5/26/2008 1:52 PM
|
Re: VideoRendererElement - Development Temporarily Suspended
Jeremiah,
Sorry I never replied to your comment at http://tdistler.com/2008/01/29/getting-custom-video-streams-into-wpf-natively ... I've been pretty busy.
The D3DImage stuff is pretty exciting, assuming the performance is on par. I know our team will be looking at this stuff also to render our video and doing video analytics overlays (object tracking, etc).
My hope for the future is easier access to the DShow graph... no more "hacks" required. The most difficult part of this whole thing is closing the "loop"... giving the app a reference to the graph (so custom events, etc can be passed back up).
Keep up the good work! I'm glad to see others as excited about this stuff as we are.
By Tom Distler on
6/10/2008 9:25 AM
|
Re: VideoRendererElement - Development Temporarily Suspended
Jeremiah,
Sorry I never replied to your comment at http://tdistler.com/2008/01/29/getting-custom-video-streams-into-wpf-natively ... I've been pretty busy.
The D3DImage stuff is pretty exciting, assuming the performance is on par. I know our team will be looking at this stuff also to render our video and doing video analytics overlays (object tracking, etc).
My hope for the future is easier access to the DShow graph... no more "hacks" required. The most difficult part of this whole thing is closing the "loop"... giving the app a reference to the graph (so custom events, etc can be passed back up).
Keep up the good work! I'm glad to see others as excited about this stuff as we are.
By Tom Distler on
6/10/2008 9:26 AM
|
|
|
Text/HTML
|
 |
|
|
|
|
|