madVR - high quality video renderer (GPU assisted)

[andybkma]

In which way does the stopping take longer? Can you describe it in more detail, please? Thanks.

Win7 64bit, Nvidia 306.23 drivers with 640M-LE video card, Zoom Player

It's no biggie but I just thought I should report it in case you were interested. With "Windowed Overlay" enabled, when I press the stop button while playing a vid file in window mode with Zoom Player, the video will pause, the paused image will stay for about a second, then the file will finally close. While in earlier versions pre v83, when I pressed stop the video file would close pretty much instantaneously. When I disable "Windowed Overlay", closing videos is faster than with "Windowed Overlay" enabled but still slower than pre v83.

Was thinking that this is just 1) a by product of the new window overlay feaure and 2) I think you set it up in these new .83 versions for mVR to close slower even with window overlay disabled...

[Nicola]

(prices from froogle)

640: 88$, slow, much too expensive for the speed, not recommended
450: 66$, reasonably good performance, best bang for the buck
550: 101$, faster than 450, but also more expensive
650: 110$, slightly faster than 550, very power efficient

Looking at those prices, if you want to save money, I'd get the 450. If you want more speed, the 550 and 650 both look priced ok. If power consumption is important to you, I'd get the 650.

1GB should be enough, unless you want to upscale to 4K, then maybe 2GB would be worth it. But I guess 4K is too far away for now, so I think 1GB should be good enough.


well, I said nothing about prices cause I'm in EU, and the prices are higher, and just different. I'm interested in the 650... does its power efficiency impact on performances or it's just a smaller die? btw, is it the gtx650 you're talking? I'll have to see if my mobo supports that...
Thanks for the infos

[bjd]

What do you mean :confused:

Was meaning as you can't use a separate device for presentation in XP, there is a chance you will get dropped frames with the new drivers. That is what I am seeing.

[madshi]

With "Windowed Overlay" enabled, when I press the stop button while playing a vid file in window mode with Zoom Player, the video will pause, the paused image will stay for about a second, then the file will finally close.
Are you just talking about when the visible video image goes "black"? Or does the slowness also affect ZoomPlayer itself, e.g. the state of the play/stop buttons etc?

While in earlier versions pre v83, when I pressed stop the video file would close pretty much instantaneously. When I disable "Windowed Overlay", closing videos is faster than with "Windowed Overlay" enabled but still slower than pre v83.

Was thinking that this is just 1) a by product of the new window overlay feaure and 2) I think you set it up in these new .83 versions for mVR to close slower even with window overlay disabled...
v0.83 might close a bit slower. Older versions didn't wait for D3D to be fully closed. v0.83 does wait. This change was necessary to avoid crashes which sometimes occurred with the old behaviour. However, if Overlay is slower than normal windowed mode, that may be something I could improve (not sure).

well, I said nothing about prices cause I'm in EU, and the prices are higher, and just different. I'm interested in the 650... does its power efficiency impact on performances or it's just a smaller die? btw, is it the gtx650 you're talking? I'll have to see if my mobo supports that...
Ok, Euro prices:

640: 77,76 €
450: 80,66 €
550: 93,15 €
650: 91,24 €

In that case I'd go with the 650, I guess. The power efficiency does not affect performance. It just means that the 650 consumes less power while running at the same speed. That results in a cooler GPU, a cooler PC and lower fan noise.

I don't think there is a non-TI 550? At least I didn't find one, I was talking about the 550 Ti.

[CiNcH]

D3D9 Hardware Overlay
Cool. So you have a YUV surface and let your scaler shaders run over them and don't run any RGB conversion inside the renderer?

Would be interesting to see whether this also works with the EVR Mixer (+using the DXVA scaler) and a Custom Presenter component. I have never seen the EVR Mixer outputting anything but RGB...

[ryrynz]

But adding the filename is just *your* wish!


:)


Do the other madVR users share the same wish? Maybe some of them would rather have the video decoder or codec displayed instead of the file name? If all madVR users agree that the file name is the most important thing to show now, then I could add it, but I doubt there will be agreement. I think some users will want information A while others want information B.


Not sure I can get ALL MadVR users to agree but anyone interested in having the filename on the seekbar please let Madshi know, example pic below. Thanks guys.

http://imageshack.us/a/img404/1884/image2xgy.jpg

[Nicola]

mmm, nice prices. You should share your source, online store I found are like 20 euro more minimum... like the same as -number- US prices, just with "euro" instead of "usd"... :(

I suppose that if my mobo doesn't support 3.0 bus, I won't benefit much from the 650? Or do you think I can still use it (the nice 65W are tempting) and have equal performances to the 550?

[madshi]

Cool. So you have a YUV surface and let your scaler shaders run over them and don't run any RGB conversion inside the renderer?
No no. The Overlay is running in RGB. madVR renders RGB, as usual. The key difference is that in normal windowed mode, the pixels have to be copied to the screen, which costs performance and which can result in tearing. When using Overlay, the video pixels are never copied to the screen.

[madshi]

mmm, nice prices. You should share your source, online store I found are like 20 euro more minimum... like the same as -number- US prices, just with "euro" instead of "usd"... :(
http://www.heise.de/preisvergleich/

I suppose that if my mobo doesn't support 3.0 bus, I won't benefit much from the 650? Or do you think I can still use it (the nice 65W are tempting) and have equal performances to the 550?
The 3.0 bus doesn't have much effect, if any at all. The bus does not affect the performance of the 650. Please do a google search for "Geforce 650 review" and look for yourself. The 650 seems to be slightly faster than the 550 Ti, and with almost half the power consumption. Not bad, eh?

[Nicola]

Yes, the gtx650 seems really good, and if bus doesn't affect performance, it's perfect for me, since my mobo (asus M4A87TD-EVO) just has 2.0 x16... btw, .de, so if shipped it'll cost the same to me, lucky thing the 650 has almost same price. If there aren't issues in the review I'm reading, I'll go for that. Thanks again.

[andybkma]

Are you just talking about when the visible video image goes "black"? Or does the slowness also affect ZoomPlayer itself, e.g. the state of the play/stop buttons etc?


v0.83 might close a bit slower. Older versions didn't wait for D3D to be fully closed. v0.83 does wait. This change was necessary to avoid crashes which sometimes occurred with the old behaviour. However, if Overlay is slower than normal windowed mode, that may be something I could improve (not sure).





Edit, Changed answer : Yes, it does affect the Zoom Player control buttons as they move & react much slower with the new overlay area enabled. I see that most clearly now

[madshi]

mVR 83.1 doesn't affect Zoom Player itself, just the slowness of the file closing. But yes, overlay enabled is definitely closing slower than normal windowed mode. Cheers :-)
Still need to know whether it's just the visible video which seems to go away slower, or whether the ZoomPlayer buttons also react slower? Basically I need to know if madVR only updates the video area slower with Overlay enabled, or whether madVR also slows down ZoomPlayer, when closing the file.

[cyberbeing]

With 0.83.1, occasionally I'll briefly see what I assume is a small madVR waiting(?) window pop-up for a split-second in the background while closing MPC-HC from windowed mode. Is that something you added? It flashes on-screen very quickly, so I've yet to get a good look, but I'm thinking it's a waiting dialog similar to one used for 3DLUT creation?

[andybkma]

Still need to know whether it's just the visible video which seems to go away slower, or whether the ZoomPlayer buttons also react slower? Basically I need to know if madVR only updates the video area slower with Overlay enabled, or whether madVR also slows down ZoomPlayer, when closing the file.

Oh okay, now that you phrase it that way I would have to definitely say that it slows down Zoom Player in addition to the video area due to the fact that the control buttons react much slower with overlay enabled.

[madshi]

With 0.83.1, occasionally I'll briefly see what I assume is a small madVR waiting(?) window pop-up for a split-second in the background while closing MPC-HC from windowed mode. Is that something you added? It flashes on-screen very quickly, so I've yet to get a good look, but I'm thinking it's a waiting dialog similar to one used for 3DLUT creation?
Not sure where that's coming from. It could be a crash which madVR tries to analyze but the MPC-HC closedown might stop the crash analyzation before it's complete. Not sure. Can you make a screenshot? It's probably too short for that? What happens if you switch MPC-HC to a different renderer, after having played a video with madVR, and then play another video? In that situation the madVR instance shut be destroyed, too. Maybe if it's a crash we're talking about, it reappears in that situation, and can then be fully analyzed?

Oh okay, now that you phrase it that way I would have to definitely say that it slows down Zoom Player in addition to the video area due to the fact that the control buttons react much slower with overlay enabled.
Ok, thanks. Please try v0.83.2 (soon out in a couple of minutes). If that's not faster then that might just be the way it is.

[jmone]

Just watched a couple of BD's in JRMC using the Intel IGP 3000 with the new Overlay and no issues at all - very very good!

[madshi]

madVR v0.83.2 released

http://madshi.net/madVR.zip

* some more Overlay improvements
Window resizing looks good to me now, probably even better than normal windowed mode. Any big problems left with Overlay mode (other than that it doesn't work for AMD users)?

[ryrynz]

Certainly improved. Still get the black screen on shutdown and playback. Stretching isn't updated in realtime thus a picture of the larger image is shown along with the smaller image overlayed on it when resizing and with fullscreen the window is shown before it goes into fullscreen. I wonder how much of this is driver related..

[Budtz]

And i still have problems with a black screen / freeze. when i switch to another video in the folder. I cant seem to get debugging to work. could any1 try and reporduce this. its fairly simple. go into a folder with several files and switch between them from withing the player

[jmone]

V83.2 looks great on my 2 Monitor Setup (550Ti) with the new Overlay mode. Rock solid queues and when testing resizing it worked fine for me with the only oddity (and I don't care) is that if I position the playback window over the two monitors then the video only shows on one part, the other part is green... but who is going to watch a video like that anyway. Now to kick off the familly to test on the HTPC (IGP 3000).

One thing I don't get is in the options you have two checkboxs to select "enable windowed overlay" and also "enable auto fullscreen exclusive", should this not be a drop down as how can you have both?

[mzso]

Seeing that much of the discussion was about gamma recently I was wondering hot to configure it properly. (Can anyone link to a giude?) Or why isn't it enough to change the monitor settings? This area is kind of misty for me.

Somewhat related: How do I set the display to correct/accurate colours. (without some sort of hardware device which I don't have)

[madshi]

Still get the black screen on shutdown and playback.
Can you describe this in a bit more detail, please?

Stretching isn't updated in realtime thus a picture of the larger image is shown along with the smaller image overlayed on it when resizing
You mean the video is not updated? Or the window is not updated? Which zoom setting are you using? Does the problem only occur when downsizing the video window or also when upsizing? It's too bad that screenshots don't work with Overlay. It would be so much easier for me to understand what you mean with a screenshot... :o

and with fullscreen the window is shown before it goes into fullscreen.
What do you mean? Can you describe it in more detail, please?

So 3 issues? Are we just talking about minor cosmetical issues? Or bigger problems? How does that compare to standard windowed mode? How can I reproduce these problems?

And i still have problems with a black screen / freeze. when i switch to another video in the folder. I cant seem to get debugging to work. could any1 try and reporduce this. its fairly simple. go into a folder with several files and switch between them from withing the player
That works just fine here. Are you using NVidia or Intel? You sure you updated to v0.83.2?

One thing I don't get is in the options you have two checkboxs to select "enable windowed overlay" and also "enable auto fullscreen exclusive", should this not be a drop down as how can you have both?
Overlay covers both windowed and fullscreen playback. Fullscreen exclusive mode works only in fullscreen playback. Personally, I'm using fullscreen exclusive mode for fullscreen playback and Overlay mode if the media player doesn't cover the whole screen. Works just fine in this combination, so both options are independent of each other.

[cyberbeing]

I'll see if I can catch a screenshot of it.

It seems like it says something like "Please wait while"

Edit: After about 50 tries I got it... It doesn't say anything useful though.
http://imageshack.us/a/img836/9555/pleasewait.png

Edit2: I'm unable to reproduce it when changing renderers before I switch files as you suggested. Should I make a debug log, or would it not show anything meaningful? From what I can tell, that madVR dialog box doesn't have a chance of appearing until the MPC-HC window has completely disappeared after being closed.

[Blight]

Here's some issues myself and the team encountered with v0.83.2:

Tried the new overlay mode on an NVIDIA GT520, checked debugging mode, overlay is a "+".
1. Resizing is much smoother compared to 0.83.1.
2. Enabling overlay mode when a video is playing resulted in a black screen until the video was reloaded (and graph re-created).
3. When switch the video from fullscreen on monitor 2 to windowed on monitor 1 (both FSE and Overlay checkboxes enabled), playback pauses. I think some red text appears for a split second before the image returns with the video paused.
4. It takes longer to clear the graph (About 1 second longer than v0.82.5), which appears as a black screen between track or just a black screen before ZP is closed. I didn't see any affect on the GUI responsiveness compared to 0.82.5, but I have only tested for a few minutes so far.

[ryrynz]

Can you describe this in a bit more detail, please?

My entire screen goes black, doesn't do that on my HD4000 though only the HD3000. Will need more testing (I'll look into it later)

The other issues (resizing (slow refresh), moving whilst paused and going fullscreen) are here in these videos (http://www.mediafire.com/download.php?1cj2rum89z7c075). Screen capturing wouldn't pick up any of them.

The fullscreen issue is a minor nitpick (small blank window at the top left hand corner before maximize) The videos were done on the HD4000.


Are we just talking about minor cosmetical issues?

Yup.

[Budtz]

[QUOTE=madshi;That works just fine here. Are you using NVidia or Intel? You sure you updated to v0.83.2?[/QUOTE]


Yes im sure im using 83.2. it has worked flawlessly for many months untill now where i get a black screen and hang every time i switch video.

using nvidia gt570 card. any chance for a testbuild with the old code maybe as it was before with the old shutdown behaviou maybe?

[cyberbeing]

@Budtz

If it only happens with fullscreen exclusive mode, it's probably the same issue I reported. Freeze with black screen 100% of the time when switching or reloading videos in fullscreen exclusive mode.

[Budtz]

@Budtz

It it only happens with fullscreen exclusive mode, it's probably the same issue I reported. Freeze with black screen 100% of the time when switching or reloading videos in fullscreen exclusive mode.

yes excactly. thats the problem im experiancing

[THX-UltraII]

Most importantly: madVR now supports using "Overlay" for windowed mode (requires Windows 7 or 8). This has several benefits and a few disadvantages:

+ seems to work around the levels problems with NVidia driversMad, does this mean that I can now just install the latest Nvidia driver without the need to alter the .inf file at driver installation?

[madshi]

Edit: After about 50 tries I got it... It doesn't say anything useful though.
That looks like a crash report in the making. Here's a special build which blocks the media player from closing down:

http://madshi.net/madVRpreventClose.rar

You'll have to manually terminate the media player with the task manager with this build. Maybe this build allows the exception report to be properly created?

2. Enabling overlay mode when a video is playing resulted in a black screen until the video was reloaded (and graph re-created).
That's weird, it doesn't happen for me. I'll try a couple of times, maybe I can reproduce it then. But it might help if you could create a madVR debug log from this situation.

Do you have Aero enabled or disabled? I've yet to try with Aero on. Maybe that's the difference...

3. When switch the video from fullscreen on monitor 2 to windowed on monitor 1 (both FSE and Overlay checkboxes enabled), playback pauses. I think some red text appears for a split second before the image returns with the video paused.
Could you create a debug log for this, too? Unfortunately my NVidia PC only has one monitor. And my PC with 2 monitors has an AMD card, so I currently can't test Overlay with 2 monitors. It's really sad that AMD drivers don't support Overlay mode at all... :(

4. It takes longer to clear the graph (About 1 second longer than v0.82.5), which appears as a black screen between track or just a black screen before ZP is closed. I didn't see any affect on the GUI responsiveness compared to 0.82.5, but I have only tested for a few minutes so far.
This is not specific to Overlay, I guess? I've changed the madVR shutdown behaviour in order to prevent random shutdown crashes - which were rare, but did occur. Now I'm waiting for D3D to fully close down before leaving the madVR destructor. I didn't wait for D3D in older versions. This will probably slow down madVR destroying a bit. But it should be good for stability. If you're worried about fast ZP closing, you could just call ExitProcess without destroying the madVR instance. Not nice, but it should work, I think. If you destroy and recreate madVR when switching files, not sure how to speed things up there. The new madVR build should be ok with you creating a new madVR instance while the old one is still alive (unlike older madVR builds). So maybe you could destroy the old madVR instance in a background thread while already creating the new one? The problem with this is that if the old instance has fullscreen exclusive mode, the new instance won't be able to go exclusive as long as the old instance hasn't left exclusive mode yet.

My entire screen goes black, doesn't do that on my HD4000 though only the HD3000. Will need more testing (I'll look into it later)

The other issues (resizing (slow refresh), moving whilst paused and going fullscreen) are here in these videos (http://www.mediafire.com/download.php?1cj2rum89z7c075). Screen capturing wouldn't pick up any of them.
Thanks for those videos - quite helpful! I think it might have to do with Aero. You have it enabled, correct? I've been testing with it disabled. Will try to enable it here...

Yes im sure im using 83.2. it has worked flawlessly for many months untill now where i get a black screen and hang every time i switch video.

using nvidia gt570 card. any chance for a testbuild with the old code maybe as it was before with the old shutdown behaviou maybe?
Ah, I see, you're talking about fullscreen exclusive mode, correct? I thought you were talking about Overlay mode. The FSE freeze is a totally different problem and has nothing to do with Overlay. I believe the freeze is a bug in MPC-HC and a new MPC-HC build should be able to fix it. I've already posted in the MPC-HC and MPC-BE threads about this freeze problem.

Unfortunately I can't go back to the previous shutdown behaviour. Due to the changes I did to support multiple madVR instances at the same time, when I go back to the old behaviour, there would be an instant crash now. The old behaviour was really bad, it was pure luck that it worked at all.

[madshi]

Mad, does this mean that I can now just install the latest Nvidia driver without the need to alter the displaydriver.inf file?
When using Overlay mode, I think yes. Although applying the levels fix might still make sense, e.g. for desktop and games etc. But you don't have to alter inf files, anymore, anyway. Just use the "madNvLevelsTweaker.exe" tool shipping with madVR, after you've installed a new driver.

[THX-UltraII]

When using Overlay mode, I think yes. Although applying the levels fix might still make sense, e.g. for desktop and games etc. But you don't have to alter inf files, anymore, anyway. Just use the "madNvLevelsTweaker.exe" tool shipping with madVR, after you've installed a new driver.Changing the .inf file at installation prevents the need of running another (even though very very tiny :)) application. :D

Going to test the new version tonight with MPC-HC and JRIVER MC17 with GTX460 with latest driver.

[madshi]

Yes im sure im using 83.2. it has worked flawlessly for many months untill now where i get a black screen and hang every time i switch video.

using nvidia gt570 card. any chance for a testbuild with the old code maybe as it was before with the old shutdown behaviou maybe?
P.S: It might still be interesting for me to get a new madVR debug log from the v0.83.2 about this freeze. In order to create such a debug log, just double click "activate debug mode.bat", then start the media player and let the freeze occur. Afterwards you should have a "madVR - log.txt" file on your desktop.

[Budtz]

a bug in mpc-hc? but i had my setup working for 6 months flawlessly through several mpc-hc builds. i havnt changed it but wheni changed to the new version of madvr i got the error.

[cyberbeing]

That special build allowed the crash report. When I attempted to send you the crash report I got an error that it failed to send, so I've taken screenshots instead.

http://img543.imageshack.us/img543/2338/crash1.th.png (http://imageshack.us/a/img543/2338/crash1.png)http://img19.imageshack.us/img19/7365/crash2.th.png (http://imageshack.us/a/img19/7365/crash2.png)http://img856.imageshack.us/img856/2835/crash3.th.png (http://imageshack.us/a/img856/2835/crash3.png)http://img443.imageshack.us/img443/6012/crash4.th.png (http://imageshack.us/a/img443/6012/crash4.png)http://img577.imageshack.us/img577/7797/crash5.th.png (http://imageshack.us/a/img577/7797/crash5.png)

[madshi]

a bug in mpc-hc? but i had my setup working for 6 months flawlessly through several mpc-hc builds. i havnt changed it but wheni changed to the new version of madvr i got the error.
So? Software development is a complex thing. madVR behaviour has changed and that's why the freeze occurs now and didn't occur in the previous build. But the real bug is still in MPC-HC, from what I can see.

[Budtz]

P.S: It might still be interesting for me to get a new madVR debug log from the v0.83.2 about this freeze. In order to create such a debug log, just double click "activate debug mode.bat", then start the media player and let the freeze occur. Afterwards you should have a "madVR - log.txt" file on your desktop.

ok heres the log

[madshi]

That special build allowed the crash report. When I attempted to send you the crash report I got an error that it failed to send, so I've taken screenshots instead.
Thanks. Next time you can just press Ctrl+C and then the bug report will be in the clipboard as a text file. Or just press the "close application" button and the crash report should be stored to your desktop. Of course screenshots are fine, too, just more work for you than necessary...

Is the problem fixed with this test build?

http://madshi.net/madVRcyberTest.rar

[madshi]

ok heres the log
Thanks, I'll look at it once the attachment gets approved (which can be fast or take ages, depending on luck). If you don't want to wait, upload it somewhere else.

[cyberbeing]

Is the problem fixed with this test build?
No, it still produces that dialog for a split second.

Here is a debug log (http://www.mediafire.com/?ebw5x4pdddtrdrv) from that build.

[Budtz]

Thanks, I'll look at it once the attachment gets approved (which can be fast or take ages, depending on luck). If you don't want to wait, upload it somewhere else.

http://www.mediafire.com/view/?w06in3xp4tg5lyy

here i think

[SamKook]

It stays that way forever? Or does it just take a long time (how long?) to resize properly?

It stays that way forever. I'm guessing it doesn't have enough time to process the previous command it receives so it simply forgets about it and goes back to its previous state since I can see it starting to resize, but it goes back to it's original size and then tries the next resize command.

I wanted to make a video to show you since it's a bit hard to explain but my capture software decided to not cooperate.

Anyway, v83.2 is a bit better. Now only half of the resize is ignored which means it's almost as fast as without it but not quite.

Manually resizing it looks much better now too since the picture doesn't alternate between black and the actual picture anymore.

[noee]

It's really sad that AMD drivers don't support Overlay mode at all...

Do you have a reliable contact to report this to? If not, we can log an issue with them thru their support....fwiw.

[Shii]

Noticed trouble with latest madVR build. Using Zoom Player 8.16. First, set action for left mouse button click in media mode to "Move Window" (Options/Interface/Mouse)
When I press left mouse button, zoom player jumps to left top corner of the screen. When I move mouse with LMB pressed - player returns to it`s initial position. So, with this bug double clicking video (for start/stop) seems impossible - player just jumps away.

[Jong]

In the AVS 5000 series thread there was a bug discovered in the RGB-YCbCr conversion, when output was set to YCbCr, where there was a greenish tint in the blacks. When using protected video path players and content (basically just bluray and TMT/PDVD), this bug was bypassed, and it was suspected the players were using overlay because of this. I'll test this with my 4670, but I don't have my 5770 anymore.Wow, yes, so many years ago that we first uncovered this "EVR onto an overlay surface" used by TMT/PDVD that initially some didn't even believe existed :). Good to see it finally coming into its own outside of the commercial players.

( I was pleased to see the green tint converting to RGB to YCbCr was fixed when I upgraded to a 7750 some months back)

No no. The Overlay is running in RGB. madVR renders RGB, as usual. The key difference is that in normal windowed mode, the pixels have to be copied to the screen, which costs performance and which can result in tearing. When using Overlay, the video pixels are never copied to the screen. From the above old AMD problem it does seem that IF the overlay is used in YCbCr mode it is possible to move video to a display without ever passing through an RGB conversion. And it does still seem that displays are more optimised for YCbCr, since this is what they will typically receive from broadcast and STB sources and it is easier for them to do their post processing that way. It is even thought that some displays probably convert RGB back to YCbCr for processing before then, finally, doing their own RGB conversion at the very end.

Is it impossible or otherwise undesirable for MadVR to be able to work in YCbCr when YCbCr 4:4:4 is used as the output pixel format? Maybe you think it is just unnecessary or not worth the effort.

madVR v0.83 released

+ should have no tearing (I think)
+ performs noticeably better than standard windowed mode
+ seems to work around the levels problems with NVidia drivers
- resizing the media player window looks ugly
- only one player (instance) can use overlay at a time
- I'm not sure yet whether the GPU driver leaves the video untouchedOne problem with the commercial players is their lack of stability. Any minor competition for resources seems to be able to cause judder.

From discussion long ago here and elsewhere (and sorry if my use of terminology is lax!), FSE seems to help considerably in giving the renderer/presenter more room to play - more of the frame period to do what it needs to do. While I trust you totally to get this stuff right, can you confirm that moving away from FSE will not make required timings for MadVR similarly tougher and hence more susceptible to potential judder?

[Andy o]

I'm not sure that people didn't believe it, as much as people just didn't care much cause they run RGB anyway. What I don't remember is if this fix also was available to Vista and XP users.

[Jong]

I'm not sure that people didn't believe it, as much as people just didn't care much cause they run RGB anyway. What I don't remember is if this fix also was available to Vista and XP users.It was doubted. It was first noticed some time before the 5xxx problem, when Reclock reported "EVR" but it was impossible to capture screenshots. People were sure TMT/PDVD were using "conventional" overlay and thought Reclock had it wrong.

[madshi]

No, it still produces that dialog for a split second.
Ok, here's the next try:

http://madshi.net/madVRcyber2.rar

The problem might be fixed, not sure. If not, you should get a crash report again (media player will be stuck again). Please send me the crash report *and* a debug log from the same situation then. Thanks!

http://www.mediafire.com/view/?w06in3xp4tg5lyy

here i think
Thanks. Found something interesting in there which *may* help. I have my doubts, but here's a test build:

http://madshi.net/madVRbudtz.rar

Is the freeze gone for you with this build? Probably not, but worth a try...

It stays that way forever. I'm guessing it doesn't have enough time to process the previous command it receives so it simply forgets about it and goes back to its previous state since I can see it starting to resize, but it goes back to it's original size and then tries the next resize command.
Ok, I see. I don't think there's much I can do to speed things up. Maybe you could try increasing the 10ms delays to something higher? Not sure what else to suggest...

Do you have a reliable contact to report this to? If not, we can log an issue with them thru their support....fwiw.
I don't have a reliable contact at all, unfortunately. With none of the GPU companies.

Noticed trouble with latest madVR build. Using Zoom Player 8.16. First, set action for left mouse button click in media mode to "Move Window" (Options/Interface/Mouse)
When I press left mouse button, zoom player jumps to left top corner of the screen. When I move mouse with LMB pressed - player returns to it`s initial position. So, with this bug double clicking video (for start/stop) seems impossible - player just jumps away.
I remember this problem from some time ago. It was a bug in an old ZP version and got fixed a long time ago. I don't think this is likely to be a madVR bug. But Blight would have to comment on that?

Wow, yes, so many years ago that we first uncovered this "EVR onto an overlay surface" used by TMT/PDVD that initially some didn't even believe existed :). Good to see it finally coming into its own outside of the commercial players.
Was Windows 7 available by that time? I'm asking because this feature was introduced in Windows 7. There's Overlay for older OSs, too, but you can't directly access it from D3D9, from what I can see.

From the above old AMD problem it does seem that IF the overlay is used in YCbCr mode it is possible to move video to a display without ever passing through an RGB conversion.
FWIW, AMD does currently not support the new Windows 7 Overlay mode at all.

And it does still seem that displays are more optimised for YCbCr, since this is what they will typically receive from broadcast and STB sources and it is easier for them to do their post processing that way. It is even thought that some displays probably convert RGB back to YCbCr for processing before then, finally, doing their own RGB conversion at the very end.
The problem is that every display is different. I've also heard a lot of stories about projectors which you should better feed with RGB because otherwise there will be all kinds of color decoding or chroma upsampling problems.

Is it impossible or otherwise undesirable for MadVR to be able to work in YCbCr when YCbCr 4:4:4 is used as the output pixel format? Maybe you think it is just unnecessary or not worth the effort.
First of all we'd have to know for sure that untouched YCbCr 4:4:4 output is possible by using Overlay. Next, it would have to work with both AMD and NVidia, to make it worth the effort. Finally:

One problem with the commercial players is their lack of stability. Any minor competition for resources seems to be able to cause judder.

From discussion long ago here and elsewhere (and sorry if my use of terminology is lax!), FSE seems to help considerably in giving the renderer/presenter more room to play - more of the frame period to do what it needs to do. While I trust you totally to get this stuff right, can you confirm that moving away from FSE will not make required timings for MadVR similarly tougher and hence more susceptible to potential judder?
I'm not moving away from FSE at all. Overlay mode is not really meant (by me) to replace FSE. It's meant to replace conventional windowed mode. Personally, I'll stay with FSE for fullscreen movie playback because it is more likely to produce stable and smooth output.

Technically, with Overlay, I can present one frame in advance. So if there's some timing glitch (maybe the CPU is busy doing something else), a frame drop could occur. With FSE mode, if you prepresent multiple frames in advance, there should be no frame drop, even if the CPU is busy for a relatively long time.

-------

FWIW, I've done some more tests with Overlay and I've found that unfortunately Overlay mode and FSE mode don't fully like each other too much. Switching a playing video between Overlay <-> FSE mode sometimes results in FSE showing just a dark colored surface. This seems to be an NVidia driver bug. You can work around it by pausing the video before switching to FSE mode. That works most of the time.

Also, I've found that enabling Overlay on the fly doesn't work, either. For some reason a media player restart is necessary. Once again, it's not madVR's fault, but the fault of the GPU driver.

[Budtz]

Thanks. Found something interesting in there which *may* help. I have my doubts, but here's a test build:

http://madshi.net/madVRbudtz.rar

Is the freeze gone for you with this build? Probably not, but worth a try...




It seems to be working. i tried 20 switches now in FSE mode. seems to be working now:)

[madshi]

Wow, I'm surprised! Well, it's an ugly hack, I've practically blocked some things Direct3D did during finalization to avoid the freeze. Now I've got to find a way to make this hack work without negative side effects.