madVR - high quality video renderer (GPU assisted)

[someone`]

Originally Posted by SamuriHL

My nVidia machine is showing the same kind of dropped frame thing at the very beginning, but, once it settles down is also pretty stable.

Same problem here .
When I start playing 1080p content , frames drop like crazy , all buffer numbers are very low , 0 1 or 2 . I have to pause a few seconds and a few times to make it play smoothly , after that not a single drop/delay frame in hours .
Decoder : Potplayer DXVA / Cyberlink HAM ( it's a bit better with HAM ).
HD 4670 512MB .

[kasper93]

@ajp_anton
Good script, but why did you change filenames...
I made few changes, that is better and works

@echo off
if exist "madVR.ax" (
if exist "madVR [Normal].ax" (goto on) else (
if exist "madVR [Debug].ax" (goto off)))

echo Can't find your madVR files.
pause
exit

:on
cls
echo #####################################
echo #  Debug mode is currently ENABLED  #
echo #####################################
echo.
set /P ans=Do you want to disable debug mode (Y/N)? 
if /i %ans%==n (exit)
if /i not %ans%==y (goto on)
ren "madVR.ax" "madVR [Debug].ax"
ren "madVR [Normal].ax" "madVR.ax"
if exist "madVR [Debug].ax" if exist "madVR.ax" (echo Debug was successfully disabled) else (echo Something went wrong...)
pause
exit

:off
cls
echo ######################################
echo #  Debug mode is currently DISABLED  #
echo ######################################
echo.
set /P ans=Do you want to enable debug mode (Y/N)? 
if /i %ans%==n (exit)
if /i not %ans%==y (goto off)
ren "madVR.ax" "madVR [Normal].ax"
ren "madVR [Debug].ax" "madVR.ax"
if exist "madVR [Normal].ax" if exist "madVR.ax" (echo Debug was successfully enabled) else (echo Something went wrong...)
pause
exit

and simple one without any questions. Switch files only

@echo off
if exist "madVR.ax" (
if exist "madVR [Normal].ax" (goto on) else (
if exist "madVR [Debug].ax" (goto off)))

echo Can't find your madVR files.
pause
exit

:on
cls
ren "madVR.ax" "madVR [Debug].ax"
ren "madVR [Normal].ax" "madVR.ax"
exit

:off
ren "madVR.ax" "madVR [Normal].ax"
ren "madVR [Debug].ax" "madVR.ax"
exit

[SamuriHL]

Originally Posted by someone`

Same problem here .
When I start playing 1080p content , frames drop like crazy , all buffer numbers are very low , 0 1 or 2 . I have to pause a few seconds and a few times to make it play smoothly , after that not a single drop/delay frame in hours .
Decoder : Potplayer DXVA / Cyberlink HAM ( it's a bit better with HAM ).
HD 4670 512MB .

I BELIEVE it has to do with switching to FSE mode but I'm really not sure. Even staying in windowed mode seems to have a few dropped frames in the beginning, so, I really don't know. And in my case it doesn't seem to matter if I'm on AMD or nVidia hardware. Happens on both. And is rock stable after it settles down.

[ajp_anton]

Originally Posted by kasper93

@ajp_anton
Good script, but why did you change filenames...
I made few changes, that is better and works

The point was that the name of the .ax file that is currently not being used would immediately tell the user whether debug mode is enabled or not.
Your filenames instead tell you which one is which, and only if you know what's going on. If one sees "madVR [Normal].ax", one may think "everything is normal" instead of "the normal one doesn't have the correct filename, therefore the debug build is active".

[pankov]

madshi,
as you've requested I've tried playing 23.976 file at 23.976Hz (23.97419 to be precise - I can't get any closer at the moment) and it doesn't differ from the CPU usage at 50.00003Hz.
I've done some testing with v0.51 and a little bit more with v0.52 and there is no difference in the CPU usage between the two.
Here are some screenshots from v0.51 (it's the same with v0.52 but I didn't have the time/will to make new ones) (from left to right)
1. v0.51 playback at 50.00003Hz display (LCD - primary) using new rendering path
2. v0.51 playback at 50.00003Hz display (Projector - secondary) using new rendering path
3. v0.51 playback at 23.97419Hz display (Projector - secondary) using new rendering path
4. v0.51 playback at 23.97419Hz display (Projector - secondary) using old rendering path


and finally the threads CPU usage of v0.52


And here is a log from v0.52 in case you've added some logging that is different from v0.51
http://www.mediafire.com/?6na1zoo6jfldgov

[fiver]

Originally Posted by madshi

Have you tried updating your GPU drivers? If that doesn't help, please create a debug log for me. It works like this: (1) rename "madVR.ax" to "madVR [release].ax". (2) rename "madVR [debug].ax" to "madVR.ax". (3) reproduce the problem. (4) Zip and upload the file "madVR - log.txt" which you'll find on your desktop.

I was running the officially supported drivers from HP (10.8.something) and today I tried unsupported 11.2. Same problem.

I have however isolated the issue. The display on the Envy 17 is capable of 60,96,and 120 hz. I normally run on 120 hz with the ATI GPU. Madvr works fine in 60 but is broken with 96 and 120.

I've attached a log from my 120hz failure.

[cyberbeing]

Originally Posted by madshi

IMHO this is a bug in the display drivers. But anyway, the new rendering path doesn't have this problem, right? So let's just tweak the new rendering path until it's better than the old in every way. I hope that will be possible somehow. There's nothing I can do with the old rendering path to solve the "out-of-order" frame stuttering.

madshi, in 0.51 & 0.52, reducing the presentation queue to 2 from 3 seems to improve things greatly, but I'm still unable to use a resizing and a 3DLUT with the new Fullscreen render path without stuttering and frame drops. My GPU must take a massive performance hit from whatever presentation method you are using for the queue. Could you allow the presentation queue to be set to 1 to see if it fixes my performance issues? I suspect this is the same underlying cause that causes issues with the old Fullscreen render path with more than a single backbuffer, but in a different way. The stuttering without frame drops I see, seem to happen whenever the Present/Backbuffer queue drops to 0. Shouldn't madVR 0.52 report presentation glitches in the stats when a scheduled present is missed, or does that serve a different purpose?

Is setting the Present Queue to 1 even possible with the swap logic used in the new render path?

If not, there may be something else to try. As I mentioned in the past, I usually got frame drops/delays whenever the Render Queue dropped below 7/8, the more the Render Queue emptied, the faster drops happened. I'd be interested to see if reducing the Render Queue allowed me to have a higher Present Queue with the new path. If we're insanely lucky, lowering the Render Queue may also act as a workaround for my 3DLUT problem.

Bug(?): CTRL+J Refresh Rate calculation stops working when entering the new Fullscreen Exclusive mode (madVR 0.50-0.52). This also causes the 'dropped/repeated frame every' calculation to break, since the calculated refresh rate isn't correct.

Originally Posted by madshi

Hmmmm... I've added some more logging output in v0.51 in the area where the hang occurred according to your log. Can you make another log for me with a similar hang with v0.51? Thanks!

I don't get these crashes here. Any way to reproduce them reliably?

I haven't had time to get you debug logs of the hang on close yet. As for the MPC-HC crashes on close, it's probably the same cause as the hang on close problem.

Originally Posted by madshi

Does rendering still succeed despite this error message? I've now simply silently disabled this error message in v0.51.

Yes, it still succeeded. Removing the error message seems to have no ill effects 0.51.

[Rain1]

Hi,

First, wow 0.52 already ...& thanks madshi /
Following up my previous test (for 0.49 & 0.50), here's my result for 0.52

* Dropped frames: 2 3 3 4 3
* GPU & CPU:

Notes:
* Bottom 3 graphs for CPU, top 2 graphs for GPU
* Load measured on Core 0, Usage on overall CPU,
* Decoder: ffmpeg-mt
* madVR settings: 4 frames pre-rendered (default)

The result looks like CPU consumption does improve compare to 0.50

I have another question, does the "maximum pre-rendered frames" in nVidia's control panel relates to madVR similar setting ?
If so, should I change it to match with madVR's setting ?

Thank you /

[Hprd]

Well, i doubt you read my original post where i said it was ok, but anyhow, it's not... (after observing a little more videos...) The que set to 16 as compare to 2 made it look like the video was playing back at half the frame rate (or something like that, it's hard to describe), it wasn't really stuttery (most of the time, after playing a video with a right to left pan, i could see it though on 16, 2 was perfectly smooth, that was when the deviation/frame repeat was high/small. Sometimes when i tried to compare it was ok on 16... I suspect for some reason it's a video driver issue, and nothing with madvr at all), just hardly smooth at all. 24/30hz resolutions don't drop frames anymore though. But, there's presentation glitches which act the same.

So basicaly, this version didn't seem to fix any of my problems ;(. I can live with this for now though, as not every video has the massive frame repeat problem (as the osd shows it anyways), which is incorrectable it seems unless switching to a lower que number.

EDIT: Ok, so i solved my problem. B4 i had reclock have the audio be output purely, without any resampling for maximum quality. But, if i allowed it to resample it (to sync with the refresh rate and wahtnot), i get PERFECT playback reguardless of what the que is set to or what video i play... I guess i might have to compromise ever so slightly for the audio quality for now, or mess around to see if i can get something else to fix it without resampling etc.

[robpdotcom]

I wasn't convinced until I saw it, but the green OSD is definitely easier to read.

[jmone]

Just got to the HTPC to test V0.52 which I use Relcock to change the Refresh Rate to match the media fps:
- V0.52 using New Path = Screen goes black when the refresh rate changes but Audio plays on just fine. If I then drop back to Windowed Mode, eg Pause you see a frame, if you play from then you get suttery video playback then back to a black screen when it goes into Exlcusive Mode (you don't even see the mad's OSD).
- V0.52 using Old Path = Fine.

Both Old and New Path are fine if the refresh rate does not change.

Using an ATI 5670 1080/24/50/60hz over HDMI

[ryrynz]

Using the new path and enabling the ffdshow framerate doubler I'm getting dropped frames, I'm only noticing it on H264 content. It's worse in fullscreen mode on higher reference frame and resolution stuff (16/720). The old path is dropping no frames with it enabled, when not using the doubler the new path appears to be working well in 0.52

[cyberbeing]

Originally Posted by cyberbeing

I haven't had time to get you debug logs of the hang on close yet. As for the MPC-HC crashes on close, it's probably the same cause as the hang on close problem.

Ok I got a log with madVR 0.52. It doesn't appear to be caused by the new Fullscreen render path after-all, in the following log it happened in windowed mode with no resizing.

http://www.mediafire.com/?2j29rqi5v62bsg9

The main difference I see is "Upload UploadThread() -> +;" being called after "Queue_Final();" in the logs where a hang happens.

[ikarad]

Originally Posted by madshi

The new exclusive mode rendering path presents one frame per VSync. So in your case it presents 96fps. However, it only *renders* 24fps. In your case madVR renders one video frame, then presents it 4 times. It's nearly impossible for fraps to see the difference. To fraps it looks like 96fps. I wish I could tell DirectX to just skip a VSync. There even is a way to do that, but it doesn't work properly, unfortunately. So I have to actually present for every VSync.

Thanks

Yes, but some of the greens (especially sharpness) are much lower than with other algorithms. Most humans like images to look sharp and SoftCubic 100 is the opposite of sharp. My recommendation is to upscale a reasonably sharp DVD. Then pause the image and switch between different algorithms to see which looks best to your eyes.

What parameters do you advise me for luma upscaling and luma downscaling?



Last question:
There are some parameters in rendering options and I don't know how configure them. If anybody could explain the aim of each option, thanks a lot.

[webs0r]

Originally Posted by jmone

Just got to the HTPC to test V0.52 which I use Relcock to change the Refresh Rate to match the media fps:
- V0.52 using New Path = Screen goes black when the refresh rate changes but Audio plays on just fine. If I then drop back to Windowed Mode, eg Pause you see a frame, if you play from then you get suttery video playback then back to a black screen when it goes into Exlcusive Mode (you don't even see the mad's OSD).
- V0.52 using Old Path = Fine.

Both Old and New Path are fine if the refresh rate does not change.

Using an ATI 5670 1080/24/50/60hz over HDMI

I get the exact same result (v0.52, ATI 5670 here too).
Now neither MPC-HC changer or Reclock script changing works
Other than that 51/52 work beautifully.

Madshi are you considering adding the ability into the renderer itself? Or can something be changed so that madVR "adjusts" itself to the external change of display refresh rate?

[Mark_A_W]

madshi

With the new exclusive rendering path, fullscreen exclusive works on my interlaced VGA display at 96hz (it didn't before).


But the playback is jerky and the presentation glitches continually climb - in batches of ~40 every 1/4 second.

The render and backbuffer queues are near empty.


However this gives me hope that it may one day work for me. Would a log help? I do realise I'm the only one here with a system like this, so if you don't want to expend effort, that's cool (I'm gunna get a new projector running 24p one day).

[Andy o]

0.53 still has visibly higher CPU usage with the new path than with the older one. Just FYI, I don't mind if it's necessary for the new path to be better, though my CPU is powerful enough. This is about 4 minutes' worth of 1080p/23.976 video for each (old first, then new), same as the last ones only a bit longer, no scaling.



Individual cores graph.


-

[madshi]

Originally Posted by kasper93

Unfortunately problem is still there. Queues are not stable. There are stable (and full) for a while and then "drop" and back to normal, drop, back to normal and so on. It's not big problem because, there is no dropped frames, but in old exclusive queues were stable. queues drops to 4-5, 4-5, 4-5, 1-8, 0-8...

Please try again with v0.53. Of course if there are no dropped/delayed frames and no presentation glitches then it's not a big problem if the queues are not stable. Anyway, if it bothers you, try fixing the GPU clock to a specific level. Maybe your GPU clocks down and up all the time, resulting in this queue behaviour? Not sure, just guessing...

Originally Posted by sneaker_ger

Would it be possible to reorder the OSD?

Done.

Originally Posted by SamuriHL

The dropped frames on my main HTPC happen in the very beginning. Probably when switching to FSE mode. Nothing to see there. After the initial "chatter" it settles down and is ROCK SOLID. My AMD 5870 is rocking my videos with this setup. LOVE IT!

Originally Posted by SamuriHL

My nVidia machine is showing the same kind of dropped frame thing at the very beginning, but, once it settles down is also pretty stable. Maybe 1 or 2 dropped frames here and there, but, quite frankly it looks amazing. CPU utilization on that machine is about 50% in MPC-HC so that's not too bad. I can't remember if it's higher or lower than 0.49, but, it's lower than 0.50 for sure. All in all I'm quite pleased with 0.52. Will mess around with my laptop more and see if I can figure out what happened there. In any case, love the green (man that helped!) and really loving madVR right now. So, job well done afaic.

Originally Posted by Qaq

First, thanks for new version. Tried it with 720p/24 video, display was set to 1080p/24. CPU usage reaches ~50%. Here you can find the log file + few screenshots: http://depositfiles.com/files/y0t0b9ap9 or here: http://www.mediafire.com/?2eyg8v1lxwstlz1 Hope it will help.

Thanks. I've tried to reproduce the problem here, but I can't. Both my HTPC and my dev PC have roughly the same CPU consumption that v0.49 had. Maybe 1% higher, if at all.

Can you please retest with v0.53? If it's still not fixed, what would help me would be the following, but you probably can give me this only if you have a dual monitor setup:

(1) A madVR log of the high CPU consumption.
(2) The ProcessExplorer should show which thread is consuming the most CPU in the media player process. This thread is probably named "madVR.ax + xxxx". Please tell me the "TID" number of this thread. You'll find it in the properties of the media player process in the "threads" tab.

But as I said, with a single monitor setup getting information (2) will probably be impossible because you can't see the ProcessExplorer while madVR is in exclusive mode.

Originally Posted by ajp_anton

Bat file scripting isn't my strong suit, but I gave it a try

Originally Posted by kasper93

I made few changes, that is better and works

Thanks, guys. I've not yet looked into the batch files, but will do so for the next build (v0.54).

Originally Posted by bjd

0.51 seems to be working better than any other version.

No issues so far and very smooth playback

Originally Posted by someone`

Same problem here .
When I start playing 1080p content , frames drop like crazy , all buffer numbers are very low , 0 1 or 2 . I have to pause a few seconds and a few times to make it play smoothly , after that not a single drop/delay frame in hours .

Can you please retry with v0.53? Having to pause/play every time is very annoying, of course.

Originally Posted by pankov

as you've requested I've tried playing 23.976 file at 23.976Hz (23.97419 to be precise - I can't get any closer at the moment) and it doesn't differ from the CPU usage at 50.00003Hz.
I've done some testing with v0.51 and a little bit more with v0.52 and there is no difference in the CPU usage between the two.

Thanks! The ProcessExplorer screenshot does not match the log, though... Can you create another log with v0.53 (if the problem is still not fixed in v0.53) together with a ProcessExplorer screenshot from the same test run? That would be helpful cause it would allow me to identify which thread it is that is consuming so much CPU.

Originally Posted by fiver

I have however isolated the issue. The display on the Envy 17 is capable of 60,96,and 120 hz. I normally run on 120 hz with the ATI GPU. Madvr works fine in 60 but is broken with 96 and 120.

I've attached a log from my 120hz failure.

Interesting. madVR can simply not gather enough information about the VSync / refresh rate to be able to playback. Could you please retry with v0.53? I've made a change which might fix this problem.

Originally Posted by cyberbeing

madshi, in 0.51 & 0.52, reducing the presentation queue to 2 from 3 seems to improve things greatly, but I'm still unable to use a resizing and a 3DLUT with the new Fullscreen render path without stuttering and frame drops. My GPU must take a massive performance hit from whatever presentation method you are using for the queue. Could you allow the presentation queue to be set to 1 to see if it fixes my performance issues? I suspect this is the same underlying cause that causes issues with the old Fullscreen render path with more than a single backbuffer, but in a different way.

I will do that in v0.54, if v0.53 doesn't help.

Originally Posted by cyberbeing

The stuttering without frame drops I see, seem to happen whenever the Present/Backbuffer queue drops to 0. Shouldn't madVR 0.52 report presentation glitches in the stats when a scheduled preset is missed, or does that serve a different purpose?

The "presentation glitch" statistic tells us if the GPU dropped a frame although all appeared to look just fine. All queues can be perfectly full and then still a presentation glitch can occur. It shouldn't but it can.

Originally Posted by cyberbeing

Is setting the Present Queue to 1 even possible with the swap logic used in the new render path?

Yes, but I can't imagine that it will produce smooth playback.

Originally Posted by cyberbeing

If not, there may be something else to try. As I mentioned in the past, I usually got frame drops/delays whenever the Render Queue dropped below 7/8, the more the Render Queue emptied, the faster drops happened. I'd be interested to see if reducing the Render Queue allowed me to have a higher Present Queue with the new path. If we're insanely lucky, lowering the Render Queue may also act as a workaround for my 3DLUT problem.

I doubt it would help, but I do plan to make the queue size adjustable in a future version.

Originally Posted by cyberbeing

CTRL+J Refresh Rate calculation stops working when entering the new Fullscreen Exclusive mode (madVR 0.50-0.52).

Ok, this was a very important hint. This explains more than anything else why you're not having smooth playback. madVR heavily relies on knowing the VSync state at all times. If the refresh rate calculation is wrong then madVR can't produce smooth output. On my PCs the refresh rate calculation works just fine in exclusive mode, too. Not sure why it doesn't for you. Anyway, I've made a big change in how I'm reading the VSync information from the GPU in v0.53. I hope that this will fix the wrong refresh rate - and produce smooth output for you, too.

Originally Posted by cyberbeing

Ok I got a log with madVR 0.52. It doesn't appear to be caused by the new Fullscreen render path after-all, in the following log it happened in windowed mode with no resizing.

http://www.mediafire.com/?2j29rqi5v62bsg9

The main difference I see is "Upload UploadThread() -> +;" being called after "Queue_Final();" in the logs where a hang happens.

Thanks. I've added yet more log information, but it will only be in v0.54. For now I still don't know why it's hanging where it's hanging. This might take several revisions to locate exactly. If you're willing to help, I'll need another log with v0.54. Don't know when v0.54 will be out, though.

Originally Posted by Rain1

here's my result for 0.52

Thanks!

I don't want you to get idle, though. So in a minute there'll be 0.53...

Originally Posted by Rain1

I have another question, does the "maximum pre-rendered frames" in nVidia's control panel relates to madVR similar setting ?
If so, should I change it to match with madVR's setting ?

You can try playing with it. In my tests it made no difference, but that was before I added support for more than 3 pre-rendered frames. So maybe it makes a difference now, although I don't think so.

Originally Posted by Hprd

Ok, so i solved my problem. B4 i had reclock have the audio be output purely, without any resampling for maximum quality. But, if i allowed it to resample it (to sync with the refresh rate and wahtnot), i get PERFECT playback reguardless of what the que is set to or what video i play... I guess i might have to compromise ever so slightly for the audio quality for now, or mess around to see if i can get something else to fix it without resampling etc.

Maybe v0.53 fixes the problem for you?

Originally Posted by jmone

Just got to the HTPC to test V0.52 which I use Relcock to change the Refresh Rate to match the media fps:
- V0.52 using New Path = Screen goes black when the refresh rate changes but Audio plays on just fine. If I then drop back to Windowed Mode, eg Pause you see a frame, if you play from then you get suttery video playback then back to a black screen when it goes into Exlcusive Mode (you don't even see the mad's OSD).
- V0.52 using Old Path = Fine.

Both Old and New Path are fine if the refresh rate does not change.

Originally Posted by webs0r

I get the exact same result (v0.52, ATI 5670 here too).
Now neither MPC-HC changer or Reclock script changing works
Other than that 51/52 work beautifully.

Madshi are you considering adding the ability into the renderer itself? Or can something be changed so that madVR "adjusts" itself to the external change of display refresh rate?

I do plan to add support for automatic refresh rate changing, which should fix this kind of problem. It will take some time, though, before I get to that.

Originally Posted by ryrynz

Using the new path and enabling the ffdshow framerate doubler I'm getting dropped frames, I'm only noticing it on H264 content. It's worse in fullscreen mode on higher reference frame and resolution stuff (16/720). The old path is dropping no frames with it enabled, when not using the doubler the new path appears to be working well in 0.52

Can you please retry with v0.53? Which is your display refresh rate and which (non-doubled) framerate does your h264 content have?

Originally Posted by ikarad

What parameters do you advise me for luma upscaling and luma downscaling?

I advice you to choose yourself based on what your eyes prefer. It's a matter of taste.

Originally Posted by ikarad

There are some parameters in rendering options and I don't know how configure them.

Just leave them at default unless you have some problems with non-smooth playback.

Originally Posted by Mark_A_W

With the new exclusive rendering path, fullscreen exclusive works on my interlaced VGA display at 96hz (it didn't before).

But the playback is jerky and the presentation glitches continually climb - in batches of ~40 every 1/4 second.

The render and backbuffer queues are near empty.

Interesting. Same with v0.53, I guess? What happens if you use Bilinear scaling (euwww!!!)?

[madshi]

madVR v0.53 released

http://madshi.net/madVR.zip

* moving madVR to another monitor during playback is now properly handled
* a couple more tweaks to the new exclusive mode rendering path
* vsync handling now uses its own Direct3D device instance
* improved handling of rendering failures
* OSD: rendering/presentation stats are now only shown when they're meaningful
* OSD: queue and dropped frames information is now directly next to each other

You can now load the video on any monitor, then move the media player to any other monitor and go into fullscreen mode. You no longer have to load the video file on the target monitor.

[LoRd_MuldeR]

Originally Posted by madshi

madVR v0.53 released
You can now load the video on any monitor, then move the media player to any other monitor and go into fullscreen mode. You no longer have to load the video file on the target monitor.