Haali not disposed after stopping video (1 Viewer)

[hoborg]

OK, just did test in new SVN and problem is fixed but only 1/2.
Graph is corectly (?) released, MS video decoder and PDVD h.264 decoders works now, but not MPC video decoder. You can open/close video 9 times with MPC decoder in use, then MP tells you cannot play video and you can see 9haali icons + 9ffdshow audio icons (in my case).

That mean MPC video decoder is steel unusable

again - no problem on GB-PVR with same graph in use...

EDIT:
On XP it is even worse then before, now you can only play video 3times with MPC video decoder and you got cannot play video message (prew. version play video always). That is bad, really bad :/

XP log

From error log:

2009-09-16 21:41:05.436610 [ERROR][MPMain]: VideoPlayer9:exception while creating DShow graph Attempted to read or write protected memory. This is often an indication that other memory is corrupt.    at DirectShowLib.IGraphBuilder.RenderFile(String lpcwstrFile, String lpcwstrPlayList)
   at MediaPortal.Player.VideoPlayerVMR9.GetInterfaces()
2009-09-16 21:41:05.452238 [ERROR][MPMain]: VideoPlayerVMR9: Exception while cleanuping DShow graph - Object reference not set to an instance of an object.    at MediaPortal.Player.VideoPlayerVMR9.Cleanup()
2009-09-16 21:41:05.452238 [ERROR][MPMain]: PlaylistPlayer: *** unable to play - L:\MP\_videa\bbc-blue_m1080p.mkv - skipping track!
2009-09-16 21:41:14.875801 [ERROR][MPMain]: VideoPlayer9:exception while creating DShow graph Attempted to read or write protected memory. This is often an indication that other memory is corrupt.    at DirectShowLib.IGraphBuilder.RenderFile(String lpcwstrFile, String lpcwstrPlayList)
   at MediaPortal.Player.VideoPlayerVMR9.GetInterfaces()
2009-09-16 21:41:14.875801 [ERROR][MPMain]: VideoPlayerVMR9: Exception while cleanuping DShow graph - Object reference not set to an instance of an object.    at MediaPortal.Player.VideoPlayerVMR9.Cleanup()
2009-09-16 21:41:14.875801 [ERROR][MPMain]: PlaylistPlayer: *** unable to play - L:\MP\_videa\bbc-blue_m1080p.mkv - skipping track!

Now i tryed to play same video and MP crashed completly (freeze) - MP was able to play/stop video 6times now.

I think i found reason - if i play/stop video using PDVD decoder, MP write in log "Remove filter from graph:" + all used filters, but with MPC decoder in use, logs about removing filters end on "Remove filter from graph: MPC - Video decoder" - it look like MP by some reason failed on removing this filter from graph, generate in error log message about Exception while cleanuping DShow graph...
That explains why Haali + FFDShow audio decoder remains in graph.

 

[tourettes]

OK, just did test in new SVN and problem is fixed but only 1/2.
Graph is corectly (?) released, MS video decoder and PDVD h.264 decoders works now, but not MPC video decoder. You can open/close video 9 times with MPC decoder in use, then MP tells you cannot play video and you can see 9haali icons + 9ffdshow audio icons (in my case).

Are those icons removed if you hover the mouse over them? If not then haali indeed isn't released properly.

I think i found reason - if i play/stop video using PDVD decoder, MP write in log "Remove filter from graph:" + all used filters, but with MPC decoder in use, logs about removing filters end on "Remove filter from graph: MPC - Video decoder" - it look like MP by some reason failed on removing this filter from graph, generate in error log message about Exception while cleanuping DShow graph...
That explains why Haali + FFDShow audio decoder remains in graph.

This is interesting info. Does it happen only with MPC-HC using HW accell? Not sure what could cause removing filter to fail. From MP's point of view there is no difference when some filter uses HW accell when it is going to be removed from the graph. All filters are threaded equally, so it could be some bug in MPC-HC that we are able to trigger (as the error message suggest C++ side issue). Does it happen as well with VMR9 in use? If not then it could be something that we are releasing too early in EVR custom presenter and that causes MPC-HC to crash when it accesses some resources that are freed already.

As a hack we could try to release the MPC-HC as the first filter (really UGLY).

Currently I have no free time to investigate this (and as I'm not using MPC-HC for anything, it will have pretty low priority on my TODO list). So anyone who is affected this bug is recommended to start debugging it (included MPC-HC filter debugging as well ).


update: the good thing is that we now have at least a idea why the bug is happening...

 

[hoborg]

This is interesting info. Does it happen only with MPC-HC using HW accell? Not sure what could cause removing filter to fail. From MP's point of view there is no difference when some filter uses HW accell when it is going to be removed from the graph. All filters are threaded equally, so it could be some bug in MPC-HC that we are able to trigger (as the error message suggest C++ side issue). Does it happen as well with VMR9 in use? If not then it could be something that we are releasing too early in EVR custom presenter and that causes MPC-HC to crash when it accesses some resources that are freed already.

As a hack we could try to release the MPC-HC as the first filter (really UGLY).

Currently I have no free time to investigate this (and as I'm not using MPC-HC for anything, it will have pretty low priority on my TODO list). So anyone who is affected this bug is recommended to start debugging it (included MPC-HC filter debugging as well ).


update: the good thing is that we now have at least a idea why the bug is happening...

Yes, EVR+WMR9 have same issue.

BTW, i got info from Tatsuo55 from MPC-HC team, that they will now aim for better support of demultiplexer on thier MPC video decoder, so disabling this filter is not really good idea i think Lot o users using it - it is best DXVA decoder available...

I am not programmer, so expect from locate problem im cannot help here any longer

 

[tourettes]

Yes, EVR+WMR9 have same issue.

How about DXVA? Does disabling it solve the crash...?

BTW, i got info from Tatsuo55 from MPC-HC team, that they will now aim for better support of demultiplexer on thier MPC video decoder, so disabling this filter is not really good idea i think Lot o users using it - it is best DXVA decoder available...

That is a good news in short it means that it could start to work with current TsReader. What comes to best DXVA decoder available, I have to note that it is not supporting interlaced VC-1 content so it cannot be the best one

I am not programmer, so expect from locate problem im cannot help here any longer

Your testing has been already very helpful. I would have done same myself, but I'm just out of free time and when I have some free time I put it into areas in MP that I personally gain some benefit.

 

[hoborg]

How about DXVA? Does disabling it solve the crash...?

Cannot try now, but i bet SW mode works OK.

That is a good news in short it means that it could start to work with current TsReader. What comes to best DXVA decoder available, I have to note that it is not supporting interlaced VC-1 content so it cannot be the best one

You are right about VC-1i, and lot of MPC-HC users want it. MPC team told it will requaired ~100h to create it...

Benefit of MPC video decoder is that only this decoder i capable to detect used GPU and enable/disable DXVA automatically depending of source video ref.frames number.

For example, if you play 5.1 profile video with 6 or more ref. frames on ATI using PDVD/MS video decoder, you will see coruptions and you want be able to do anything with that. MPC decoder auto switch to SW mode and play video correctly.

 

[robyf]

OK, just did test in new SVN and problem is fixed but only 1/2.
Graph is corectly (?) released, MS video decoder and PDVD h.264 decoders works now, but not MPC video decoder. You can open/close video 9 times with MPC decoder in use, then MP tells you cannot play video and you can see 9haali icons + 9ffdshow audio icons (in my case).

That mean MPC video decoder is steel unusable

I think i found reason - if i play/stop video using PDVD decoder, MP write in log "Remove filter from graph:" + all used filters, but with MPC decoder in use, logs about removing filters end on "Remove filter from graph: MPC - Video decoder" - it look like MP by some reason failed on removing this filter from graph, generate in error log message about Exception while cleanuping DShow graph...
That explains why Haali + FFDShow audio decoder remains in graph.

I do not see this behaviour, instead I'm only able to play an .mkv/h.264 file once, like before, and haali icon remains in tray (even if I hover the mouse over it) like before when I stop the video. The good news is it only happens with MPC-HC (with DXVA enabled), microsoft codec seems to be released correctly now. Strange thing is that now ac3filter is not released correctly too (ac3filter icon remains in tray too). Will try to post logs in the evening.

Have tried only with windows 7 32bit RTM.

Note for people trying to reproduce the bug: YOU DO NOT HAVE TO EXIT MEDIAPORTAL after stopping the video (run it in windowed mode for instance). Play the video, stop it and go into the tray looking for haali icon if it's still there (and remains there hovering over it with the mouse).

 

[hoborg]

Strange thing is that now ac3filter is not released correctly too (ac3filter icon remains in tray too).

That not strange, it is logical. MP graph cleanup process crash when trying to remove MPC video decoder = rest of used decoders remain in graph.

 

[tourettes]

Cannot try now, but i bet SW mode works OK.

Thanks. I bet as well that the issue is not happening with software mode. After that someone needs to figure out what happens differently with those two modes. MPC-HC codec must behave differently somehow (release it's own resources in different order, or access renderer or something else in the graph that has already been disposed by MP). But only debugging will tell.

You are right about VC-1i, and lot of MPC-HC users want it. MPC team told it will requaired ~100h to create it...

Maybe they would add that support in change for more accurate time stamp code they have in MPC-HC (current one is broken) . Same code is used in MP, but with latest local video playback improvement investigations I did notice that the code is broken... Not that it would affect in normal playback that much, but if you need to time something in < 1 ms accuracy it is broken.

Benefit of MPC video decoder is that only this decoder i capable to detect used GPU and enable/disable DXVA automatically depending of source video ref.frames number.

For example, if you play 5.1 profile video with 6 or more ref. frames on ATI using PDVD/MS video decoder, you will see coruptions and you want be able to do anything with that. MPC decoder auto switch to SW mode and play video correctly.

Off topic, but if you can play the higher compression files already with CPU then you are able to play all those lower profile encodings as well so DVXA is pretty useless in that case (of course it creates less heat, but still...) Picking a better GPU that supports higher profiles is the correct way to solve such issue (no need to have codec to handle it).

 

[tourettes]

Note for people trying to reproduce the bug: YOU DO NOT HAVE TO EXIT MEDIAPORTAL after stopping the video (run it in windowed mode for instance). Play the video, stop it and go into the tray looking for haali icon if it's still there (and remains there hovering over it with the mouse).

Actually that is a must as closing the application will clean it's resource usage...

 

[hoborg]

Cannot try now, but i bet SW mode works OK.

Thanks. I bet as well that the issue is not happening with software mode. After that someone needs to figure out what happens differently with those two modes. MPC-HC codec must behave differently somehow (release it's own resources in different order, or access renderer or something else in the graph that has already been disposed by MP). But only debugging will tell.

You are right about VC-1i, and lot of MPC-HC users want it. MPC team told it will requaired ~100h to create it...

Maybe they would add that support in change for more accurate time stamp code they have in MPC-HC (current one is broken) . Same code is used in MP, but with latest local video playback improvement investigations I did notice that the code is broken... Not that it would affect in normal playback that much, but if you need to time something in < 1 ms accuracy it is broken.

Benefit of MPC video decoder is that only this decoder i capable to detect used GPU and enable/disable DXVA automatically depending of source video ref.frames number.

For example, if you play 5.1 profile video with 6 or more ref. frames on ATI using PDVD/MS video decoder, you will see coruptions and you want be able to do anything with that. MPC decoder auto switch to SW mode and play video correctly.

Off topic, but if you can play the higher compression files already with CPU then you are able to play all those lower profile encodings as well so DVXA is pretty useless in that case (of course it creates less heat, but still...) Picking a better GPU that supports higher profiles is the correct way to solve such issue (no need to have codec to handle it).

tourettes, i am not a flamer type, so lets close gpu discussion and aim on problem.
Becouse we located source of problem, i think this thread should be renamed, becouse it have nothing to do with haali - something like MP failed to remove MPC video decoder (DXVA ON) from graph.
Becouse the problem only happend in MP, i am sugesting to add this to MP bug tracker too.

BTW, can the problem have something to do with output format? I think MPC decoder with DXVA on is outputing to NV12, but not when DXVA is off (cyberlink output to NV12 in both cases).