madshi bug tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000226madVRbugpublic2014-07-13 14:552015-05-02 11:32
Reporterromulous 
Assigned Tomadshi 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionnot fixable 
PlatformOSOS Version
Summary0000226: Zoom Player OSD Flickering
DescriptionOriginally logged as a Zoom Player bug (#618), bLight believes the issue is inside madVR. Basically, in some circumstances, there is flickering of the Zoom Player OSD when using madVR.
Steps To Reproduce1. Ensure Zoom Player is using madVR as the video renderer. Inside madVR, I have FSE disabled, and I also have Overlay disabled.
2. In Zoom, disable the following option - the bug does not occur if this option is enabled, which is the default:
Playback : Video > Display OSD through MadVR's OSD API (preserves fullscreen exclusive mode)
3. Open Zoom's playlist and add a number of files to it.
4. Close the playlist, and with Zoom in windowed mode, start playback.
5. Use [ and ] to move through the playlist, looking carefully at the OSD display in the top right corner of Zoom's window.
6. If you watch carefully, when you hit ] to move to the next file, the 'Next Track' message on the OSD will display, then the text will flash quickly, and then display the same text again. Rather than just show the text for say 2 seconds, it seems to - at least from a visual standpoint - show it for 1 second, turn it off for a frame or two, then show it again for another second.
7. For best results, wait until the 'Next Track' disappears before moving to the next track - it just makes it easier to see the behaviour (ie rather than quickly moving through the playlist and trying to look at the OSD text, do it slowly and give the OSD text time to disappear before moving to the next file).
Additional InformationbLight speculated that it is possible that madVR is disabling and then returning the OSD window's "on top" status and then restoring it, and that may be what is causing the issue.
TagsNo tags attached.
madVR Version0.87.10
Media Player (with version info)Zoom Player v9.1
Splitter (with version info)LAV v0.62
Decoder (with version info)LAV v0.62
DecodingSoftware
Deinterlacingauto mode
DXVA2 Scaling Activeno
Aero / Desktop CompositionOn
Problem occurs with modewindowed mode
GPU ManufacturerNVidia
GPU ModelGTX 660Ti
GPU Driver Version337.88
Attached Files

- Relationships

-  Notes
(0000806)
madshi (administrator)
2015-03-22 12:55

Can't reproduce this with ZP v10, either. Can you?
(0000839)
romulous (reporter)
2015-03-23 09:18

Yes, can still reproduce.
(0000840)
madshi (administrator)
2015-03-23 09:29

What can I do to reproduce the issue? I've followed your list, but can't reproduce it here. Without being able to reproduce the issue, there's not much I can do about it.

I've been testing with the latest version of my sources, of course, but there haven't really been any changes that would explain why there would be any difference compared to v0.87.14. You did test with v0.87.14, right?
(0000843)
romulous (reporter)
2015-03-23 11:12

Yes, 0.87.14. It's probably your settings - you need to have FSE and overlay disabled in madVR, and have the 'display OSD' setting in Zoom itself disabled (it is enabled by default).
(0000844)
madshi (administrator)
2015-03-23 13:02
edited on: 2015-03-23 13:02

Of course I've made all those changes, exactly as you described, but I still can't reproduce the bug... :-( I'll try with the settings you uploaded to the other bug report.

(0000846)
madshi (administrator)
2015-03-23 14:11

I can reproduce the problem now with your settings. However, I can't say for sure what exactly causes the problem. I've disabled all "on top" manipulations, and the problem still occurs. So it must be something else. The key problem seems to be that ZP totally destroys madVR and recreates it, when moving to the next file in the playlist. Somehow this produces this problem. Some of the processing when destroying and recreating madVR happens inside of the Microsoft base classes, so I'm not fully sure what's happening there exactly.

At this point I've no idea what I could do to fix this. It *could* be caused by madVR. But it could also be ZP's fault, I don't really know. The problem could probably be solved by not destroying and recreating madVR, but by simply unconnecting and reconnecting the pins instead. Maybe you can suggest that to bLight?
(0000862)
romulous (reporter)
2015-03-26 10:37

Thanks, I will do that. I thought I saw some discussion on Doom9 recently (in the MPC-HC, MPC-BE or MPDN threads) about FSE not being kept when moving from file to file in that particular player, and the response from one of the devs was that madVR itself is responsible for destroying itself and recreating itself when opening a new file (and this was why FSE mode was not kep from file to file). Is that not the case?

(I will have to see if I can find the thread again, it was only in the last week or so)
(0000863)
romulous (reporter)
2015-03-26 10:42

Ah, MPC thread. Beginning here:
http://forum.doom9.org/showthread.php?p=1712632#post1712632 [^]

Your response is the first one after that - I interpreted it to mean that madVR itself destroys itself each time. Was I wrong about that, and in fact it is the player which does this?
(0000864)
madshi (administrator)
2015-03-26 10:54

madVR never destroys itself. It's the media player (or maybe the DirectShow graph builder, if the media player lets it do all the work) is responsible for creating and destroying the madVR instance. There's nothing I can do about madVR being destroyed and recreated. The media player would have to do something to change that.

But that FSE topic is different to this bug. This bug is with FSE disabled. Still, I think both this bug and the FSE topic you mentioned can probably be fixed by the media player keeping madVR alive when switching from one file to the next in the playlist.
(0000865)
romulous (reporter)
2015-03-26 11:51

Ok, sure - I have reopened the bug report on the Zoom tracker and have made your suggestion to bLight in the comments.
(0000976)
madshi (administrator)
2015-05-02 11:32

Ok, I'll close this for now. If you have new information, or if Blight says it's definitely a bug in madVR, please reopen.

- Issue History
Date Modified Username Field Change
2014-07-13 14:55 romulous New Issue
2015-03-22 12:55 madshi Note Added: 0000806
2015-03-22 12:55 madshi Assigned To => madshi
2015-03-22 12:55 madshi Status new => feedback
2015-03-23 09:18 romulous Note Added: 0000839
2015-03-23 09:18 romulous Status feedback => assigned
2015-03-23 09:29 madshi Note Added: 0000840
2015-03-23 09:29 madshi Status assigned => feedback
2015-03-23 11:12 romulous Note Added: 0000843
2015-03-23 11:12 romulous Status feedback => assigned
2015-03-23 13:02 madshi Note Added: 0000844
2015-03-23 13:02 madshi Note Edited: 0000844 View Revisions
2015-03-23 14:11 madshi Note Added: 0000846
2015-03-23 14:11 madshi Status assigned => feedback
2015-03-26 10:37 romulous Note Added: 0000862
2015-03-26 10:37 romulous Status feedback => assigned
2015-03-26 10:42 romulous Note Added: 0000863
2015-03-26 10:54 madshi Note Added: 0000864
2015-03-26 10:54 madshi Status assigned => feedback
2015-03-26 11:51 romulous Note Added: 0000865
2015-03-26 11:51 romulous Status feedback => assigned
2015-03-26 12:54 madshi Status assigned => feedback
2015-05-02 11:32 madshi Note Added: 0000976
2015-05-02 11:32 madshi Status feedback => closed
2015-05-02 11:32 madshi Resolution open => not fixable


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker