ui thread

Apr 30, 2010 at 5:49 AM

Hi Jer

I seems like the mediaelement is playing on the same thread as the ui ...  so if my software is doing anything else the player locks up until the process is finished. is there any way it can do its thing off the ui thread. I know when I was using directshow the video ran without interuption regardless of what was going on.

Regards David

 

Coordinator
Apr 30, 2010 at 6:01 AM
Actually I do have everything running on another thread.  The only thing that happens on the UI thread is a) creating the thread to run everything on.  b) Telling D3DImage to update the video frame.

What sounds like is happening is you are blocking the UI thread by doing work on it.  So no UI updates can happen (ie buttons cant be clicked, animations don't move, etc).  Try moving your blocking code to a new thread.

-Jer
May 14, 2010 at 7:47 PM

I have the same problem, I have a main application window that handles navigation in the various application screens. The WPFMediaKit MediaUriElement is hosted in a second window in the same application. Whenever I press a button in the main window and there is some animation for example, the video on the WPFMediaKit window pauses momentarily then continues. The audio does not skip and sync is not lost after that. How is it possible that WPFMediakit gets stuck while a WPF MediaElement does not? The MediaElement most probably runs in the UI thread. Is it possible that using a separate Dispatcher for your player causes this problem?

Regards,

John

Coordinator
May 14, 2010 at 9:05 PM
The MediaElement has the luxury of updating the video frames on the render thread, not the UI thread like in D3DImage.  Most likely the video studders for a second because your UI thread is busy building the visual tree for UI you are navigating to.  If the UI thread is being blocked (running code that takes longer than a few miliseconds), the D3DImage cannot call the Invalidate method to update the video frame.  The audio continues to run because it is ran on another DShow thread and is not blocked.

My only suggestion in your case is to run your second window that has the MediaUriElement on it's own Dispatcher/Thread or make sure your UI thread isn't loading a heavy visual tree when navigating...or doing anything of significant work for that matter.

-Jer
May 15, 2010 at 7:57 AM

Hello Jer,

Thanks for your prompt response. Your description sounds 100% accurate, indeed there's some non-negligible processing in event handlers (I presume the UI thread) and a fairly complex visual tree in most of the pages. Since there is a lot of code in the main window pages, running the MediaUriElement window on it's own thread sounds like a simpler and more isolated change. The problem is am not very familiar with the WPF threading model. Is it mandatory that I use a new thread or can I use a second Dispatcher on the UI thread? Do you have any recommendations for some good reading on WPF threading issues I can go through to achieve this result? Perhaps also some parts of your code for WPFMediakit I can study, if you are doing similar things.

Thanks a million,

John

May 18, 2010 at 3:35 PM

To whom it may concern. I used the information on this page to get it done. I run the MediaUriElement on a separate window and make sure there are no cross-thread issues with the rest of the application. It worked out pretty well, there is a very slight jitter when it shares time with the ui thread but it is barely noticeable.

http://eprystupa.wordpress.com/2008/07/28/running-wpf-application-with-multiple-ui-threads/

Best,

John

 

May 18, 2010 at 11:02 PM

Hi John

Thanks for the link... it should solve my problem as well.

Regards David