View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000226 | madVR | bug | public | 2014-07-13 14:55 | 2015-05-02 11:32 |
| Reporter | romulous | Assigned To | madshi | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | not fixable | ||
| Summary | 0000226: Zoom Player OSD Flickering | ||||
| Description | Originally logged as a Zoom Player bug (0000618), bLight believes the issue is inside madVR. Basically, in some circumstances, there is flickering of the Zoom Player OSD when using madVR. | ||||
| Steps To Reproduce | 1. 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 Information | bLight 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. | ||||
| Tags | No tags attached. | ||||
| madVR Version | 0.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 | ||||
| Decoding | Software | ||||
| Deinterlacing | auto mode | ||||
| DXVA2 Scaling Active | no | ||||
| Aero / Desktop Composition | On | ||||
| Problem occurs with mode | windowed mode | ||||
| GPU Manufacturer | NVidia | ||||
| GPU Model | GTX 660Ti | ||||
| GPU Driver Version | 337.88 | ||||
|
|
Can't reproduce this with ZP v10, either. Can you? |
|
|
Yes, can still reproduce. |
|
|
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? |
|
|
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). |
|
|
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. |
|
|
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? |
|
|
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) |
|
|
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? |
|
|
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. |
|
|
Ok, sure - I have reopened the bug report on the Zoom tracker and have made your suggestion to bLight in the comments. |
|
|
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. |
| 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 | |
| 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 |
