madVR - high quality video renderer (GPU assisted)

[noee]

You can also tell that the madVR internal decoder is being used by checking the ctrl+J stats.

[cyberbeing]

is there an optimal setting for the gpu flush settings?
...
What do the settings do exactly?

There is no one-size-fits-all optimal flush setting. If you are having issues with stuttering panning scenes, tearing, or delayed/dropped frames, you can try playing with the flush settings. Otherwise just leave it as the default.

Their purpose is for fine-tuning madVR for your GPU and computer. Many factors like OS, Drivers, Aero, Subtitles, CPU, CPU load, and DPC latency can influence both your GPU and madVR. Flushing or not flushing after certain steps can at times change how your GPU behaves. Your goal when tweaking should be finding the minimal flush settings which show an improvement but don't cause other issues.

Don't Flush = Don't Flush - No CPU Load
Flush = Make a no-guarantee attempt to flush - Usually No CPU Load
Flush & Wait (Sleep) = Flush no later than 1ms after requested - Low to Moderate CPU Load
Flush & Wait (Loop) = Flush immediately when requested - Low to High CPU load

Flush & Wait (Loop) is somewhat dangerous to use, unless you never experience ANY slowdowns, high CPU load, or things other than madVR fighting for CPU/GPU time. Keep your eye out for increases in CPU load or dropped/delayed frames when using a Flush & Wait setting.

[racerxnet]

Build # 68 and 70 will not play DVD's. Fault is Nvidia.ax from the fault nag. Went back to an earlier version and all is well. Can you make sure the Nvidia decoders are able to be used as before. I tried with the internal MadVr decoder checked and it still would not play with MPC-HC and the Nvidia decoders enabled/disabled.

Thanks,

MAK

[JarrettH]

If we are talking nvidia purevideo software, that was made for older hardware and XP

[racerxnet]

If we are talking nvidia purevideo software, that was made for older hardware and XP

I have new hardware with old software, so you are correct. I am running XP still.

[andybkma]

madVR v0.70 released


* fixed: at playback start, and after unpausing there was sometimes judder


This has definitely improved :) Thanks so much, madshi. Nice to know that it just wasn't me that was experiencing this...

Edit: Dang! I must have borked something up because it's doing it again. I uninstalled madVR, cleaned it out from registry, re-registered the ax file, but it's still doing it. Tested in Zoom Player and PotPlayer. Juttering upon playback start. I wonder why it was working at first.

[cyberbeing]

Build # 68 and 70 will not play DVD's. Fault is Nvidia.ax from the fault nag. Went back to an earlier version and all is well. Can you make sure the Nvidia decoders are able to be used as before.

madshi, I just checked and there does appear to be a regression after madVR 0.66 with encrypted DVDs and the NVIDIA PureVideo Software decoder on Windows XP. madVR 0.67 has corruption. madVR 0.68-0.70 all crash the decoder. Did you accidentally remove the workaround you had in place for NVIDIA PureVideo's tendency to lie about what it's outputting?

Logs for 0.66/0.67/0.70: http://www.mediafire.com/?f150f9dymksxch0

[agustin9]

I'm having a problem:

Using the internal h264 decoder, while in exclusive mode, when i unpause a video it takes some time to resume.
It does not in windowed mode or using a external decoder

[Hypernova]

madshi, I may missed it but, is it your intention that internal decoder won't decode h264 in avi? I think this leads to some avi files crash MPC-HC every time I seeked.

[madshi]

madshi, thanks for the new version and for the internal decoders. Is it possible to use them in conjunction with ffdshow AviSynth?
Unfortunately no, unless I add AviSynth support myself, which I'm not planning right now.

And how do I make sure madVR internal decoder connects and not player's internal or externals?
There are 2 ways:

(1) Look which filters are in your graph. If there's a video decoder filter, madVR is not doing the decoding.

(2) Look at the madVR OSD (Ctrl + J):

madVR decoding: "libav, h264, 8bit, 4:2:0"
external decoder: "h264, 8bit, 4:2:0 -> NV12, 8bit, 4:2:0"

Build # 68 and 70 will not play DVD's. Fault is Nvidia.ax from the fault nag. Went back to an earlier version and all is well. Can you make sure the Nvidia decoders are able to be used as before.
I just checked and there does appear to be a regression after madVR 0.66 with encrypted DVDs and the NVIDIA PureVideo Software decoder on Windows XP. madVR 0.67 has corruption. madVR 0.68-0.70 all crash the decoder.
Will check that.

This has definitely improved :) Thanks so much, madshi. Nice to know that it just wasn't me that was experiencing this...

Edit: Dang! I must have borked something up because it's doing it again. I uninstalled madVR, cleaned it out from registry, re-registered the ax file, but it's still doing it. Tested in Zoom Player and PotPlayer. Juttering upon playback start. I wonder why it was working at first.
Make sure you reactivate the "delay playback" option because it's disabled by default in v0.70.

Using the internal h264 decoder, while in exclusive mode, when i unpause a video it takes some time to resume.
It does not in windowed mode or using a external decoder
This doesn't seem to happen on my PC. Can anybody else reproduce this? A log might help. Try to keep it short, by doing this:

Start the video, go exclusive mode, pause, wait 2-3 seconds, unpause, wait until playback is fluid again, close the media player. Don't do anything else. Every action you take makes the log longer. Thanks.

madshi, I may missed it but, is it your intention that internal decoder won't decode h264 in avi? I think this leads to some avi files crash MPC-HC every time I seeked.
Didn't check that. Which FourCC does the AVI splitter output? Does madVR even try to decode it (and fail)? Or does an external decoder take over?

[nevcairiel]

Didn't check that. Which FourCC does the AVI splitter output?

Typically its MEDIASUBTYPE_H264, stored in AnnexB format. Some splitters (LAV Splitter specifically) convert it to MEDIASUBTYPE_AVC1, removing the AnnexB start codes.
Note that the typical AVI splitters use FORMAT_VideoInfo and do not have the SPS/PPS in the format block (as defined by MSDN, if using MEDIASUBTYPE_H264 with start codes, you do not have to supply the extradata)

The most important part about H264 in AVI is however that the timestamps are DTS, not PTS, therefor you shall not reorder them.

[madshi]

Ah ok, thanks for the heads up!

@Hypernova, which AVI Splitter are you using?

[Hypernova]

Didn't check that. Which FourCC does the AVI splitter output? Does madVR even try to decode it (and fail)? Or does an external decoder take over?

It's H264. I am not sure how to find out the answer for the other two questions. I don't see any indication that madVR tried and failed though. I use Haali by the way.

Now that you mentioned FourCC. It's probably because H264 vs AVC1? I do not have h264 in avi that use AVC1 so I cannot be so sure.

Edit: Ah, looks like you and nevcairiel already figure it out :)

[madshi]

It's H264. I am not sure how to find out the answer for the other two questions. I don't see any indication that madVR tried and failed though. I use Haali by the way.
So is there some h264 decoder filter in your filter list, when playing back AVI h264 files? Probably is, because madVR doesn't support the "h264" FourCC yet. Which decoder filter are you using? Does the seek crash occur with every h264 AVI file you have?

[Hypernova]

So is there some h264 decoder filter in your filter list, when playing back AVI h264 files? Probably is, because madVR doesn't support the "h264" FourCC yet. Which decoder filter are you using? Does the seek crash occur with every h264 AVI file you have?

Yes, basically it fall back to ffdshow.

No it only crash on some files. That's why I kinda reluctant to report the crash by itself. I even suspect it's just a bad muxing somehow. If you still have the sample I uploaded before (http://www.mediafire.com/?9jf19139i6e0uh2) that was a part of one of the files that do crash. The strange thing is, that small sample does not crash every time I seek (unlike the original file), but take a long time to seek. And once in a while will crash MPC-HC.

Also, this looks like it has nothing to do with internal codec. I switched back to external ffdshow and it still crash. I'm certain that 0.67 does not crash. If you need to know if 0.68/0.69 crash on these files or not please let me know. TBH though I think this is a rare occasion so I'm exactly bother by it.

I tried checking the "delay playback..." and it does not help.

[agustin9]

This doesn't seem to happen on my PC. Can anybody else reproduce this? A log might help. Try to keep it short, by doing this:

Start the video, go exclusive mode, pause, wait 2-3 seconds, unpause, wait until playback is fluid again, close the media player. Don't do anything else. Every action you take makes the log longer. Thanks.

Here is the log:
http://www.megaupload.com/?d=Q38MCKDT

Thanks for your hard work

[adam777]

Hi madshi,
Thanks as always for the hard work.
Just a quick one - are the internal decoders multi-threaded? couldn't find a reference.
:thanks:

[Hypernova]

madshi, subtitile disappeared when paused again..

[cyberbeing]

AVI
...
I use Haali by the way.

Both the Haali AVI splitter (which is why it's disabled by default in the installer) and the Gabest/MPC-HC AVI splitter (no support for incomplete files?) have some bugs and limitations from what I remember. In general you should stick with the default Microsoft AVI Splitter, unless you have a particular reason to use something different. This could have nothing to do with your current problem of course.

[pirlouy]

Just a quick one - are the internal decoders multi-threaded? couldn't find a reference.
:thanks:
Yes; confirmed by Madshi recently (in last pages of this thread)

[madshi]

No it only crash on some files. That's why I kinda reluctant to report the crash by itself.
Here is the log:
http://www.megaupload.com/?d=Q38MCKDT
madshi, I just checked and there does appear to be a regression after madVR 0.66 with encrypted DVDs and the NVIDIA PureVideo Software decoder on Windows XP. madVR 0.67 has corruption. madVR 0.68-0.70 all crash the decoder.
Can the 3 of you please test whether these 3 problems are fixed in this special build?

http://madshi.net/madVR70special.zip

Just a quick one - are the internal decoders multi-threaded?
Yes.

madshi, subtitile disappeared when paused again..
Confirmed. <sigh> Will try to fix this again for the next build.

[adam777]

Thanks

[Blight]

madshi:

The good:
1. OSD flickering on pause/unpause is fixed.
2. The graph no longer pauses when switching to fullscreen on a second monitor.

The bad:
1. There's a lag of ~1 second between the time I call an OSD display function and the time the OSD appears on screen. You can clearly see it by playing in windowed mode and pressing space to show the control bar. You can see the difference in the time displayed in the control bar and the time displayed in the window. This is not such an issue when dealing with the limited OSD I've integrated, but it may prevent large scale OSD (like a menu system) from being responsive.
2. Alt+Enter is still causing issues. If I disable all my keyboard event handling, Alt+Enter is still doing something weird when MadVR is used. Are you familiar with a tool that will help me track the keyboard hook and find which module is causing this?

Feature Request:
Not really critical, but it may be 'nice to have' an additional OSD parameter that controls the alpha value of the entire OSD, for example, If I wanted to make the OSD dynamically translucent.

[cyberbeing]

Can the 3 of you please test whether these 3 problems are fixed in this special build?

http://madshi.net/madVR70special.zip


Still crashes. Log: http://www.mediafire.com/?9k1y9goypb10fo6

[madshi]

1. There's a lag of ~1 second between the time I call an OSD display function and the time the OSD appears on screen. You can clearly see it by playing in windowed mode and pressing space to show the control bar. You can see the difference in the time displayed in the control bar and the time displayed in the window. This is not such an issue when dealing with the limited OSD I've integrated, but it may prevent large scale OSD (like a menu system) from being responsive.
But in paused state the OSD reacts much faster, correct?

The problem is that I have to balance what is more important: (1) Smooth playback with no frame drops? Or (2) fast reacting OSD? Of course I could force a redraw of the next displayed frame to already include your modified OSD image, but that would require me to trash all pre-rendered frames (practically clear the rendering and backbuffer queues completely) and redo all the rendering work. I fear this might introduce a few frame drops once in a while. Maybe a compromise would make sense? E.g. instead of fully flushing the rendering queue, maybe I could only flush half of it? Or something like that? It's really not a problem getting the OSD to become quick. The only problem is that doing so might result in frame drops whenever the OSD changes...

2. Alt+Enter is still causing issues. If I disable all my keyboard event handling, Alt+Enter is still doing something weird when MadVR is used. Are you familiar with a tool that will help me track the keyboard hook and find which module is causing this?
If only I could reproduce the problem! It works just fine on my PC, with ZP, too! I can do Alt+Enter with ZP8RC3 all day here without any problems.

Feature Request:
Not really critical, but it may be 'nice to have' an additional OSD parameter that controls the alpha value of the entire OSD, for example, If I wanted to make the OSD dynamically translucent.
I wish you would have had this idea before I finalized the OSD interface! I don't want to break compatability now. My suggestion would be that you change from color keying to full alpha channels. It's not that hard to do (not in Delphi, either), and would allow you to do whatever you want, per pixel.

Still crashes.
Argh. Ok, here's the next try:

http://madshi.net/madVR70special2.zip

It will probably still crash (I guess), but if you can create another log, that might tell me more. I've added some logging specific to this crash. FWIW, on my PC there's no crash, DVD playback with the NVidia PureVideo Decoder works just fine here.

[racerxnet]

Can the 3 of you please test whether these 3 problems are fixed in this special build?


I still cannot insert a DVD and have it play with the internal decoders or Nvidia decoders. Tried several different configurations with no luck. NVdec.ax fault nag after inserting disc with MPC-HC.

Special build .70
Win XP SP3
Nvidia decoders - No good
Arcsoft decoders - No good
Internal filters - No good

Thanks,

MAK :thanks:

[agustin9]

Can the 3 of you please test whether these 3 problems are fixed in this special build?

My pause problem is gone in both special versions! Thanks!

[Blight]

But in paused state the OSD reacts much faster, correct?
I think so, but I'm not 100% certain, it's hard to tell.
You can see the update frequency is much slower than it should be (even when paused).

Holding the left mouse button over the timeline and dragging it left/right (which updates the timeline graphics very quickly).
What happens is that the player based UI updates multiple times per second and the MadVR OSD updates much slower.

I've ran a few tests and GPU-Z is reporting 5% GPU load, so I don't think that's the problem.
checking the task manager, the CPU gets maxed, but it gets maxed when doing these crazy seeks even without the OSD visible.

I also had one beta tester report decreased play smoothness when playing an 1080p clip at full resolution when the control bar is visible.


The problem is that I have to balance what is more important: (1) Smooth playback with no frame drops? Or (2) fast reacting OSD? Of course I could force a redraw of the next displayed frame to already include your modified OSD image, but that would require me to trash all pre-rendered frames (practically clear the rendering and backbuffer queues completely) and redo all the rendering work. I fear this might introduce a few frame drops once in a while. Maybe a compromise would make sense? E.g. instead of fully flushing the rendering queue, maybe I could only flush half of it? Or something like that? It's really not a problem getting the OSD to become quick. The only problem is that doing so might result in frame drops whenever the OSD changes...

As it happens with seeks, doesn't the buffer get cleared instantly?
Perhaps it can be a parameter that passes with the OSD? For example, if I'm working with menus, I want them to be responsive and don't care (as much) if a frame in the background is dropped.



If only I could reproduce the problem! It works just fine on my PC, with ZP, too! I can do Alt+Enter with ZP8RC3 all day here without any problems.

I created two log files (http://t.inmatrix.com/madvr_altenterlog.rar).
What I've done is very simple:
1. I disabled ZP's keyboard handling entirely.
2. I opened a simple AVI+XVID+MP3 video file and paused it after 1-2 seconds.
3. With "madVR - log_alt-enter.txt", I pressed Alt-Enter and then Alt+F4.
With "madVR - log.txt", I simply closed the player through the GUI.

Since I disabled keyboard handling in ZP, the log files should be pretty much identical, but I suspect they're not.
See if you can possibly find the cause.


I wish you would have had this idea before I finalized the OSD interface! I don't want to break compatability now. My suggestion would be that you change from color keying to full alpha channels. It's not that hard to do (not in Delphi, either), and would allow you to do whatever you want, per pixel.

I can, but it's probably much faster to do it with a Shader.
Is the OSD interface locked-down?, is something using it other than ZP at the moment?
If the answer is 'no' then it's ok to change as there's no public beta of ZP that's capable of using the interface.

[Gleb Egorych]

With 0.70 crashes on Zoom (http://forum.doom9.org/showthread.php?p=1509618#post1509618) are back.

[cyberbeing]

http://madshi.net/madVR70special2.zip

It will probably still crash (I guess), but if you can create another log, that might tell me more. I've added some logging specific to this crash. FWIW, on my PC there's no crash, DVD playback with the NVidia PureVideo Decoder works just fine here.
Yep it still crashes. As I mentioned previously, it only crashes with encrypted DVDs from the DVD drive. Unencrypted DVDs work fine from both the DVD drive and ripped to ISO. If you can't reproduce the crash, could you reproduce corruption problem (frame split half-way down vertically, distorted video on top, green bar on bottom) with 0.67?

0.70 Special2 MPC-HC Log: http://www.mediafire.com/?mxu7y9mkatr4ucz

Edit: Interestingly it works with a ZoomPlayer 7 Smart Graph if I leave it alone for a couple minutes:
0.70 Special2 Working ZoomPlayer Log: http://www.mediafire.com/?hbn7zo0bo96860u

Edit2: Or not... I tried it again and ZoomPlayer 7 hung:
0.70 Special2 Hung ZoomPlayer Log: http://www.mediafire.com/?lm1qsb9q338wmsu

Edit3: And then it worked again in ZoomPlayer, and then it hung again <_<. Since the media player seems to play a part (or more likely just graph building), are you using a special MPC-HC build?

[Blight]

More bug reports:
1. If I blank secondary monitors by creating a black window with no border on monitors where the video isn't shown, MadVR will exit exclusive mode for a split section and then return with MadVR's 'exclusive mode' OSD appearing.
The weird thing is, I don't even have to show or position the blanking window for this to happen.
All I need to do is create a form with the player window as the owner (not parent).

procedure BlankSecondaryMonitors;
var
I : Integer;
tmpForm : TForm;
begin
If Screen.MonitorCount > 1 then
Begin
If Assigned(MonitorBlankList) then MonitorBlankList.Free;
MonitorBlankList := TList.Create;
For I := 0 to Screen.MonitorCount-1 do If Screen.Monitors[I].Handle <> MainForm.Monitor.Handle then
Begin
tmpForm := TForm.Create(MainForm);
{tmpForm.OnKeyDown := MainForm.OnKeyDown;
tmpForm.Color := OPBGColor;
tmpForm.BorderStyle := bsNone;
tmpForm.DefaultMonitor := dmDeskTop;
tmpForm.Cursor := crNone;
tmpForm.SetBounds(Screen.Monitors[I].Left,Screen.Monitors[I].Top,Screen.Monitors[I].Width,Screen.Monitors[I].Height);
tmpForm.Show;}
MonitorBlankList.Add(tmpForm);
End;
//ForceForeground(MainForm.Handle);
End;
end;

As you can see from the code, even when I commented out almost everything, it still causes the glitch.

2. I still get freezes/crashes when switching between 'windowed on monitor 1' to 'fullscreen on monitor 2' if 'auto exclusive mode' and 'use dx11 path' are enabled.

3. If 'auto exclusive mode' is enabled, switching between 'windowed on monitor 1' to 'fullscreen on monitor 2' causes the exclusive mode image to take longer and longer to reappear (the screen stays black for up to 13 seconds after 10-15 switches).

4. My 'stop function causes the OSD to remain on-screen until a play command is issued.
My stop function works like this:
1. Call graph stop.
2. Seek to position '0'.
3. Call graph pause (to show the first video frame).

[Hypernova]

madshi, 0.70special (1) does not crash. I didn't tried 2. :thanks:

[nuhi]

madshi, [issue resolved] don't know if it is intentional or even known about but some 16:9 videos with black bar are zoomed in on madvr. One can see the difference by using Ffdshow's resize to 1080p and enabling it back and forth. Only some videos, let me know if you would like a sample, maybe you already know about this, but then it would be nice if it is optional.

Second just a suggestion; to have a volume bar in exclusive mode. I keep on scrolling up blindly to be sure the volume is to the max, can't see it.

Thanks!

[agustin9]

Second just a suggestion; to have a volume bar in exclusive mode. I keep on scrolling up blindly to be sure the volume is to the max, can't see it.

The volume level is shown at the OSD, that way you can tell if it's maxed or not.

[nuhi]

The volume level is shown at the OSD, that way you can tell if it's maxed or not.

agustin9, thanks but I must be blind, can't see any OSD and I enabled it in the MPC options, can you maybe recall what I could be missing?

madshi, excuse me, I found the cause of my zoom issue while playing with OSD settings; it is MPC feature (Zoom 2 was selected), obviously Ffdshow pre-resized output does not fall under that processing as the picture is already max size.
So all good, thanks once again.

[dansrfe]

My main issue is still with the smoothness of switching monitors and going back into FSE mode. The delay and laggy-ness of the transition is not completely flawless.

[agustin9]

agustin9, thanks but I must be blind, can't see any OSD and I enabled it in the MPC options, can you maybe recall what I could be missing?

Try installing the latest directx version from here:
http://filehippo.com/download_directx/

[Plutotype]

testing 0.70 ( original, not special ones ) and have couple of questions:

Is it possible that using ffdshow video as external filter for VC-1/H.264/MPEG-2 could produce some audio video sync issues with versions since 0.67 ( madVR internal video decoders implemented )?

Why 0.70 has the VC-1 decoder disabled by default? Why H.264/MPEG2 are turned ON by default? Does turning on the decoders and using external one ( ffdshow video ) has any sense in terms of A/V sync issues?

Thanks for the "pause playback until render queue is full" - working nice here.

Thanks

all filters latest + LAVfilters 0.30

[dansrfe]

Why H.264/MPEG2 are turned ON by default?

None of the internal decoders are turned on by default. you may be using your old settings.bin configuration from the previous madVR versions where you might have turned them on.

[andybkma]

Make sure you reactivate the "delay playback" option because it's disabled by default in v0.70.




Ah, unfortunately that doesn't help. Whether the "delay playback" option is on or off I still get the slight jugger at video playback start. I see no noticeable difference at all when ticking this option or not when using Zoom Player or PotPlayer in Windows 7. Ah well, just something to live with I guess...

[fairchild]

@dansrfe if you look at the notes for 0.70, there actually are decoders enabled by default now. I just disabled them though since I like running yadif deinterlacer for interlaced vids.

[VFR maniac]

v0.70 breaks playback of fullrange source, it plays greenly.
v0.69 works fine.

[dansrfe]

@dansrfe if you look at the notes for 0.70, there actually are decoders enabled by default now. I just disabled them though since I like running yadif deinterlacer for interlaced vids.

You may be correct actually. I just replace all the files in my madVR folder and the settings.bin file remains. That may the reason why the internal decoder options are still deselected for me.

[madshi]

I think so, but I'm not 100% certain, it's hard to tell.
You can see the update frequency is much slower than it should be (even when paused).

Holding the left mouse button over the timeline and dragging it left/right (which updates the timeline graphics very quickly).
What happens is that the player based UI updates multiple times per second and the MadVR OSD updates much slower.
The next build will cut down the render queue to 3/8 whenever you ask for an OSD change. This should cut down response times by more than half. Hopefully that will help, let me know.

I created two log files (http://t.inmatrix.com/madvr_altenterlog.rar).
What I've done is very simple:
1. I disabled ZP's keyboard handling entirely.
2. I opened a simple AVI+XVID+MP3 video file and paused it after 1-2 seconds.
3. With "madVR - log_alt-enter.txt", I pressed Alt-Enter and then Alt+F4.
With "madVR - log.txt", I simply closed the player through the GUI.

Since I disabled keyboard handling in ZP, the log files should be pretty much identical, but I suspect they're not.
See if you can possibly find the cause.
That's weird. In your alt-enter log madVR doesn't ever go to fullscreen exclusive mode. Shouldn't it? Anyway, these madVR logs are so big and there's so much information in there, I simply don't know where to look for whatever problem you're experiencing.

From what I can see in the alt-enter log this is what happens:

(1) playback is started and works fine
(2) after 2.5 seconds playback is paused
(3) after 12.5 seconds the connection to madVR is broken and recreated, don't ask me why, this was not initiated by madVR
(4) after 13.0 seconds the rendering queues are filled again
(5) after 24.5 seconds playback is stopped and madVR destroyed

I can't see anything wrong in the OSD, although I don't know why the connection to madVR was broken and recreated.

Is the OSD interface locked-down?, is something using it other than ZP at the moment?
Yes, J.River MediaCenter v16 uses the same API you're using, just with alpha channel images instead of color keyed images.

With 0.70 crashes on Zoom (http://forum.doom9.org/showthread.php?p=1509618#post1509618) are back.
I can't reproduce the crash here, however I can see that ZP's zoom feature doesn't work the way I would expect. I'll talk to Blight about this.

Yep it still crashes. As I mentioned previously, it only crashes with encrypted DVDs from the DVD drive. Unencrypted DVDs work fine from both the DVD drive and ripped to ISO.
Missed the encrypted bit. Can reproduce the crash now. Very weird crash, though. Will have to deactivate some of the auto detection code (primaries, decoding matrix etc) for external decoders, when DVD playback is running.

1. If I blank secondary monitors by creating a black window with no border on monitors where the video isn't shown, MadVR will exit exclusive mode for a split section and then return with MadVR's 'exclusive mode' OSD appearing.
The weird thing is, I don't even have to show or position the blanking window for this to happen.
All I need to do is create a form with the player window as the owner (not parent).

As you can see from the code, even when I commented out almost everything, it still causes the glitch.
Can I have a madVR log from this situation, please? Thanks.

2. I still get freezes/crashes when switching between 'windowed on monitor 1' to 'fullscreen on monitor 2' if 'auto exclusive mode' and 'use dx11 path' are enabled.
Oh, I didn't check this with "use dx11 path", cause my development PC is XP. Does this also occur with the dx9 path?

3. If 'auto exclusive mode' is enabled, switching between 'windowed on monitor 1' to 'fullscreen on monitor 2' causes the exclusive mode image to take longer and longer to reappear (the screen stays black for up to 13 seconds after 10-15 switches).
I can't reproduce that here. Is that with the dx11 path again? Does the same thing happen with the dx9 path?

4. My 'stop function causes the OSD to remain on-screen until a play command is issued.
My stop function works like this:
1. Call graph stop.
2. Seek to position '0'.
3. Call graph pause (to show the first video frame).
What OSD remains on-screen? Yours or mine? If yours: Did you draw is with a timeout value? Or did you (try to) clear it with a separate API call?

BTW, you can also email me at madshi (at) gmail (dot) com, if you prefer. Might be quicker and less painful communication? I'll leave that for you to decide, though. Doom9 is fine with me, too.

Second just a suggestion; to have a volume bar in exclusive mode. I keep on scrolling up blindly to be sure the volume is to the max, can't see it.
MPC-HC shows the volume in an OSD, if you change it. Other players might not. Anyway, madVR doesn't even know that volume changes, so there's not much I can do about it. It's the media player's job to help you there.

My main issue is still with the smoothness of switching monitors and going back into FSE mode. The delay and laggy-ness of the transition is not completely flawless.
This might be improved in some far away version, but not anytime soon.

testing 0.70 ( original, not special ones ) and have couple of questions:

Is it possible that using ffdshow video as external filter for VC-1/H.264/MPEG-2 could produce some audio video sync issues with versions since 0.67 ( madVR internal video decoders implemented )?
I don't really think so.

Why 0.70 has the VC-1 decoder disabled by default? Why H.264/MPEG2 are turned ON by default?
I've disabled the VC-1 decoder because I consider the Microsoft VC-1 decoder superior to libav/ffmpeg and Intel at the moment. If (and when) that changes, I will modify the default settings accordingly. My h264/MPEG2 decoder implementations should compare well to any other (free) h264/MPEG2 decoders out there, and they seem to be stable now, too, so that's why I enabled them by default. madVR has a rather low merit, though, so madVR's internal decoders shouldn't force themselves upon you. You can still easily prefer external decoders over madVR's internal ones, even if they are enabled.

Does turning on the decoders and using external one ( ffdshow video ) has any sense in terms of A/V sync issues?
No.

Ah, unfortunately that doesn't help. Whether the "delay playback" option is on or off I still get the slight jugger at video playback start. I see no noticeable difference at all when ticking this option or not when using Zoom Player or PotPlayer in Windows 7. Ah well, just something to live with I guess...
It seems to work pretty well here. Can I have a log from when you get frame drops right after playback start?

v0.70 breaks playback of fullrange source, it plays greenly.
v0.69 works fine.
Confirmed. Will be fixed in the next build.

[madshi]

madVR v0.71 released

http://madshi.net/madVR.zip

* for DVD playback start, "delay playback start..." option is now auto disabled
* when OSD changes, render queue is cut down to 3/8 to make OSD more responsive
* when madVR pauses/starts/stops graph, notification message 0xFA17 is sent now
* fixed: crash with NVidia PureVideo MPEG2 Decoder
* fixed: crash with h264 AVI content
* fixed: unpause delay with internal decoders in exclusive mode
* fixed: subtitles disappeared when pausing playback
* fixed: madVR caused "File Source Async" to never be destroyed
* fixed: full range YCbCr input showed a green tint (introduced with v0.70)

[Thunderbolt8]

I've disabled the VC-1 decoder because I consider the Microsoft VC-1 decoder superior to libav/ffmpeg and Intel at the moment.can the microsoft decoder do multithreading as well?

[madshi]

I'm telling the libav/ffmpeg VC-1 decoder to do multithreading, but I don't know if it actually is capable of doing that. In any case, the Microsoft VC-1 decoder is clearly faster on my dual core CPU.

[Thunderbolt8]

same here, but still dont know about the multithreading thing. have requested multithreading for libav VC-1 playback twice or three times during the past years at the ffmpeg forum, but from what I can see at least nothing changed over that time. so last thing I know still is that it only looks like multithreading, because task manager seems to do cpu swapping and this then only looks like as if doing multithreading or something like that.

[cyberbeing]

Sorry for the late report (I originally thought it was a fluke), but madVR 0.70 Special2 introduced a bug with "delay playback start".

Only madVR 0.70 Special2 & 0.71 have the bug. madVR 0.70 & 0.70 Special1 are fine.

When using the refresh rate changer and "delay playback start" is enabled, videos opened paused (after refresh rate change). It happens with any decoder, internal or external, so it's not the same as that other frozen screen bug which you fixed. The good news is if you unpause the video, it appears to play normally. The bad news is occasionally when you close MPC-HC in this inital paused state, madVR will hang (I've been unable to get a log of this so far).

Paused State after Refresh Rate Change - Log: http://www.mediafire.com/?3flc92or4oy54o8

[chogster]

Still no joy for me using HAM with any madVR version newer than 0.57! CPU and GPU loads are average, but I'm experiencing a high rate of dropped frames running 1080p/bluray! Everything seems smooth switching over to the Cyberlink software filter, but CPU usage is obviously much higher.

Was there a significant change within madVR from version 0.58 onwards that could cause conflict with HAM?