madVR - high quality video renderer (GPU assisted) [Archive] - Page 113

cyberbeing

19th February 2011, 18:12

I disagree. Changing the video refresh rate is naturally the duty of the video renderer. Anything else makes no sense. Having the audio renderer change the video refresh rate behind the back of the video renderer makes as much sense as having the video renderer change the audio DAC sample rate behind the back of the audio renderer.
Yet that is exactly what Reclock does, and it's been proven to work acceptably. Reclock changes the video frame-rate to match the refresh rate and resamples the audio behind the video renderer's back. By the same argument, an audio renderer is beyond the scope of madVR (madshi video renderer).

I'm unsure what you're trying to say. Does this mean you now plan to code an audio renderer (madAR?) which replaces the functionaly which Reclock provides? How else would madVR change the video framerate and keep A/V sync, without the audio being resampled or timestreched?

madshi

19th February 2011, 18:47

The green and red curve allow to see if I have judder or not in the video (synchronization with refresh rate of my monitor). If red and green curves are parallels I have no judder and video is smooth, ifnot it is not smooth.
I think a "dropped" and "repeated" frames counter is much more useful than these graphs. madVR does not count "repeated" frames yet, though.

Although with your render, I can't see if I have judder or not.
In a good or bad way?

Yeah those are not really documented well. But if you catch one, you'll know, its obvious degredation, mostly showing as blocking.
Ah, ok, thanks.

Tell me if this answers anything...
Not really. I know all the deinterlacing algorithms and which is better than which. I'm just not sure if ATI/NVidia do real motion compensated deinterlacing or not.

Yet that is exactly what Reclock does, and it's been proven to work acceptably. Reclock changes the video frame-rate to match the refresh rate and resamples the audio behind the video renderer's back.
Yes, that's how Reclock works. I don't consider it a good solution.

By the same argument, an audio renderer is beyond the scope of madVR (madshi video renderer).
Very true.

I'm unsure what you're trying to say.
I'm trying to look at things with "fresh eyes", forgetting bad concepts of the past. The natural task of an audio renderer is to render audio, and the natural task of a video renderer is to render video. The audio renderer should leave the video renderer alone and vice versa. Both renderers should do their best to achieve perfect playback on their own. Only this way we can get perfect audio + video quality.

Let me give you a few reasons of why having the audio renderer change refresh rates doesn't make sense:

(1) The DirectShow chain automatically provides all necessary information to all filters, including the renderers. DirectShow does *not* tell the audio renderer *anything* about video. By relying on DirectShow alone, an audio renderer doesn't even know if the media playback includes video or not. I think that gives a clear hint that Microsoft thinks that the audio renderer should not get its hands dirty with any video stuff.

(2) Consider a dual monitor setup: First monitor LCD computer display. Second monitor a front projector. Many LCD computer displays only support 60Hz. Most front projectors support 60Hz and also 24Hz. So the refresh rage changer ("RRC") needs to behave differently, depending on which monitor the video is played on. That means the RRC practically needs a full monitor setup, which detects monitors and stores supported refresh rates per monitor. Now tell me: Does Reclock recognize different monitors? And does Reclock allow you to configure the automatic refresh rate changing, depending on which monitor video is played on? Does Reclock have a full monitor management to allow all this kind of stuff? Does a full monitor management belong into the settings dialog of an audio renderer?

(3) Consider watching a 1080i60 TV broadcast, which first shows a movie and after that a music concert. You want to watch both. Now the optimal refresh rate for the movie is 24Hz, but the optimal refresh rate for the music concert is 60Hz. Do you honestly think the audio renderer is in a position to switch refresh rates if the type of video content (film <-> video) changes in the middle of playback? The only one who can possibly know this is the deinterlacer, which is usually part of the video renderer.

Does this mean you now plan to code an audio renderer (madAR?) which replaces the functionaly which Reclock provides? How else would madVR change the video framerate and keep A/V sync, without the audio being resampled or timestreched?
You're not going to trick me into revealing my development plans... :) But I can safely say that I have zero plans to develop an audio renderer.

Anyway, even with Reclock in the chain, moving the RRC from Reclock to madVR still makes sense. Reclock will adjust to any refresh rate, anyway. So it doesn't really matter much to Reclock who changes the refresh rate. And madVR already contains a full device manager, which detects different monitors and allows you to change settings on a per monitor base. Once I add refresh rate changing, you will be able to configure it per monitor. Which is the only way it makes sense. And Reclock should be happy with this, too.

mr.duck

19th February 2011, 19:02

Not really. I know all the deinterlacing algorithms and which is better than which. I'm just not sure if ATI/NVidia do real motion compensated deinterlacing or not.
Details are hard to find. What about...

Vector adaptive de-interlacing is far more advanced and uses a much better system to create the 60p frames 1:1 from the 60i source. It does this by analysing the entire image for static and moving content, and tries to create a motion vector for the moving content, to allow the 60p frames to be better reconstructed from the 60i fields. (Some of the best vector-adaptive de-interlacing can deliver VERY good results)
http://www.avsforum.com/avs-vb/showthread.php?t=1112923

Qaq

19th February 2011, 19:02

The natural task of an audio renderer is to render audio, and the natural task of a video renderer is to render video.
I'm confused a bit here. Is networking a natural task of a video renderer also?
...The audio renderer should leave the video renderer alone and vice versa.

ikarad

19th February 2011, 19:07

I think a "dropped" and "repeated" frames counter is much more useful than these graphs. madVR does not count "repeated" frames yet, though.

I see a dropped frame counter with ctrl+J but even with judder the counter doens't increased.

It's not a problem if red and green curves are remplaced by a counter. The most important thingh is that there is something to know if there is judder or not.

In a good or bad way?

I don't know because I don't have red and green curves to know.

I think there is no judder but I would like to confirm with scientific method (red and green curves or counter). For this moment I use evr custom because I know that there is no judder but i would like to use madvr.

cyberbeing

19th February 2011, 19:23

I'm a bit confused with your terminology.

Refresh rate changer ("RRC") = Monitor refresh rate changer
OR
Refresh rate changer ("RRC") = Video frame rate changer

Since Relock doesn't touch the monitor refresh rate, I assume you are talking about video frame rate. Correct? :confused:

It's confusing if you refer to 'video frame rate' as 'video refresh rate' when there is also 'monitor refresh rate'.

pankov

19th February 2011, 20:30

What makes you think the latency is caused by the network stuff? The madVR network is initialized during start time and then it sits idle, doing nothing. IMHO the chance that the madVR network stuff is causing increased DPC latency is pretty much zero.
As I wrote in one of my previous posts LatencyMon reports that the increased latency times that I get when using madVR are caused by NDIS.sys which AFAIK is responsible for network activities so thus I thought it could be the network stuff in madVR.
But don't get me wrong - it's simply a wild guess - it's not something I'm certain of.
I only know that when I use madVR I get higher DPC latency times than when I use EVR.
I have some doubts that it could be something else connected with Interrupts because xperf shows increased interrupts CPU usage but I can't find which driver causes them.
If you are willing to look into it I can provide some traces. I have to admit that all this is beyond my level of knowledge ... at least for the moment.
I've sent them to cyberbeing but I guess he's too busy to deal with my stuff.
All this is much less important for me than the fix for the access violation on jumping to the next file that I've lastly reported here
http://forum.doom9.org/showthread.php?p=1468028#post1468028

madshi

19th February 2011, 20:32

Details are hard to find. What about...

http://www.avsforum.com/avs-vb/showthread.php?t=1112923
Well, it sounds like motion compensated deinterlacing. I'm just not 100% convinced, because that would almost be too good to be true.

I'm confused a bit here.
Agreed.

I'm a bit confused with your terminology.

Refresh rate changer ("RRC") = Monitor refresh rate changer
OR
Refresh rate changer ("RRC") = Video frame rate changer

Since Relock doesn't touch the monitor refresh rate, I assume you are talking about video frame rate. Correct? :confused:

It's confusing if you refer to 'video frame rate' as 'video refresh rate' when there is also 'monitor refresh rate'.
"refresh rate" is a term which is only ever used for the display/GPU. It is never used for movie frame rates. I was always talking about display/GPU refresh rate. I was never talking about movie/source frame rate. If you look back at where the whole discussion started (weeks ago) it was about display refresh rates, not about movie frame rates. So it seems to me now that we never actually disagreed? We just misunderstood each other?

You say Reclock doesn't touch the monitor refresh rate. I thought Reclock has some scripting capability with which users can automatically switch refresh rates via VBS script? Well, maybe I'm wrong, I've never that VBS scripting capability yet.

madshi

19th February 2011, 20:37

As I wrote in one of my previous posts LatencyMon reports that the increased latency times that I get when using madVR are caused by NDIS.sys which AFAIK is responsible for network activities so thus I thought it could be the network stuff in madVR.
But don't get me wrong - it's simply a wild guess - it's not something I'm certain of.
I only know that when I use madVR I get higher DPC latency times than when I use EVR.
I have some doubts that it could be something else connected with Interrupts because xperf shows increased interrupts CPU usage but I can't find which driver causes them.
If you are willing to look into it I can provide some traces. I have to admit that all this is beyond my level of knowledge ... at least for the moment.
Well, as I said: madVR just announces itself on the network in the startup phase. After that, madVR does not do *any* more network stuff. So I don't see how the network stuff could result in DPC latency problems.

All this is much less important for me than the fix for the access violation on jumping to the next file
Don't worry, that's on my to do list.

pankov

19th February 2011, 20:42

:thanks:

mr.duck

19th February 2011, 20:49

Well, it sounds like motion compensated deinterlacing. I'm just not 100% convinced, because that would almost be too good to be true.
The only other thing I am going to add is my own subjective experience. 99% of the video I watch is interlaced. I have a Radeon 5750 using vector adaptive deinterlacing and the results are very impressive. So I think there is still a chance it is not too good to be true because it is difficult to imagine it getting much better.

leeperry

19th February 2011, 21:02

All this is much less important for me than the fix for the access violation on jumping to the next file that I've lastly reported here
http://forum.doom9.org/showthread.php?p=1468028#post1468028
PotPlayer also crashes sometimes when I skip to the next file in seamless playback mode, but drwatsn32 says that it's due to "ffdshow!DllUnregisterServer"...I don't recall ever encountering this problem a few months back. I can provide mVR logs if you think that's related somehow.

nevcairiel

19th February 2011, 21:12

Well, it sounds like motion compensated deinterlacing. I'm just not 100% convinced, because that would almost be too good to be true.

ATIs best deinterlacer is Vector Adaptive, the second best Motion Adaptive. Both produce very good results, Vector Adaptive has some advantages in certain situations, especially with sports tv.

NVIDIA calls their "Spatial-Temporal Deinterlacing", which in quality is similar to ATIs Vector Adaptive deinterlacer.

Sadly i have never seen a comparison of HQV Hardware vs. Software deinterlacing, only ATI vs NVIDIA, or similar - but the resulting images look really good to me.

This article is from 2005, so i bet the quality might have even improved since then, but its one of the best i could find on short notice:
http://www.anandtech.com/show/1809
Especially NVIDIA does very well on most tests there. ATI has since improved alot (and in the latest drivers, NVIDIA has problems with cadence detection with some cards), but they are still very similar otherwise, and doing a fantastic job.

The best part about it is, that at least on NVIDIA (cannot speak about ATI, haven't had one for quite a while), it can also detect telecine and process that properly with IVTX. It doesn't try to treat it as interlaced - without any special configuration necessary, it just works. :D

ikarad

19th February 2011, 21:40

ATIs best deinterlacer is Vector Adaptive, the second best Motion Adaptive. Both produce very good results, Vector Adaptive has some advantages in certain situations, especially with sports tv.

NVIDIA calls their "Spatial-Temporal Deinterlacing", which in quality is similar to ATIs Vector Adaptive deinterlacer.

Sadly i have never seen a comparison of HQV Hardware vs. Software deinterlacing, only ATI vs NVIDIA, or similar - but the resulting images look really good to me.

This article is from 2005, so i bet the quality might have even improved since then, but its one of the best i could find on short notice:
http://www.anandtech.com/show/1809
Especially NVIDIA does very well on most tests there. ATI has since improved alot (and in the latest drivers, NVIDIA has problems with cadence detection with some cards), but they are still very similar otherwise, and doing a fantastic job.

The best part about it is, that at least on NVIDIA (cannot speak about ATI, haven't had one for quite a while), it can also detect IVTC and process that properly. It doesn't try to treat it as interlaced - without any special configuration necessary, it just works. :D
Please, could you explain what are the differences between inverse telecine, "motion adaptive and vector adaptive?

cyberbeing

19th February 2011, 21:43

So it seems to me now that we never actually disagreed? We just misunderstood each other?
Yeah, it's probably my bad for not fully reading the discussion I was replying to. :p

You say Reclock doesn't touch the monitor refresh rate. I thought Reclock has some scripting capability with which users can automatically switch refresh rates via VBS script? Well, maybe I'm wrong, I've never that VBS scripting capability yet.
That also requires Powerstrip I believe, and it's an optional advanced user feature (not default behavior). leeperry is more familiar with it, I'm sure.

I've personally never touched it or needed it, and it's probably the same for most Reclock users.

nevcairiel

19th February 2011, 21:47

Please, could you explain what are the differences between inverse telecine, "motion adaptive and vector adaptive?

Inverse Telecine is not deinterlacing it all. Its for video processed by Telecine (http://en.wikipedia.org/wiki/Telecine), its a process to convert film content into video content.

Motion and Vector Adaptive are two deinterlacing algorithms, which to describe would go out of scope for this post. Vector Adaptive is the better quality, but will also use more performance.

ikarad

19th February 2011, 22:01

Inverse Telecine is not deinterlacing it all. Its for video processed by Telecine (http://en.wikipedia.org/wiki/Telecine), its a process to convert film content into video content.

Motion and Vector Adaptive are two deinterlacing algorithms, which to describe would go out of scope for this post. Vector Adaptive is the better quality, but will also use more performance.

Inverse telecine transform intrelaced movies (30 fps for example) in non entrelaced movies (24 fps for example), not? It's not deinterlacing method? Maybe I misunderstood all.

I use inverse telecine filter for intrelaced japan anime.

If I told wrong things, told me.

madshi

19th February 2011, 22:06

Sadly i have never seen a comparison of HQV Hardware vs. Software deinterlacing, only ATI vs NVIDIA, or similar - but the resulting images look really good to me.
HQV etc hardware does not use motion compensation, which ATI and NVidia seem to use. So ATI/NVidia might actually be better. But I'm not really sure.

The best part about it is, that at least on NVIDIA (cannot speak about ATI, haven't had one for quite a while), it can also detect telecine and process that properly with IVTX. It doesn't try to treat it as interlaced - without any special configuration necessary, it just works. :D
Well, that's how it should be. I guess, though, that the movie framerate still stays at 60Hz for 1080i60 movies, although IVTC is used? I don't think any decoder/renderer currently automatically switches between 24Hz and 60Hz output, depending on whether 1080i60 content is film or video, right?

Yeah, it's probably my bad for not fully reading the discussion I was replying to. :p
Hehe... :)

madshi

19th February 2011, 22:07

madshi, with "delay switch to exclusive mode by 3 seconds" enabled, and "show seek bar" disabled, and when i double click the mpc-hc window to make the window fullscreen, madVR immediately indicates its going to exclusive mode. There is no 3 second delay. Restarting mpc-hc has no effect.

This means that when I actually want to use the mpc-hc seekbar, and when I move the mouse to the bottom of the fullscreen window, the mpc-hc seekbar appears, but madVR seems to go immediately to exclusive fullscreen again. The 3 second delay isn't... well working at all for me. Again not a huge issue but if you want me to try anything let me know and I can do that.
I've worked on the exclusive <-> windowed switch a bit, it should be a bit better in the next build (maybe coming out tomorrow). Please retry with that build and let me know if the problem is still there.

yesgrey

19th February 2011, 23:32

I only know that when I use madVR I get higher DPC latency times than when I use EVR.
Which graphic card do you have? If it's a Nvidia it might be the culprit. The current drivers cause high DPC latency times... I'm currently getting some with my computer. It might be the reason for the lock ups I'm getting with madVR...

pankov

19th February 2011, 23:47

I'm using AMD HD5750 with Catalyst 10.12 drivers so I guess it's not the same issue.
yesgrey, do your high DPC latency times happen only when using madVR or also in other "games" using the 3D engine?

yesgrey

20th February 2011, 00:04

do your high DPC latency times happen only when using madVR or also in other "games" using the 3D engine?
I don't play "games" anymore, only madVR. :D
But the high DPC latency times I'm getting are even with the computer idle. Using madVR does not make it worse when watching something, only when I try right clicking to get the menu and the lockups happen they go wild! :(

Plutotype

20th February 2011, 01:22

[QUOTE=yesgrey;1479284]I don't play "games" anymore, only madVR. :D

:):):)

Mark_A_W

20th February 2011, 07:27

Let me give you a few reasons of why having the audio renderer change refresh rates doesn't make sense:

(1) The DirectShow chain automatically provides all necessary information to all filters, including the renderers. DirectShow does *not* tell the audio renderer *anything* about video. By relying on DirectShow alone, an audio renderer doesn't even know if the media playback includes video or not. I think that gives a clear hint that Microsoft thinks that the audio renderer should not get its hands dirty with any video stuff.

(2) Consider a dual monitor setup: First monitor LCD computer display. Second monitor a front projector. Many LCD computer displays only support 60Hz. Most front projectors support 60Hz and also 24Hz. So the refresh rage changer ("RRC") needs to behave differently, depending on which monitor the video is played on. That means the RRC practically needs a full monitor setup, which detects monitors and stores supported refresh rates per monitor. Now tell me: Does Reclock recognize different monitors? And does Reclock allow you to configure the automatic refresh rate changing, depending on which monitor video is played on? Does Reclock have a full monitor management to allow all this kind of stuff? Does a full monitor management belong into the settings dialog of an audio renderer?

(3) Consider watching a 1080i60 TV broadcast, which first shows a movie and after that a music concert. You want to watch both. Now the optimal refresh rate for the movie is 24Hz, but the optimal refresh rate for the music concert is 60Hz. Do you honestly think the audio renderer is in a position to switch refresh rates if the type of video content (film <-> video) changes in the middle of playback? The only one who can possibly know this is the deinterlacer, which is usually part of the video renderer.

1. I don't disagree with what you are saying at all...but:

2. Actually, the answer to most of that is yes. Reclock does detect monitors. You can force it it, or let it choose automatically.
It will change refresh rate when coupled with Powerstrip.

It might not be the best place for all this stuff, but most of what you stated is in place.

3. Reclock manages, by hook or by crook. But it's not perfect. Sometimes I get literally perfect playback. Other times I don't - I don't know why, it's not repeatable. However I'm not using exclusive (it won't work for an interlaced res).

Feel free to make it all perfect :) I'll buy you a beer - I've already offered more than once!

madshi

20th February 2011, 09:03

Actually, the answer to most of that is yes. Reclock does detect monitors. You can force it it, or let it choose automatically.
It will change refresh rate when coupled with Powerstrip.
But does it allow you to specify different refresh rate change settings for different detected monitors? If so, that would be news to me.

Feel free to make it all perfect :) I'll buy you a beer - I've already offered more than once!
I don't like beer. Which is weird, being german. I prefer a cold coke.

Mark_A_W

20th February 2011, 09:19

No, I don't think the stock VBS script is that clever.

But it's a VBS script - a skilled person will be able to make it serve up a cold coke :)

pirlouy

20th February 2011, 11:11

Touching monitor display refresh rate. Isn't it dangerous for monitor/TV/etc. ?

jmone

20th February 2011, 11:29

I disagree. Changing the video refresh rate is naturally the duty of the video renderer. Anything else makes no sense. Having the audio renderer change the video refresh rate behind the back of the video renderer makes as much sense as having the video renderer change the audio DAC sample rate behind the back of the audio renderer.

I agree that the Audio Renderer is the "odd" place to have it be given the development of Reclock to resampling Audio to keep place with the video it was a logical outcome at the time.

That said, there are other parts of the playback chain where the refresh rate management may make sense, including the Video Render, Decoder or the Player itself. I'd argue that the Player may make the most sense as it owns the whole direct show playback thread. Of course that means the player need to monitor and influence what is happening!

madshi

20th February 2011, 12:07

Touching monitor display refresh rate. Isn't it dangerous for monitor/TV/etc. ?
Not really. Today's digital displays simply show no image if they don't understand/support the video format. Maybe CRTs could take damage if you drive them with too high refresh rate, I don't know.

there are other parts of the playback chain where the refresh rate management may make sense, including the Video Render, Decoder or the Player itself. I'd argue that the Player may make the most sense as it owns the whole direct show playback thread. Of course that means the player need to monitor and influence what is happening!
It depends a bit on how you see it. Having the refresh rate management in the player would be a logical choice, too, since the media player is the one who supposedly has ultimate control over everything. However, I think that video rendering decisions should be made by the video renderer and not by the media player. E.g. if a video renderer offers features like black frame insertion, or interpolated intermediate frames, or if the video renderer is able to automatically detect video vs. film content, all these things result in the need for different refresh rates. If the media player would be the one to decide, it would have to understand and add controls for all those video renderer specific features.

As an example, just suppose madVR v1.1 would add black frame insertion as a new feature. If that happens, madVR will have to output very high refresh rates (as high as possible). If the media player would be in control of refresh rates, it would not activate the necessary high refresh rates - unless it would get new controls for madVR v1.1. So basically the media player would need to add controls to disable/enable black frame insertion, and then forward these controls to madVR. Which means that with the release of madVR v1.1, all media players which support madVR would have to be updated to add the new controls and to allow the higher refresh rates needed for black frame insertion. Does this really make sense? I don't think so.

(Just to be safe: I'm not saying that madVR v1.1 will add black frame insertion. I've no idea whether I'll ever implement such a feature.)

noee

20th February 2011, 13:48

But does it allow you to specify different refresh rate change settings for different detected monitors? If so, that would be news to me.

Yes, it does, but only using the "event trigger" method that is provided. For example, Reclock will trigger an event (NotifyDisplayChange.EXE) that specifically runs the script file "RunEvent.VBS".

The following params are passed to the VBS:
' The 7 parameters received by this script are explained below:
'
' (1) contains the event name that just occurred:
' - "GREEN" : tray icon just got green (all is fine). Parameter
' - "YELLOW" : tray icon just got yellow. We should make what is necessary
' to change the monitor refresh rate
' - "STOP" : playback just stopped
' - "QUIT" : ReClock is about to quit
'
' Parameters (2), (3), (8) and (9) apply only with "GREEN" and "YELLOW" events. Otherwise they contain "-"
'
' (2) contains the type of media file currently played :
' - "CINEMA" : frame rate of source file is around 24 fps
' - "PAL" : frame rate of source file is around 25 fps
' - "NTSC" : frame rate of source file is around 30 fps
' - "CUSTOM" : frame rate of source file does not fall in previous categories
'
' (3) contains the current sound playback mode (apply only with GREEN/YELLOW event):
' - "PCM" : PCM mode
' - "SPDIF" : AC3 passthrough SPDIF
'
' (4) contains the current monitor selected for playback (1=primary, 2=secondary, etc...)
'
' (5) contains the total monitor count detected in the system
'
' (6) contains the current resolution of your monitor (WIDTHxHEIGHT)
'
' (7) contains the current refresh rate of your monitor (in Hz)
'
' (8) contains the original playback rate of the file (in fps multiplied by 1000)
'
' (9) contains the current playback rate of the file (in fps multiplied by 1000)
'
' (10) contains the filename of the current media file

YOu'll note that param 4 is the current playback monitor.

So, yeah, you can do it using this method. But technically speaking, REclock is not doing it. Reclock is only triggering the event by calling the VBS. Up to you (the user) what to do with it.

And for some reason, the myth has perpetuated that Reclock requires Powerstrip to do this. Completely not true, you can call any "display changer" from the script.

Xirix

20th February 2011, 14:17

I've just tried madvr, disabled exclusive mode, it seemed to be fine, but it's using my processor considerably more than any of the other renderers were, is there a way to tone it down? I know it's a super high quality renderer, but I'm only trying it out because practically all the others renderers available to me have been problematic.

yesgrey

20th February 2011, 14:56

is there a way to tone it down? I know it's a super high quality renderer, but I'm only trying it out because practically all the others renderers available to me have been problematic.
Try setting all scaling to bilinear and disabling dithering.

madshi

20th February 2011, 15:05

Yes, it does, but only using the "event trigger" method that is provided. For example, Reclock will trigger an event (NotifyDisplayChange.EXE) that specifically runs the script file "RunEvent.VBS".

YOu'll note that param 4 is the current playback monitor.
Ah, I see, thanks. However, Reclock is only reporting the monitor number. There's no real display management. E.g. if you sometimes have a plasma and sometimes a front projector on the secondary GPU port, Reclock will not help figuring out which of them is currently connected. Of course you can do all that kind of stuff in the script, too, but if you go there, at some point you end up writing your own full blown software.

I've just tried madvr, disabled exclusive mode, it seemed to be fine, but it's using my processor considerably more than any of the other renderers were, is there a way to tone it down? I know it's a super high quality renderer, but I'm only trying it out because practically all the others renderers available to me have been problematic.
What do you mean with "my processor"? Do you mean the GPU or the CPU? The CPU is used more because madVR currently does not support DXVA decoding. The Haali Renderer doesn't support DXVA decoding, either, though. So the CPU consumption should be more or less comparable between madVR and Haali. Of course VMR, EVR and Overlay will have much lower CPU consumption if you use DXVA decoding.

noee

20th February 2011, 15:27

Ah, I see, thanks. However, Reclock is only reporting the monitor number. There's no real display management. E.g. if you sometimes have a plasma and sometimes a front projector on the secondary GPU port, Reclock will not help figuring out which of them is currently connected. Of course you can do all that kind of stuff in the script, too, but if you go there, at some point you end up writing your own full blown software.

Yep, agree completely, the Reclock solution is, IMO, at best, a hack and completely unacceptable for "end user" types.

Sometimes I think it would be cool if there was a service interface available to players/renderers for display management. The Windows API and accompanying abstractions are lacking.

A well-defined interface that could encapsulate the monitor management, such that all players/renderers could rely on the service, might really simplify the players and set the stage for local/remote multi-mon support.

madshi

20th February 2011, 17:01

Sometimes I think it would be cool if there was a service interface available to players/renderers for display management. The Windows API and accompanying abstractions are lacking.

A well-defined interface that could encapsulate the monitor management, such that all players/renderers could rely on the service, might really simplify the players and set the stage for local/remote multi-mon support.
There are so many things Microsoft could do for HTPCs. But I think they don't really have a clue. Or maybe they don't care. Same with ATI and NVidia. There doesn't seem to be anybody at ATI at least who's any personal knowledge about HTPCs.

Ok so here's the log for the massive frame-dropping I get. Here's what I did:

1) Start video.
2) Pause after ~500ms (immediately)
3) Did not touch window or anything for at least 5-8 mins.
4) Played video for 10 seconds, paused it again, then stopped it.

Log: http://www.mediafire.com/?cnewog37eoh7dhh
Thanks. I've checked out your log, but it doesn't tell me too much. What I can see is that frames are dropped simply because rendering doesn't run fast enough. The rendering thread seems to have a lot of weird phases where it doesn't do much. I don't really know what's this caused by, but I doubt that madVR is at fault. Is it possible that your GPU goes into some kind of sleep mode after such a long pause? And that it doesn't fully wake up again?

madshi

20th February 2011, 18:11

I have a minor bug to report, as well as a question, as follows.

1. In Windows 7 Control Panel, "Appearance and Personalization", "Display", "Make it easier to read what's on your screen", there are three options. "Smaller", "Medium" and "Larger". If using "Larger", madVR will not switch to fullscreen exclusive mode. Selecting "Smaller" or "Medium" is OK, but not when using "Larger". I'm using "Larger" on my 50" TV (1920x1080) and it took a while before I found out this :-)
It seems that in "Larger" mode, a maximized window has a resolution of only 1280x720 instead of 1920x1080. As a result madVR will not see this as maximized. Furthermore, in windowed mode the video rendering will also be zoomed by Windows. This is really bad for image quality. IMHO there are 2 solutions to this problem:

(1) Make do with "Medium", which seems to have none of the mentioned problems.

(2) Or ask MPC-HC to support the "Larger" mode. The support must be implemented by the media player. I've tried to do this from within madVR, but then MPC-HC goes weird. The Microsoft documentation also says that this needs to be done by the EXE (MPC-HC) and not by any DLLs (madVR).

I don't think there's much I can do here.

dansrfe

20th February 2011, 18:39

cyberbeing

20th February 2011, 18:41

So the frame-drop as long pause problem does still exist as I thought. It's too bad you weren't able to find out the cause from dansrfe's log though... It's much more random for me, so I've been unable to produce a practical log.

Do you think the problem could be the GPU flushing or overwriting madVR's frame queues or shader workloads which were residing in GPU RAM? In other words, a GPU RAM garbage collection problem?

If dansrfe is able to easily reproduce the problem, it would be interesting to see if madVR simply dumping the GPU cache to system memory on pause, and then reading it back on un-pause would workaround the issue. Another related idea would be for madVR to basically reset itself on pause to its initial on-load state. Obviously both would have performance impacts, but it would be interesting if either actually fixed the problem.

dansrfe

20th February 2011, 18:49

You know I get this feeling that the frame drops might have something to do with communication with the graphics card via the drivers either from Windows or madVR. I think DPC latency might have something to do with this as well.

Xirix

20th February 2011, 19:42

Ah, I see, thanks. However, Reclock is only reporting the monitor number. There's no real display management. E.g. if you sometimes have a plasma and sometimes a front projector on the secondary GPU port, Reclock will not help figuring out which of them is currently connected. Of course you can do all that kind of stuff in the script, too, but if you go there, at some point you end up writing your own full blown software.

What do you mean with "my processor"? Do you mean the GPU or the CPU? The CPU is used more because madVR currently does not support DXVA decoding. The Haali Renderer doesn't support DXVA decoding, either, though. So the CPU consumption should be more or less comparable between madVR and Haali. Of course VMR, EVR and Overlay will have much lower CPU consumption if you use DXVA decoding.

Well, I noticed it after literally seconds of playing a video with madvr, my CPU's fan sped up considerably and it was using considerably more CPU power than Haali was and heating up a lot, in fact I never noticed a different between Haali and the other renderers.

I'll try editing the settings like yesgrey suggested and get back.

madshi

20th February 2011, 21:25

Feature request:

1) When a video is played and I manually scale it by dragging MPC-HC's window
2) I put it in FSE
3) I get out of FSE (after some time to make adjustments, etc.
4) The scaling that I set it at before I fullscreened it is not the resolution the video goes back to

Is there a way madVR can remember the resolution that the video was scaled to before going into FSE and then it can restore back to that same resolution when coming out of FSE?
You mean after going out of FSE the video window size is different than before? If so: madVR does not control the video window size. The media player does. This is probably a feature request you need to ask in the MPC-HC thread.

If you mean something else, then I have not understood it.

So the frame-drop as long pause problem does still exist as I thought.
But only for few people, it seems.

Do you think the problem could be the GPU flushing or overwriting madVR's frame queues or shader workloads which were residing in GPU RAM? In other words, a GPU RAM garbage collection problem?
The queues are not overwritten. I could see from the log that they worked fine. All 8 frames in the queue were displayed perfectly after the "unpause". But after that the rendering of the new frames just wasn't fast enough.

If dansrfe is able to easily reproduce the problem, it would be interesting to see if madVR simply dumping the GPU cache to system memory on pause, and then reading it back on un-pause would workaround the issue.
GPU cache? You mean the queue contents? That's definitely not the cause of the problem.

Another related idea would be for madVR to basically reset itself on pause to its initial on-load state. Obviously both would have performance impacts, but it would be interesting if either actually fixed the problem.
Yeah, a full Direct3D reinitialization might work around the problem. But I don't like this "solution" at all. I can't do that as a default behaviour in madVR because there will be visible artifacts (screen will probably go black for a moment).

Can you check whether your GPU clocks have changed after a long pause? Maybe the GPU has downclocked itself?

Well, I noticed it after literally seconds of playing a video with madvr, my CPU's fan sped up considerably and it was using considerably more CPU power than Haali was and heating up a lot, in fact I never noticed a different between Haali and the other renderers.
Have you been testing with the same video clip? Decoding some videos consume *A LOT* of CPU power, while decoding others is a piece of cake. You need to test all renderers with the same video.

It is possible that Haali consumes a bit less CPU than madVR. But the difference shouldn't be that big. E.g. with a high bitrate h264 or VC-1 Blu-Ray, if your CPU is borderline fast enough, you should get near 100% with either madVR or Haali, and you should fly around 10-20% with VMR and EVR with DXVA decoding. Decoding MPEG2 is very easy for the CPU in comparison.

I'll try editing the settings like yesgrey suggested and get back.
yesgrey misunderstood you. He thought you meant your GPU when you said "processor". Changing the settings like yesgrey suggested will not decrease CPU power.

cyberbeing

20th February 2011, 22:27

But only for few people, it seems.
I honestly haven't seen it myself for quite some time, so for all I know the problem is already resolved on my system, but then why does dansrfe still have it? On the other hand, when this problem was in full swing, I already got into the habit of never leaving a video paused for long periods of time needlessly.

Can you check whether your GPU clocks have changed after a long pause? Maybe the GPU has downclocked itself?

No need to pause the video, since the GPU will downclock normally whenever there is a low GPU load for what appears to be 30 seconds. For example, windowed playback at 100% without resizing.

Date , GPU Core Clock [MHz] , GPU Memory Clock [MHz] , GPU Temperature [°C] , Memory Used [MB] , GPU Load [%] , Memory Controller Load [%] , Video Engine Load [%] , VDDC [V] ,

IDLE GPU
2011-02-20 13:09:36 , 275.4 , 601.7 , 54.0 , 25 , 0 , 3 , 0 , 1.2000 ,

MADVR VIDEO PLAYBACK
2011-02-20 13:09:37 , 550.8 , 850.5 , 54.0 , 220 , 9 , 6 , 0 , 1.4500 ,

MADVR VIDEO PLAYBACK LOW-POWER 3D DOWNCLOCK
2011-02-20 13:10:09 , 501.4 , 850.5 , 55.0 , 220 , 10 , 6 , 0 , 1.4500 ,

MADVR VIDEO PLAYBACK 2D DOWNCLOCK
2011-02-20 13:10:33 , 275.4 , 601.7 , 57.0 , 220 , 16 , 7 , 0 , 1.2000 ,

madshi

20th February 2011, 22:39

Can you force the clocks to stay on max? Maybe that would already take care of the 3dlut stuttering problem you're experiencing?

Xirix

20th February 2011, 23:06

Have you been testing with the same video clip? Decoding some videos consume *A LOT* of CPU power, while decoding others is a piece of cake. You need to test all renderers with the same video.

It is possible that Haali consumes a bit less CPU than madVR. But the difference shouldn't be that big. E.g. with a high bitrate h264 or VC-1 Blu-Ray, if your CPU is borderline fast enough, you should get near 100% with either madVR or Haali, and you should fly around 10-20% with VMR and EVR with DXVA decoding. Decoding MPEG2 is very easy for the CPU in comparison.

I have been testing with the same clip yes, and it's nothing that should be so processor-intensive anyway, it's a video of someone playing a SNES game. With Haali there's little to no increase of CPU usage, with madvr on default except for disabling exclusive mode my fan is spinning 700rpm faster and one of my CPU's cores is maxing out (According to Speedfan anyway, not the most reliable program I know, but there's definitely quite a big different in power used regardless)