0

I don't know how to phrase the question because I'm really not sure what is actually happening. I have an app written using a number of MediaElements. I've written it in both WinRT (C#) and WPF and seen the same behavior. Regardless, it basically is one page of video thumbnails on repeat navigating to a second page with the video. It works great for a while.

But after a while (i.e., lot's of debug-stop-debug), one video thumbnail will not load...just get a green screen. Then another. Then another. And then finally all of the videos stop displaying, though they will still be playing, as I can hear the audio on the "big" video page.

Interestingly, at that point, WMP and most every other video app (even browsers) stops showing video, as well. VLC DOES play correctly, though. I point this out because I assume what is likely happening is that I'm somehow exhausting a limited number of "video renderer handles" (dunno) from DirectShow or some layer just below that which VLC bypasses.

I've gone to great lengths to make sure all streams are closed and disposed and such whenever they end, but obviously either there's a bug in the MediaElement or I'm missing some opportunity to close a handle or dispose of something directly related to the rendering engine. This happens on multiple PC's and (with the WPF version) happened both on Win7 and Win8.1. Have to reboot to clear it up. Any ideas on where to start sleuthing?

Edit:

I'm playing local files. Binding the source to a Uri in .Net and setting it to an open IRandomAccessStream in code in WinRT. Same behavior in both scenarios.

paul
  • 85
  • 1
  • 7
  • You don't mention where the video is coming from, but if it is from a live source (webcam, stream), I think you should not expect to be able to stop, debug and continue afterwards. – wimh Jun 02 '14 at 17:29
  • Ah, yes, thanks. It is coming from a local file (MP4). In WPF it sets the source to a local Uri pointing to the video file. In WINRT it sets the source to an open stream. It's not so much debug/continue as debug/stop/recompile/debug. Really isn't even the debug cycle that seems to be at issue. Seems more the number of times the MediaElement is initialized and its Source is set... – paul Jun 02 '14 at 20:28

1 Answers1

1

Your symptoms suggest that video renderers are not released and still hang around. They are a limited resource, then you run out of them (see some details on this question) and then video presentation issues. You might perhaps be able to compare the behavior against VMR7 renderers which are typically available in larger quantities, and then the solution would be in releasing the unused objects reliably.

Community
  • 1
  • 1
Roman R.
  • 68,205
  • 6
  • 94
  • 158
  • Thanks for the reply. Yes, I'm 99% sure this is exactly the issue. Unfortunately, I have very little control over the renderer choice since I'm relying on the MediaElement control. I'm REALLY hoping not to have to learn DirectShow/Media Framework and create my own control in C++ just to get around this. I'm hoping that perhaps explicitly setting the Source to null whenever the MediaElement is Unloaded might release the renderer resource. I'll report back either way. Thanks again! – paul Jun 03 '14 at 17:43