madVR - high quality video renderer (GPU assisted)

[sneaker_ger]

I've redone the 1080p60 on the 9200M GS test a lot of times and yesterday evening it would start dropping frames like crazy again. Today I started it again and it worked fine. I watched CPU and GPU clocks and they were running fine, so it's not an overheating problem. (Furthermore the complete cooling system of the laptop was renewed a month ago)

The CPU seems pretty high and I think it was probably the decoder that ran out if cpu, not a fault in the renderer system itself, so I will probably start looking into that further if it does happen again (unless you come up with a solution to the high CPU before that).
I also experienced a hang today - no idea whether it was caused by madVR or some other part of the chain.
Anyways, I had logging enabled, so if you think the logs could be of any use to you:
http://rapidshare.com/files/457272848/9200M_madVR_logs.7z

About the window->FSE switch:
It's definitely slower than the old path for me. Picture will even turn black for a moment.

[mrcorbo]

If you run into trouble, please try to avoid switching monitors or even resolutions/refresh rates. Make sure the monitors are already set to the correct resolution and refresh rate. Then move MPC-HC to the target monitor *before* loading the video file. If you do that, there should be no problems.

I'll find a better solution to this in a future madVR version.


I found that using Autofrequency is a reasonable work-around as it does the resolution change before loading MPC-HC, with the downside of Autofrequency not supporting all of the file associations (most notably *.bdmv) that MPC-HC does. I can deal with that. If you can figure out a way to allow madVR to cope with this scenario, all the better.

Thanks for the response.

[Gleb Egorych]

Hmmmm... How does v0.51 compare to v0.49 for you? I understand you liked v0.50 best, but there were serious problems in v0.50 and it did some things wrong.
0.49 has a bit less dropped frames with CoreAVC software mode than 0.51 with default settings. Though these 2 versions drop frames differently. 0.49 drops frames more regularly while 0.51 with 4 pre-rendered frames drops more spiky.

[SamuriHL]

Ummm. Hmmm. So, my laptop has never been what one would call "powerful". It's a c2d 2.53ghz machine with an AMD 3450 in it. It's fine for playing blu-rays with DXVA. Any time I ever tried to do software decoding and madVR, the machine would just choke and was completely unacceptable. Until today! :D I decided to try out the Cyberlink Video Decoder in HAM mode with madVR and see just what would happen. I'm SUPER impressed!! It actually works. Granted, the scaling options had to be, uhhhh, "tweaked", but, even so it looks awesome on my 1600x900 screen. Consider that I was streaming music from iTunes at the same time I was playing my trouble MKV's over the network and even with subs on, this machine handled it gracefully. MPC-HC never went over 60% CPU which is remarkable! This is really truly impressive.

[madshi]

Note, it was 720p video. With 049 CPU usage is ~12% and with 05* it reaches 60%. Like I said above, 051 has a bit less CPU usage than 050. I have AMD X2 +6000. Probably, my low-end ATI 5450 is the bottleneck.

I remember that new feature with framebuffers (tried to change from 4 to 6,8 without luck). So no doubts here, it was 051.

I always do it 1:1 matched. It was 23,976 - source and display.
Then I don't really understand at all why you have so high CPU consumption. Anyway, can you retry with v0.52? Will be out in a couple of minutes.

would it take long to add an option in madvr where you choose the color of the text (red, green, blue) ? so everybody can choose the color that suits best its need/preference.
I do not really have any fun/time right now to work on cosmetical things.

An idea for the debug build...

You could include a "Enable or disable debug.bat" that changes between the following two "modes":
Normal mode: normal build is "madVR.ax", debug build is "madVR [Debug is disabled].ax".
Debug mode: normal build is "madVR [Debug is enabled].ax", debug build is "madVR.ax".
Not a bad idea. Would you volunteer to create nice bat files for me? :)

In windowed mode fraps display 24 fps like the number of frame per second of my movie. In exclusive full screen mode, fraps display 96 fps (refresh rate of my CRT).
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.

I use softcubic at 100 because it is the only that doens't have red (only green).
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.

0.49 has a bit less dropped frames with CoreAVC software mode than 0.51 with default settings. Though these 2 versions drop frames differently. 0.49 drops frames more regularly while 0.51 with 4 pre-rendered frames drops more spiky.
And how does v0.52 behave? (out in a couple of minutes)

Ummm. Hmmm. So, my laptop has never been what one would call "powerful". It's a c2d 2.53ghz machine with an AMD 3450 in it. It's fine for playing blu-rays with DXVA. Any time I ever tried to do software decoding and madVR, the machine would just choke and was completely unacceptable. Until today! :D I decided to try out the Cyberlink Video Decoder in HAM mode with madVR and see just what would happen. I'm SUPER impressed!! It actually works. Granted, the scaling options had to be, uhhhh, "tweaked", but, even so it looks awesome on my 1600x900 screen. Consider that I was streaming music from iTunes at the same time I was playing my trouble MKV's over the network and even with subs on, this machine handled it gracefully. MPC-HC never went over 60% CPU which is remarkable! This is really truly impressive.
:)

[madshi]

madVR v0.52 released

http://madshi.net/madVR.zip

* fixed: presentation glitches were not reported at all
* fixed: reaction to presentation glitches was (very) wrong
* added some more fixes and tweaks to the new exclusive mode rendering path
* fixed: seek bar sometimes got stuck with new exclusive path when paused
* fixed: starting in paused mode sometimes failed to show first video frame
* fixed: pre-render option wasn't always enabled/disabled correctly
* debug OSD is now green instead of red (doom9 majority wish)
Please retest all v0.50/v0.51 problems with v0.52. Again I'm not sure about CPU consumption. Might be improved/fixed. Or not.

v0.52 now properly shows and handles presentation glitches. Please note that v0.49 and earlier versions were not able to detect presentation glitches even if they occurred (!!). That means if you see the presentation glitch statistic increase with v0.52 which you didn't see with v0.49 that's not yet a reason to worry. Trust your eyes above all else.

[kasper93]

Thanks for new version, I have some problem with unstable queue (new exclusive), but maybe it's fixed now. I will write if it's not ;P

EDIT

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...
HD5870
cat 11.4
win 7 64bit
ffdshow latest for decoding

[mrdkreka]

This might not be a very big problem for most people, but could you stop having CTRL+J (display stat) as a global hot-key. Can be a bit annoying when it conflict with other programs that use the same hot-key.

[SamuriHL]

CPU utilization on my laptop seems higher now. Not horribly high, but, higher. But, in a few minutes of play I had almost 60 dropped frames and 4 presentation glitches. UGH. My laptop is probably not really a good test bed.

[Plutotype]

first reaction 0.52

- like the green OSD:)
- paused state - seekbar issue fixed, thanks

[madshi]

This might not be a very big problem for most people, but could you stop having CTRL+J (display stat) as a global hot-key. Can be a bit annoying when it conflict with other programs that use the same hot-key.
I plan to make the key combination adjustable in a future version. I don't remember right now why I made it global, but there was some reason for that.

CPU utilization on my laptop seems higher now. Not horribly high, but, higher. But, in a few minutes of play I had almost 60 dropped frames and 4 presentation glitches. UGH. My laptop is probably not really a good test bed.
Higher than what? Than v0.51? :( Doesn't sound so good. Did older versions work better on your laptop? As in less frame drops?

[sneaker_ger]

Yes, seek bar issue seems to be fixed. Didn't notice any other change to 0.51.

Would it be possible to reorder the OSD?
Like:
Glitches
Delayed
Dropped
Decoder
Render
Upload
etc.

Would be easier to watch dropped frames and the queues at the same time to look for the source of a problem. Resolution, rectangle etc. don't change anyways.

About the key:
Maybe add it as an option in the settings, like Haali does.

[SamuriHL]

Higher than what? Than v0.51? :( Doesn't sound so good. Did older versions work better on your laptop? As in less frame drops?

Yea, 0.51. I never ever got it to work with older versions before. CPU utilization was always too high. However, my thought was now that I have the HAM mode stuff working on my main HTPC, I decided to see if it'd work on my laptop. The video is watchable. I didn't check the stats when testing 0.51. Just a quick "sniff test" to see if it'd handle my most troubling videos. And it did. Clearly not without some issues, but, for a laptop I'm ok with that. But same videos do seem higher with 0.52 on this machine. I haven't had a chance to test my main HTPC. And I haven't even had time to test 0.51 on my nVidia box let alone 0.52 yet.

EDIT: 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! Off to test the nVidia box. More challenging as it's 24Hz on slower hardware. This could be "fun".

[SamuriHL]

CPU utilization on my main HTPC is very very good. 14% for the video that I consider "troubling" that pushed my laptop up to 80% in 0.52. I have 12 dropped frames and 5 delayed frames. This is an MKV that notoriously causes problems, even with DXVA on a lot of machines. It's VC-1 in an MKV container with DTS-HD MA audio. It punishes decoders, splitters, and renderers alike. :D It's why I use it. Those dropped and delayed frames happened in the very beginning and haven't had ANY since.

[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. :)

[Qaq]

madshi
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.

[ajp_anton]

Not a bad idea. Would you volunteer to create nice bat files for me?
Bat file scripting isn't my strong suit, but I gave it a try:

@echo off
if exist "madVR.ax" (
if exist "madVR [Debug mode is enabled].ax" (goto on) else (
if exist "madVR [Debug mode is disabled].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 mode is disabled].ax"
ren "madVR [Debug mode is enabled].ax" "madVR.ax"
if exist "madVR [Debug mode is disabled].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 [Debug mode is enabled].ax"
ren "madVR [Debug mode is disabled].ax" "madVR.ax"
if exist "madVR [Debug mode is enabled].ax" (echo Debug was successfully enabled) else (echo Something went wrong...)
pause
exit
This will however fail if the filenames are wrong. Maybe it's possible to identify them by filesize (if not by absolute sizes, but from the fact that the debug one is bigger), but whatever...

edit: simplified the first if

[PlazzTT]

Installed 0.52 on Windows 7 x64, but it's still greyed out in MPC (build 3026 x64)?

[SamuriHL]

That would be because you need the 32 bit version of MPC-HC. madVR is 32 bit only. Even on a 64 bit OS.

[bjd]

@madshi

Thanks for 0.51. Never got a proper chance to fully test 0.50 before you released an update :)

However 0.51 seems to be working better than any other version.

No issues so far and very smooth playback :thanks:

[someone`]

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]

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]

@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
http://img854.imageshack.us/img854/5876/v051new5000003onlcd.th.png (http://img854.imageshack.us/i/v051new5000003onlcd.png/) http://img96.imageshack.us/img96/3365/v051new5000003.th.png (http://img96.imageshack.us/i/v051new5000003.png/) http://img40.imageshack.us/img40/8753/v051new2397419.th.png (http://img40.imageshack.us/i/v051new2397419.png/) http://img52.imageshack.us/img52/9127/v051old2397419.th.png (http://img52.imageshack.us/i/v051old2397419.png/)

and finally the threads CPU usage of v0.52
http://img814.imageshack.us/img814/8720/v052new2397419threads.th.png (http://img814.imageshack.us/i/v052new2397419threads.png/)

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]

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]

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.

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.

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 :eek:...& thanks madshi /
Following up my previous test (for 0.49 & 0.50) (http://forum.doom9.org/showthread.php?p=1491809#post1491809), here's my result for 0.52

* Dropped frames: 2 3 3 4 3
* GPU & CPU:
http://i6.photobucket.com/albums/y244/rain1/test052.jpg
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. :thanks:

[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]

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 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]

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.
http://img4.hostingpics.net/thumbs/mini_514393moi.jpg (http://www.hostingpics.net/viewer.php?id=514393moi.jpg)

[webs0r]

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.

http://photos.smugmug.com/photos/1251777482_josrn-O.png

Individual cores graph. (http://photos.smugmug.com/photos/1251777496_3hNQz-O.png)


-

[madshi]

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...

Would it be possible to reorder the OSD?
Done.

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!
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. :)
:)

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.

Bat file scripting isn't my strong suit, but I gave it a try
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).

0.51 seems to be working better than any other version.

No issues so far and very smooth playback :thanks:
:)

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.

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.

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.

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.

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.

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.

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.

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.

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.

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... :D

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.

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?

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.
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.

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?

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.

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.

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]

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.

:thanks:

[someone`]

Can you please retry with v0.53? Having to pause/play every time is very annoying, of course
It still happens , but i found new trick : start playback --> pause --> reopen --> smooth playback .
I got green screen with v0.53 because using too much memory , i only have 1GB .

[SamuriHL]

Just tested 0.53 on my laptop. With my 2 test files I didn't go over 60% for MPC-HC CPU usage and only had under 10 dropped frames at the very beginning. Video is smooth and looks awesome. Considering it's my laptop I expect 0 problems on my 2 HTPC's, so, for me, things are very good! Thanks for your work on this, madshi! What a great amount of improvement over the last few weeks!!

[toniash]

Have you seen this ->? http://forum.doom9.org/showpost.php?p=1492498&postcount=1331

[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).

Here are the logs madshi.

The first log is of this strange thing where the monitor changes from 95.906hz interlaced to 60hz interlaced when it jumps into exclusive mode.

This also happens to me when I install something and the screen darkens when windows asks "are you sure" - a powerstrip quirk I think.

The log plays at 60hz for a while (no drops or delays or glitches), then I pause/play and it returns to 95.906hz, still in exclusive mode, but then I get the pres glitches.

http://dl.dropbox.com/u/1372034/madVR%20-%20log%20%20v0.52%20it%20changes%20to%2060hz%2C%20then%2096hz.txt


The second log is a clean entry to exclusive at 95.906hz, but with lots of pres glitches.

http://dl.dropbox.com/u/1372034/madVR%20-%20log%20v0.52%20pres%20glitches.txt

I will try 0.53 now....I can't keep up with you!!


Edit: 0.53 is no different with the pres glitches. My render/backbuffer/present queues are all low/empty. Bilinear didn't help (I have an i7 950 and an ATi4850), ..it's got grunt. But is it possible it's not enough grunt for 96hz?

[Andy o]

(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.


You just need that TID number, besides the log? Cause process explorer takes a few seconds to update, so can I just take that TID right after I switch from exclusive to windowed?

If so, it's 2444 madVR.ax+0x8470

I'll post the log in a while.

[sneaker_ger]

Have you seen this ->? http://forum.doom9.org/showpost.php?p=1492498&postcount=1331

Yes, there's a similar project for ffdshow (https://forum.doom9.org/showthread.php?t=160371).

But frames have to be copied back on forth to the GPU, so it's less efficient than conventional DXVA.

@madshi
Thx for the new version and the changed OSD. Will test it later.

[madshi]

:thanks:
I do remember this was important for you... :p

It still happens , but i found new trick : start playback --> pause --> reopen --> smooth playback .
Hmmmm... Can I have a log, please?

Just tested 0.53 on my laptop. With my 2 test files I didn't go over 60% for MPC-HC CPU usage and only had under 10 dropped frames at the very beginning. Video is smooth and looks awesome.
So 0.53 is a noticeable improvement on your laptop? That's great to hear!

Have you seen this ->? http://forum.doom9.org/showpost.php?p=1492498&postcount=1331
Haven't seen that. I imagine it should work quite well for NVidia, but I think there might be problems with ATI.

The first log is of this strange thing where the monitor changes from 95.906hz interlaced to 60hz interlaced when it jumps into exclusive mode.
Yeah, I don't understand that, either. On my secondary monitor similar things happen. It seems that *after* I switch to the correct refresh rate, Windows suddenly reports 60Hz. So madVR says: Ok, then I'll use that. Very weird. Should be solved once I implement the automatic refresh rate changing. Oh well, maybe I should stop being such a perfectionist and implement a crude automatic refresh rate changer soon instead of waiting for the perfect solution (which will take time).

I will try 0.53 now....I can't keep up with you!!
:p

You just need that TID number, besides the log? Cause process explorer takes a few seconds to update, so can I just take that TID right after I switch from exclusive to windowed?

If so, it's 2444 madVR.ax+0x8470
Yes, that's the number I need. But the number changes every time you start a new video. And I need the number to match the log you're creating. Then I can search the log for that number.

[Andy o]

OK, I found out that you can switch the refresh to up to 10 seconds so there's plenty of time to get the info. I'll get you the log in a while, thanks.

[SamuriHL]

So 0.53 is a noticeable improvement on your laptop? That's great to hear!


Yea it seems to be. Either that or my laptop was just being stupid yesterday when testing 0.52. :) In either case, it's running quite well given the performance of this laptop overall. I haven't tried running it on my work laptop. I keep avoiding putting things on there that aren't work related because it's a powerhouse machine and I might get too comfortable using it. :D In any case, on my laptop and my 2 HTPC's I have madVR running extremely well now. I'm really quite happy.

[someone`]

My log 61MB unzip :
http://www.fileserve.com/file/gfHsw6j

Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1mn 29s
Bit rate : 13.8 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.278
Stream size : 148 MiB (95%)