Call for tester for 1.4.0 features and fixes (3 Viewers)

[Atomic7431]

it seems to depend on how quick you are with turning the amp on and off for sd anyway, if i wait 1 second then the video and audio are all playing still, if i wait 5/6 seconds then the video is still playing with no audio or it throws up the error with video playing in a window, if i wait 14/15 secs then were back at the videos selection and nothing playing.

Faulting application name: MediaPortal.exe, version: 1.3.0.0, time stamp: 0x516d1103
Faulting module name: audiokse.dll, version: 6.1.7600.16385, time stamp: 0x4a5bdac9
Exception code: 0xc0000005
Fault offset: 0x00059cfa
Faulting process id: 0x%9
Faulting application start time: 0x%10
Faulting application path: %11
Faulting module path: %12
Report Id: %13

this comes up in nearly all the error reports in windows event viewer

 

[Scythe42]

Nope, I mean instead of Lav Video / Lav Audio / Lav Splitter try a combination of MPCVideo, ffdshow, Halli for example. Probably just a different audio filter could be enough. But as said it is probably Direct Show itself.

What you are describing is a result of the HDMI Audio Render being removed. Why is it removed? Because you turned your receiver off, and in the HDMI worked, HDMI audio renderer is an external device. Basically when it gets removed Windows is telling us that a the HDMI audio end point was removed.

Better exception handling inside our Direct Show graph will come. But it will not help if the codecs or drivers crash. In your logs for example playback was stopped, but still the Direct Show Graph crashed MP.

I assume when we deal with the exception in Direct Show itself it could work better. As the Direct Show notifications could come a few ms before the HDMI audio render removal. But working on DirectShow is out of scope for my work.

Faulting module name: audiokse.dll, version: 6.1.7600.16385, time stamp: 0x4a5bdac9
Exception code: 0xc0000005

Yep, audio endpoint handler of Windows crashed. That is exactly the symptom you see when Direct Show crashes and as a result crashes MP.

On issue with Direct Show: Micrsoft sees it as deprecated. But still the filter developers did not upgrade or wrap their filter to Media Foundation. Direct Show itself gets no real development (read new features) from Microsoft. But the transition will only happen when the free filter developers start to support Media Foundation as well.

 

[Scythe42]

it seems to depend on how quick you are with turning the amp on and off for sd anyway, if i wait 1 second then the video and audio are all playing still, if i wait 5/6 seconds then the video is still playing with no audio or it throws up the error with video playing in a window, if i wait 14/15 secs then were back at the videos selection and nothing playing.

Yep, that is correct. Exactly the reproducible HDMI audio issue. The faster you disconnect/reconnect the more likely you can crash DirectShow. I can do this with nearly all DirectShow based players on demand. Devs should be able to reproduce this. But even with error handling this might still happen.

Also when you put your receiver into standby it does not necessarily disconnect the HDMI connection right away. Some receiver keep it up for a second or so to avoid handshakes in case the AVR was turned off by accident or some accidental input switching is going on. So there might be workarounds for users.

Hardware based solution: Use a high end HDMI switchbox with full HDMI alive. Regardless what you do, your HDMI connection never gets removed from a windows point of view. Such stuff runs - depending on features - between 150 USD and 400 USD. Ouch. The problem is that the HDMI protocol was developed by TV engineers and the content industry instead of IT engineers. It has a lot of flaws/oversights.

It all comes down to the need of the handhshake for content protection. Yeah, sure someone in the digital world intercepts it from the cable. Nah, we rip the medium and stream right away before it ever hits the cable or have keys for satellite TV. Broadcasters had too much influence here with their need. No one was listening to the tech guys pointing issues out. The managers didn't want to hear it. They have their DRM dreams.

With 4K coming slowly HDMI will be gone. Currently HDMI cannot handle the bandwidth. You need a couple of cables for it, if you want to handle 4K streams. I hope they do not try to create something backwards compatible and instead learn from the mistakes.

That is also the reason why 4K displays are not coming fast. There is no content and no proper content delivery mechanism. Just letting a display upscale the content is worthless. I assume 4K content will be media less distribution mostly. BluRays are not selling as good at DVDs because the shitt BD-J menus are too slow.

If I not mistaken it is not even full Java but some Java Phone derivation. But I might be mistaken here. As much as I like bonus content in general (in the late 90s it was awesome, now it is mostly crap), I just put a new BR in my drive. Rip the main stream (just transmux it, no transcoding) and put int into an MKV on my storage array. Then the BR goes into the "archive box". When full, it goes into the cellar.

But back in topic:

It might not be possible though to fully prevent the crash when it goes to deep down into DirectShow. But it could be possible to sandbox it by starting the DirectShow graph in an own thread. Then the thread itself will only crash. That can be detected by MP as a "natural stop playback".

In fact having the graph run in its own thread is not that much of a problem. But given that we like to release 1.4.0 soon I cannot put this in anymore. Will have to wait until 1.5.0. Also I can create the issue with 1.3.0 also on demand.

When the main thread does not crash, MP should stay alive.

Hmm, the more than I think about it the more do I like this and think it will work to sandbox DirectShow this way. Will check the code if this could work.

DirectShow itself still creates its own background task but it is still anchored to the main MP thread or MP would not crash.

Here we enter the territory of STAThread vs. MTAThread and the way C# work. Need to read up on MSDN a bit.

 

[legnod]

So...i had time to test the new mp.exe and its nearly working now
only issue left is that the splashscreen (basic and fullscreen splashscreen) starts on main monitor if monitor 2 has been selected but mediaportal shows up on the correct screen (window and fullscreen).

 

[Atomic7431]

thanks for the input, will do some more tests with different codecs etc and without the audio on at all as im sure it will not occur that often. Think the work you people have put into this is great and hope it makes 1.4.0.

 

[Scythe42]

And we have winner... I am not 100% sure here, but it looks very much like a bug in LAV Audio that connects to the Audio Renderer. I cannot really confirm it as MP debugging capabilities ended at this point.

I could debug the crash down to Cleanup() in VideoPlayerVMR.9.cs. Not the exact point though as the DirectShowLib comes in, meaning where we leave C#.

When we do a IMediaControl.Stop() the audio filter crashes taking down MP with it right away. Could be also the IMediaControl.GetState() meaning a combination of both or its resulting state object. Have digged in that deeps.

What ever the filter does when a graph is stopped and/or state requested afterwards, it does not handle the condition that the audio rendered it is connected to does not exist anymore.

When using ffdshow for audio for example I can properly stop the graph 100% at all times. LAV = I crash.

Of course if we leave the filter running the audio endpoint manager will crash naturally at a later point. Most likely the next time the device gets connected again.


Correct solution:
Stop Direct Show Graph on an error reported by DirectShow Graph handling instead off a device notification message. But in fact MSDN tells that if you want more details about what causes the error you should use DeviceNotifications. Advantage is that the DS Graph only raises the event when a it uses the audio device. So it will be general usable withotu any options.

But the filter cleanup still needs to happen or we still have the references to the COM objects. For example you would still see a tray item if you let a filter show its activity their.

@Developers: Anyone has a good connection to nev and sorting this one out with it? Even when LAV audio is still connected to an audio renderer that has been removed from the system (100% reproducible with HDMI audio) the graph must be stoppable properly and not crash the audio endpoint management of Windows.

What seems to work. I wrap the whole Cleanup() call in a worker thread and just let the thread crash. Yes, there are left over COM objects, but hey, they could not be cleaned up anyway. But that would prevent problems with filters killing MP.

I am torn here what to do...

 

[tourettes]

@Developers: Anyone has a good connection to nev and sorting this one out with it? Even when LAV audio is still connected to an audio renderer that has been removed from the system (100% reproducible with HDMI audio) the graph must be stoppable properly and not crash the audio endpoint management of Windows.

Audio decoder has no connection to the real audio HW / drivers, the component to be blamed is audio renderer. Instead of the HDMI audio renderer try to use DS default audio renderer and/or MediaPortal Audio Renderer to see if they behave any better. I would assume DS renderer works nicely, but MPAR wont.

 

[Scythe42]

So...i had time to test the new mp.exe and its nearly working now
only issue left is that the splashscreen (basic and fullscreen splashscreen) starts on main monitor if monitor 2 has been selected but mediaportal shows up on the correct screen (window and fullscreen).

So, you saying that splashscreen always still starts on your primary display regardless which type of spashscreen you use.

Let's take a look what the logs tell me:

Screen Selection takes places, nicely on display 2

[2013-04-17 18:23:49,508] [377	] [SplashScreen] [INFO ] - SplashScreen: Splash screen is using screen: \\.\DISPLAY2 (Position: -1920,0 Dimensions: 1920x1200)
[2013-04-17 18:23:49,549] [419	] [MPMain  ] [INFO ] - Main: MP is using screen: \\.\DISPLAY2 (Position: -1920,0 Dimensions: 1920x1200)

No screen changes, we do not want.

[2013-04-17 18:23:49,565] [434	] [MPMain  ] [DEBUG] - Main: WM_GETMINMAXINFO
[2013-04-17 18:23:49,580] [450	] [MPMain  ] [DEBUG] - Main: WM_GETMINMAXINFO
[2013-04-17 18:23:49,580] [450	] [MPMain  ] [DEBUG] - Main: WM_GETMINMAXINFO
[2013-04-17 18:23:49,583] [452	] [MPMain  ] [DEBUG] - Main: WM_GETMINMAXINFO
[2013-04-17 18:23:49,583] [452	] [MPMain  ] [DEBUG] - Main: WM_GETMINMAXINFO
[2013-04-17 18:23:49,585] [455	] [MPMain  ] [DEBUG] - Main: WM_GETMINMAXINFO
[2013-04-17 18:23:49,585] [455	] [MPMain  ] [DEBUG] - Main: WM_GETMINMAXINFO
[2013-04-17 18:23:49,585] [455	] [MPMain  ] [DEBUG] - Main: WM_GETMINMAXINFO
[2013-04-17 18:23:49,588] [457	] [MPMain  ] [DEBUG] - Main: WM_GETMINMAXINFO

Form for the splash screen is setup, and we are still good. Matches screen selector

[2013-04-17 18:23:49,588] [457	] [SplashScreen] [DEBUG] - SplashScreen: Fullscreen splash screen size: 1920x1200 @ -1920,0

Nothing else is logged. So I guess I need to put in some more code in the SplashScreen to debug when it resets the location I actually set when I created the form.

 

[legnod]

So, you saying that splashscreen always still starts on your primary display regardless which type of spashscreen you use.

correct

 

[Scythe42]

Audio decoder has no connection to the real audio HW / drivers, the component to be blamed is audio renderer. Instead of the HDMI audio renderer try to use DS default audio renderer and/or MediaPortal Audio Renderer to see if they behave any better. I would assume DS renderer works nicely, but MPAR wont.

Makes no difference if I choose a HDMI device directly from the list or the Default Device. Only thing I at least can reproduce it a crash as soon as LAV Audio is inside the graph when stopping the graph after the audio render got disconnected from the system. With ffdshow in the graph it does not crash.

Again not ruling out that my system could be part of the issue. I in general have a lot of issues with LAV Audio. So I might be biased.

I do not know enough about DS filter writing and how they interact with each other. I could be completely wrong here.

That's just what a quick test showed me. In the end it will of course always be a crash in the audio endpoint library. But both NVidia and AMD behave the same for me, which rules out a driver issue. In fact in a driver issue we would see a BSOD.

Also important: best reproducible with bitstreaming. With MP3s I never could produce a crash on demand when letting the Direct Show Graph run.

MPAR: cannot tell you how MPAR behaves as I cannot get it to run properly. I have huge lipsync issues and audio glitches. But that could be my system setup. As a bitstreamer I have not looked much into MPAR yet. It behaves totally different as we have a component in addition to the actual endpoint audio device. Similar when using ReClock.

So the audio renderer device itself seems not really the problem. It seems that what is connected to it, tells it something and then it talks to the actual device any we are gone.

If we break it down this is without question a defect inside the audio endpoint handler from Microsoft. That the component actually crashing. It should trap this problem and not crash. But for DirectShow we will never see an update here. And as said, different audio filters seem to behave differently. So we need to find a workaround for something MS will not update anymore in relation to DirectShow. Does not mean that a future update will not handle this. Have not tested in how far Win8 behaves better than Win7 here. I only have Win7 where I have a HDMI audio connection available.

Not ruling out an actual problem how MP is doing the CleanUp() though that might not be 100% compatible.

But what should we do to prevent MP from crashing regardless where the bug comes from? By sandboxing the Cleanup() in a thread MP itself should not crash. Error logging should be possible when we check if the thread properly returned a code. Not nice but everything else means going down the DirectShowLib and doing something over there, which would be even worse in my opinion. Also makes no difference if I use a newer DirectShow Lib.

I am torn here what to do on the MP side...