madVR - high quality video renderer (GPU assisted)

[sgraves66]

I've created my own media center frontend using SDL 2.0 and use LAV filters with madVR. I create a native win32 window to host the renderer. This window is disabled and disallows focus to allow window events to be captured by the primary SDL window. When entering and leaving madVR fullscreen exclusive mode, the hosted window becomes enabled and focused, so keyboard and mouse events aren't being captured by SDL. The first time I change from windowed to exclusive, the hosted widow remains disabled, but any subsequent change back to windowed allows the renderer to be focused.

Would it be possible to add an option to keep the hosted window's styles when entering and leaving fullscreen exclusive mode? It would also be nice to see an option to fully disable keyboard shortcut processing in madVR. I'm sure most user's wouldn't need these options, but it would help my effort tremendously. The frontend is designed to use DirectShow, VLC, mplayer, mplayer2 and any additional player that supports embedding, but DirectShow is default for obvious quality reasons.

[leeperry]

BTW, here's a sample of a levels range issue I've been encountering quite a bit lately: test.mkv (2.9 MB) (https://mega.co.nz/#!Hlo0DDJS!NOrK-zgwg80AoRXZLulMagUYQ9seMA_5WLUS8mc0V1E)

Here are some screenshots showing the problem (http://www.imagebam.com/gallery/gxavm6jgyu4z6ddtg5856xdgjz28u36a/).

Basically, the auto-detected TV range looks washed out and I have to use the PC range that looks OK, but apart from some randomly pesky video files, PC range usually looks lighter than TV range so I'm kinda confused here? FFDshow shows that there is indeed life <16 but then processing a PC>TV conversion should make it darker and not lighter :confused:

Oh well, I'm not too used to 0-255 native content, maybe that's expected behavior after all :o

[TheElix]

And anyway, all those PC monitors work internally in 8bit(and more often than not 6bit, as proven by their poor REC709 gamut coverage), that's really the stone age when all serious TV's work in 12bit and videoprojectors have been working in at least 10bit for over a decade.....oh well, someday I'll find a flat screen that'll make me happy, I'm a believer :pThanks for the feedback. Personally I'm a fan of CRT image and couldn't be happier with Sony FW900 as a monitor. It offers so much compared to LCDs. Even having a great projector (Mitsubishi HC5) there are times when I miss the image my FW900 can produce.

[zeroibis]

I am actually still using a GDM-C520 but it can take up to 5-10min to start it at the beginning of the day (I think the caps are drying out or something). Well it has lasted over 10 years so far... still waiting for something better to be invented.

With the newer scaling modes really pushing many gpus hard is there any plan to offer CUDA support in the future. This could allow us to possibly use more than one low end card and still use high quality scaling.

[paradoxical]

You can do 100 revisions with 1.01, 1.02, etc. How is that unreasonable? The other option of course is to use more than one decimal point; it's more obvious that 1.1.0 is larger than 1.0.2 than 1.10 being larger than 1.2.

You still seem to be acting as if version numbers of arithmetic decimal numbers which it is not. The period is nothing but a delimiter between a major and minor version number. Also, adding a second period is usually signifying that the 3rd number is a bug fix number. So saying to use 1.0.2 instead of 1.2 doesn't really make any sense.

Think of it this way: When you type out numbers from, say, one to ten do you type 01, 02, 03, 04, etc. or do you type 1, 2, 3, 4? Each number delimited in the version number major.minor.bugfix (or whatever format used) is a distinct integer value of its own it is not a fractional number just because it's after a decimal.

End of derail.

[madshi]

I don't think it's ever been as the new rendering path would appear to cause random presentation glitches from time to time, as if mVR missed the VSYNC fliptime or something....
With the new presentation path, the GPU driver is responsible for syncing to vsync, so it's the GPU driver which misses the vsync fliptime, not madVR. Doesn't make any difference to you, but I'm not taking the blame for NVidia bugs... :p

I do get occasional ghosting and all(even though my brain seems to get used to it), but it's either this or normal 24/25p judder so pick your poison....
I'm slightly confused now. SmoothMotion FRC does not reduce 24/25p judder.

Madshi, I cannot get DXVA2 (Native or copyback) decoding through lav filters to work with madvr. The screen goes completely green after a few seconds. It does not happen with evr. Intel Quick sync decoding works fine as well. I've tried several different options within madvr with no luck.
If copyback doesn't work, either, then it can't be madVR's fault. You may want to report this in the LAV thread. If copyback doesn't work, it's nevcairiel's job to fix this.

Sometimes when I press the next arrow button rapidly when trying to find a scene in a movie the window gets "stuck" on a a few frames and just keeps repeating in exclusive mode. The audio keeps going like normal though. If I go back to windowed mode then the problem goes away but going back to exclusive mode just gives a black screen thereafter. The only resolution at that point is to restart MPC-HC. I have smooth motion on.
Having this weird problem with a random black frame appearing during a movie.
There seem to be some weird problems with SmoothMotion FRC turned on. I'll try to fix these, but since they're hard to reproduce on my PC, it will not be easy...

About SetWindowText()

I made some test - and i can say that some bug in madVR. I do some change in MPC-HC-> call SetWindowText() after graph is build, and main window Title is also broken(replace non english/locale characters with '?').
Ok, thanks, will have a look at this.

hello, i've a problem using latest version of MPC-HC stable release with madvr 0.86.1... When i try to open any video it tooks about 10 seconds to mpc to show the images. It stay with "Opening..." for 10 seconds then, the icon of madvr appears in system tray and video start reproduce without problems... how can i fix that?
That sounds weird. Is this a new problem or did it always behave this way for you? If it's a new problem, does it only occur with specific MPC-HC builds? Or what else did you change recently which might have introduced this problem?

Hi guys, i have an Acer Revo 3610 witn an Nvidia Ion gpu htpc, actually it has lots of obvious limitations, i can't do 1080p native playback and 720p upscaled to 1080 with smooth motion (i can't live without that madvr feature) on has lots of hiccups, without it i dont have any troubles, only if i upscale 720p to 1440x810 i can have a pretty decent playback with smooth motion on but i have to settle with bilinear or dxva image upscaling, my question is if i play all my 720p material without upscaling it to 1080p, it plays flawlessly even with more demanding upscaling methods, but are there really too much disadvantages if i only play in 720p with the best upscaling methods (even if i dont need them cause im not upscaling) vs 720p upscaled to 1080p or in my case 1440x810 but only with bilinear or dxva image upscaling
Well, you could switch your PC into 720p output mode and then let your TV upscale. Of course the end result will not be as nice as letting madVR do all the work, but if your GPU is so slow, you'll have to live with *some* compromise. You could also try all those "trade quality for performance" options in the madVR settings. Maybe some of those make a difference for you? But keep only those checked which you absolutely must.

I reported earlier that this mp4 trailer

http://www.hd-trailers.net/yahoo-redir.php?id=94eacdcc-ade6-35fa-aa14-5d22c8d71934&resolution=1080

gave me massive frame drops with smooth motion on. Then I said using FSE fixed it. But turned out I was wrong. It's when I zoom in the picture in MPC (hit Pan&Scan increase size about 8 times) that I get the frame drops with smooth motion on. Playing in unzoomed size or smooth motion off causes no problem. windowed/windowed overlay/FSE makes no difference.

Oddly, most stuff play fine. I don't know what's different with that video (and others).
I don't know, either, seems to work fine on my PC. You could try demuxing the video and audio tracks, and then mux the video to MKV with eac3to. Afterwards add the audio track back in with mkvtoolnix. This way you should get an MKV file with "optimal" timestamps. Maybe the timestamps in the original file are somewhat broken. This is just a wild guess, though...

My display is 1080p native but works with 720p too, i just asked in your opinion which is better, 720p with advanced upscaling methods like lanczos3 or Jinc chroma & image, vs 720p to 1080p with bilinear in both upscaling methods.
Activating Lanczos/Jinc makes no difference if you don't actually scale.

Yeah, it gives me the date of when the post was updated. Since when is that equal to the date of the latest version?
I usually only update the first post when I release a new build. So the date is usually equal to the date of the latest version. Of course there's no guarantee, I might update the first post once in a while without posting a new build - but that's rather rare.

Anyway, why is the date so important? I would imagine the version number is the key and that's visible on the first post.

madshi, is it possible to make the refreshRate file tags work even if the format isn't specified in the settings? For example, I currently only have 1080p24 as a display mode because I mostly watch films and NTSC DVDs were not triggering the change to 24hz. However, for the odd video file that I have, even if I tag it with [refreshRate=60], the display will still switch to 24hz because I don't have 1080p60 as a display mode in the settings. Is there a way you can make the filename tag override this and force the switch to whatever refreshRate is specified?
It's possible, of course, but it's not as easy as it might sound. E.g. if you use a tag [refreshRate=60] how would madVR know which resolution to switch to, if there's no such mode in the display mode changer list? This sounds like too much of a headache for me. Why don't you simply add 1080p60 to the list of supported modes?

I did upgrade the GPU, from an Nvidia GTS450 to a GTX660

Now in Windows 7 there are no issues with MadVR.

But on Windows XP, after the upgrade any video I play with MadVR shows dropped frames for like 10-15 seconds, then plays normally and after a while dropped frames appear again for the same length. If I choose other renderers videos play normally. If I choose lower settings in Madvr, delay may appear much later or not at all if the video is lower in quality.
I'd suggest to check whether the GPU is clocking down when the frame drops occur. Try forcing the GPU clocks to a fixed value with one of those tweaker tools.

Hi madshi. Can you share with us in wich new features are you working for next madVR version?
None at the moment. The next build will just contain bugfixes and minor improvements.

I don't know who else is using Intel HD Graphics here, but I just lowered my rendering times by 10 ms on this PC:

Intel i3 2100
4GB DDR3
Intel HD Graphics 2000 on latest drivers
Win 7 64-bit
latest official mpc, madvr, lav (quicksync)

madvr settings

image scaling: DXVA2
chroma scaling: bicubic75 with AR

general settings: cpu queue 8, gpu queue 4 <<< that made a tremendous difference from the default of 12/8

backbuffers: 4
present queue: 6

smooth motion: on <<< allowing me to now turn on smooth motion
Other people reported that for SmoothMotion FRC to work correctly, they had to increase the queue size. Seems this is one of those things that is different for every user, depending on OS, GPU, driver etc. Maybe the higher queue makes problems for you because the GPU is running out of RAM? Don't know...

When I play 480p and lower content and lower, my average rendering time seems to skyrocket, but when I watch 720p/1080p content, it stays at around 4-6ms depending on if i'm watching 8bit or 10bit content. Surely it should be a lot than this?
If you watch 1080p content on a 1080p display, madVR doesn't have to scale at all (except chroma), so that's a lot easier on the GPU. However, 720p content upscaled to 1080p should consume at least as much resources as 480p upscaled to 1080p, so I'm not sure what's going on there. Well, maybe the 720p content was 24fps and the 480p content might be DXVA deinterlaced to 60fps? Of course 60fps consumes 2.5x as much power as 24fps.

I also seem to be having problems with exclusive mode. Now, even though I don't particularly use it, I was just wondering why when I switch to it the playback becomes sluggish and redering time skyrockets once again?
Sounds weird. Does your laptop use the NVidia GPU or the Intel GPU for rendering? Maybe it's one of those cases where the communication between Intel <-> NVidia GPU makes problems somehow, I don't know. If you don't have any problems with windowed mode, you can simply disable exclusive mode. Although for most people it should produce better performance than windowed mode! You could also try whether the "use a separate device for presentation" option helps or not.

[madshi]

Hi everyone, I dont know if this has been mentioned before, however (although silly), can nnedi3 be used as a chroma upsampler? :D
Technically possible. Maybe some time in the future, but not anytime soon. I don't know how fast (or rather slow) it would run, though.

with some content (1080p) - my Render buffer drops to 0 - thus causing dropped frames - yet other its at a more healthy 6+

can I check that the Render buffer is GPU related not CPU related ? (I'm trying to work out where my weak link is)

I've had got set Chroma Upscaling to Jinc3 but have dropped to Spline3 which has reduced no. of instances of the buffer dropping to 0 - but not totally eliminated it

CPU is a E7400 overclocked to about 3.5

GPU is a ATI 5670 overclocked to about 900 core, 512MB GDDR5 VRAM
What is the difference between the content where the render buffer drops to 0 and that where it stays at 6+? Different framerate maybe? Or one interlaced, the other progressive, maybe? Are you using fullscreen exclusive mode? Maybe posting a screenshot of the debug OSD (Ctrl+J) when the rendering queue does to 0 might be helpful to diagnose the problem further...

Well I have no idea then, I get full present queue (3-4/4). Running Win8 pro x64 with LAV software decoding (i7-3770k) and SLI GTX Titans. 13 ms rendering, 41.7 ms frame interval, and 8.3 ms v-sync.
Why is your present queue so small? Try using a *much* higher value, unless you're short on GPU RAM. E.g. try 12. Does the present queue then still go to 0-4/12?

I got Jinc 3 tap for chroma and image upscale, is this good or should I put chroma upscale to SoftCubic?
Jinc 3 is good for quality, if your GPU is fast enough to handle it.

My main question is, I have selected "Only when needed" for smooth motion and have deleted 1080p24 on my display resolution switcher in MadVR.
If I play back 480p or 720p video fileswhich are 23.976fps will MadVR upscale to 1080P on my TV if I have disabled the display mode switcher?
If you have disabled the display mode switcher, madVR will simply use the desktop GPU mode. Whether madVR upscales or not depends on the settings of your media player. E.g. if the video is 480p and your desktop GPU mode is 1080p then madVR will upscale 480p to 1080p if you set your media player to e.g. "touch window from inside" and then switch it to fullscreen.

Just tried a 720P 24fps H264 video in exclusive fullscreen mode and Im getting around 130ms render time but in windowed fullscreen around 40ms. Putting chroma upscale and image upscale to Lanzos 4 taps does not make much of a difference.

Im using software decoding on a i5 3337U CPU with HD 4000 and Radeon 8730m dGPU.
130ms render time is *A LOT*. Much too high for fluid playback. Maybe the 8730m is too slow, I don't know. Try starting with Bilinear scaling for both chroma and image scaling. If that works fluidly, you can try using more expensive scaling algorithms. Also make sure you don't force Antialiasing and Anisotropic Filtering on in the GPU control panel. These features have no benefit for video rendering, but consume a lot of power.

I see this bug has been reported (http://bugs.madshi.net/view.php?id=53&PHPSESSID=0c5946cca8fadba8ff7cf7c2341a4c6f), but I just want to say that I have the same issue. Using the latest Intel drivers on my HD4000 (3570K) the seekbar doesn't disappear on some videos. Reverting back to the previous driver solves it.

Using same drivers as the bug report above, but I'm using MPC HC, LAV 0.57.
I can't handle bug reports that are spread across bug tracker and forum thread. If you want your feedback to be helpful, you have to add it to the bug tracker report you mentioned.

madshi, it seems that "disable GPU gamma ramp" stopped working. This isn't an issue exclusive to my system: http://www.avsforum.com/t/1471169/madvr-argyllcms
Did you add this to the madVR bug tracker?

Hi, I'm using madvr with success for months (Intel HD4000 9.18.10.3111) and I'm experiencing an issue the exclusive mode tag, upper left, is fixed no way to made it disappear. Same for rendering info (CTRL+J) no way to trash them, if I try the portion on the black zone seem to be fixed instead the part over the video disappear. The issue was present also with previous Intel driver. Someone can help me?? :(
Did you add this to the madVR bug tracker?

The latest drivers also cause some serious juddering with smooth motion enabled.
Did you add this to the madVR bug tracker?

@6233638 (and any other scaling maniac :P)

I just assembled an htpc for a friend that has the most awfull collection of avi & divx ever seen.
Right now i use MN for chroma, Softcubic80 for luma.
Any better recommendation for such material.
My main goal is to hide compression artifacts.
For hiding artifacts I'd suggest SoftCubic. Of course it'll be blurrier than other scalers. You could also try setting up some AviSynth noise/artifact reduction scripts, if his CPU is fast enough for that. Or alternatively some custom shaders (they're not as good in quality as better AviSynth scripts, though)...

I have to say - big thanks to the developers of MadVR - as I'm finding the 24-60hz processing much better for motion etc than my internal 24hz processing on my TV

my TV is a Panasonic PF11 (pro-panel) - and it displays 24p as pure 24hz - should be pretty perfect - but for some reason the MadVR processed to 60 looks a lot better :)
Good to hear! :)

On Windows 7 64 bit does having Aero turned on or off effect the playback quality of mVR? I mean does it effect it (better or worse) with stuttering/delayed/dropped frames etc?
Having it off might introduce tearing. If you don't have tearing with it turned off, then there should be no difference. Aero adds a little bit of additional GPU consumption, so performance with it off might be slightly better. Of course in fullscreen exclusive mode or when using Overlay, it doesn't matter whether Aero is on or off.

Im kinda annoyed lol
This is a new laptop with Radeon 8730M but cant use that card for MadVR as in exclusive mode I get 5 times slower rendering then windowed mode! As its switchable graphivs only solution is to use HD4000 but with that I can only use Lanz3 and BiCubic 75 and I get around 30 - 35ms render for 720P to 1080P.
Not sure why you get 5x slower rendering in FSE mode. Makes no sense to me. You could try activating the "use a separate device for presentation" option. That helps some people, but I've heard it makes problems with some laptops with shared GPUs. Maybe it helps you, or maybe not. You could also try checking whether the AMD GPU clock goes down in exclusive mode for some weird reason. If it does, try to use a tweaker to fix it to a reasonably high clock.

It is possible that in exclusive mode your AMD renders the frame, then has to send it to the Intel GPU for output. Maybe that is so slow for some reason. But I don't really know...

Madshi, are you close to release a new update or is there nothing to expect in the next couple of weeks ??
There should be a new bugfix build sooner or later, but no big new features.

I've created my own media center frontend using SDL 2.0 and use LAV filters with madVR. I create a native win32 window to host the renderer. This window is disabled and disallows focus to allow window events to be captured by the primary SDL window. When entering and leaving madVR fullscreen exclusive mode, the hosted window becomes enabled and focused, so keyboard and mouse events aren't being captured by SDL. The first time I change from windowed to exclusive, the hosted widow remains disabled, but any subsequent change back to windowed allows the renderer to be focused.

Would it be possible to add an option to keep the hosted window's styles when entering and leaving fullscreen exclusive mode? It would also be nice to see an option to fully disable keyboard shortcut processing in madVR. I'm sure most user's wouldn't need these options, but it would help my effort tremendously. The frontend is designed to use DirectShow, VLC, mplayer, mplayer2 and any additional player that supports embedding, but DirectShow is default for obvious quality reasons.
This sounds like a weird design, having a renderer window which is disabled, to allow a different window to process keyboard events. Why don't you use this instead:

http://msdn.microsoft.com/en-us/library/windows/desktop/dd377323(v=vs.85).aspx

[leeperry]

With the new presentation path, the GPU driver is responsible for syncing to vsync, so it's the GPU driver which misses the vsync fliptime, not madVR. Doesn't make any difference to you, but I'm not taking the blame for NVidia bugs... :p
You've made very clear that the nvidia drivers are the cause of the random hiccuping with the new rendering path on XP, but the old one has always worked flawlessly with my 8800GS so as long as you leave it there all is well :cool:

Well, I guess I would have to try a 660 myself with the old rendering path.....but the 700 serie is bound to arise and I have yet to find a 1080p LCD screen that'd make me happy, so it might very well take me half a decade to upgrade until OLED would finally hit stores(at reasonable prices :sly:)

I'm slightly confused now. SmoothMotion FRC does not reduce 24/25p judder.
Well, when I enable FRC in 90/96Hz I don't get the nasty 24/25p judder anymore for sure.......it's a hell lot smoother, the pop effect is drastically increased as well and it's just a real treat to look at. I think SVP also has a frame rate conversion option, not just interpolation....It would appear to me that you are making the movements smoother due to (mostly) imperceptible perfectly synchronized blending/"ghosting". I'm really hooked to it now!

BTW, you didn't answer me on my 0-255 source levels report (http://forum.doom9.org/showpost.php?p=1630801&postcount=18905), is that expected behavior at all :confused:

:thanks:

[nekromantik]

130ms render time is *A LOT*. Much too high for fluid playback. Maybe the 8730m is too slow, I don't know. Try starting with Bilinear scaling for both chroma and image scaling. If that works fluidly, you can try using more expensive scaling algorithms. Also make sure you don't force Antialiasing and Anisotropic Filtering on in the GPU control panel. These features have no benefit for video rendering, but consume a lot of power.


I think its as its switch able graphics I am unable to use the AMD card. The 8730M is much faster then then HD4000 which I am forced to use. According to system minitor the amd card gets activated but for some reason its always 100ms+ on FSE mode.
On HD4000 I am getting 25 - 30ms upscaling 720P to 1080P using Jinc3 and Softcubic 100.
I need modified drivers to make the AMD card work.

[karamancho]

Why is your present queue so small? Try using a *much* higher value, unless you're short on GPU RAM. E.g. try 12. Does the present queue then still go to 0-4/12?

4 is the default value for the number of frames presented in advance. I tried 12 but the queue still remains empty (0-12/12)

[sgraves66]

This sounds like a weird design, having a renderer window which is disabled, to allow a different window to process keyboard events. Why don't you use this instead:

http://msdn.microsoft.com/en-us/library/windows/desktop/dd377323(v=vs.85).aspx

It's actually a generic workaround to support external media players that don't allow me to specify a message drain, only a window handle, but thanks for the suggestion. I've only recently added support for DirectShow and completely forgot about that method. It doesn't just host media players, but also game emulators, screen savers, etc. Disabling the window works 99% of the time, so I've stuck to this simple pattern for many reasons.

[madshi]

BTW, here's a sample of a levels range issue I've been encountering quite a bit lately: test.mkv (2.9 MB) (https://mega.co.nz/#!Hlo0DDJS!NOrK-zgwg80AoRXZLulMagUYQ9seMA_5WLUS8mc0V1E)

Here are some screenshots showing the problem (http://www.imagebam.com/gallery/gxavm6jgyu4z6ddtg5856xdgjz28u36a/).

Basically, the auto-detected TV range looks washed out and I have to use the PC range that looks OK, but apart from some randomly pesky video files, PC range usually looks lighter than TV range so I'm kinda confused here?
Not sure what you did there. On my PC your sample behaves as expected. Meaning: PC range looks lighter than TV range. Maybe ffdshow has screwed up somehow. I didn't have ffdshow in the chain.

I think its as its switch able graphics I am unable to use the AMD card. The 8730M is much faster then then HD4000 which I am forced to use. According to system minitor the amd card gets activated but for some reason its always 100ms+ on FSE mode.
Have you tried the option "use a separate device for presentation"? Not sure if it works at all in your case, but it might be worth a try. In any case, do you need FSE mode? Maybe windowed mode works ok for you?

I need modified drivers to make the AMD card work.
Maybe, I don't know.

4 is the default value for the number of frames presented in advance. I tried 12 but the queue still remains empty (0-12/12)
What is your GPU, your OS and your GPU driver? What is your display refresh rate? Your movie fps? And do you have Smooth Motion FRC turned on or off? A screenshot of the debug OSD (Ctrl+J) in the moment when the presentation queue is empty might be helpful.

[madshi]

It's actually a generic workaround to support external media players that don't allow me to specify a message drain, only a window handle, but thanks for the suggestion. I've only recently added support for DirectShow and completely forgot about that method. It doesn't just host media players, but also game emulators, screen savers, etc. Disabling the window works 99% of the time, so I've stuck to this simple pattern for many reasons.
I understand. The problem for fullscreen exclusive mode is that madVR tries to make it work for any media player, regardless of whether it's aware of it or not. And it does work for all the media players out there (that I'm aware of) - seemingly except yours. If you can make do with the IVideoWindow method I suggested that would be welcome, then I don't have to change madVR. I'd like to avoid changing madVR's behaviour for just one media player. It might result in follow up problems with other media players...

[sgraves66]

I understand. The problem for fullscreen exclusive mode is that madVR tries to make it work for any media player, regardless of whether it's aware of it or not. And it does work for all the media players out there (that I'm aware of) - seemingly except yours. If you can make do with the IVideoWindow method I suggested that would be welcome, then I don't have to change madVR. I'd like to avoid changing madVR's behaviour for just one media player. It might result in follow up problems with other media players...

Completely understand. I doubt that mine will ever be seen outside of my home, anyways. It's taken years to develop and is constantly in motion. I'd need more developers to make it publicly available.

put_MessageDrain didn't seem to improve anything. madVR does work fine in most cases, but the mouse wheel seems to give me the most issues, plus some overlapping keyboard shortcuts between the frontend and madVR. The later is easily solved and there may be an issue within SDL 2.0 causing the intermittent loss of the mouse wheel. Disabling the window just seems to care of all these issues in a simple manner.

The fronted is primary controlled by bluetooth remote and/or joystick, anyways, so it's rare that a mouse is actually used.

[leeperry]

Not sure what you did there. On my PC your sample behaves as expected. Meaning: PC range looks lighter than TV range. Maybe ffdshow has screwed up somehow. I didn't have ffdshow in the chain.
I only used ffdshow to check the levels, the very same problem occurs with LAV alone.....apparently it's due to my gamut mapping PS scripts(used as post-scaling in PotP):
// script=ps_3_0
// Code from MPC

sampler s0 : register(s0);
float4 p0 : register(c0);

static float4x4 r2r =
{
1.07521105249278,-0.0851867514203263,-3.55175263678786E-05,0,
-0.0256692518211088,1.06388788724376,-0.0340832039107225,0,
-0.0112108076565148,0.019277609404304,0.985946849621001,0,
0, 0, 0, 0
};

float4 main(float2 tex : TEXCOORD0) : COLOR
{
float4 c0 = tex2D(s0, tex);
c0 = pow(c0, 1/0.45);
c0 = mul(r2r, c0);
c0 = saturate(c0);
c0 = pow(c0, 0.45);

return c0;
}
Could it be that your BTB/WTW expanding "trick" gives the aforementioned issue if there originally was data in those areas somehow? Or maybe it's just not compatible with what this PS script expects? How could I fix it then please? :o

If I don't enable this PS script, then indeed PC is lighter than TV on this sample and this PS script works fine on 16-235 content.

[nekromantik]

Have you tried the option "use a separate device for presentation"? Not sure if it works at all in your case, but it might be worth a try. In any case, do you need FSE mode? Maybe windowed mode works ok for you?


Yes I tried that.
That breaks playback, I get blank screen but with audio.

With windowed mode and AMD card I still get around 50 - 60ms rander times and its jittery and lots of frame drops.
The card is not been utilized properly, gaming works fine. I think I need to stick with HD4000.

[karamancho]

What is your GPU, your OS and your GPU driver? What is your display refresh rate? Your movie fps? And do you have Smooth Motion FRC turned on or off? A screenshot of the debug OSD (Ctrl+J) in the moment when the presentation queue is empty might be helpful.

NVIDIA Quadro NVS 135M
Windows 7 ultimate sp1 32bit
drivers ver. 320.00
display 59.87547Hz
movie 23.976 fps
smooth motion off

since the 'display several frames in advance' only works in FSE mode a screenshot of the debug OSD isn't possible

[Asmodian]

You might be running out of video memory? Is it a 128MB or 256MB NVS 135M?

You can check video memory usage with GPU-Z. You might also take a look at how much memory bandwidth you are using while you are in there, 9.6GB/sec is pretty low for MadVR.

[karamancho]

memory size: 128 MB
bandwidth: 9.5 GB/s

[Asmodian]

How much video RAM is used when running MadVR?

[karamancho]

avg. 100 on SD, avg. 120 on 720p

[Asmodian]

Well that makes sense, even just one frame of 8bit RGB 720x480 video is 8.3MB so you don't have enough video RAM for the present queue.

[madshi]

Completely understand. I doubt that mine will ever be seen outside of my home, anyways. It's taken years to develop and is constantly in motion. I'd need more developers to make it publicly available.

put_MessageDrain didn't seem to improve anything. madVR does work fine in most cases, but the mouse wheel seems to give me the most issues, plus some overlapping keyboard shortcuts between the frontend and madVR. The later is easily solved and there may be an issue within SDL 2.0 causing the intermittent loss of the mouse wheel. Disabling the window just seems to care of all these issues in a simple manner.

The fronted is primary controlled by bluetooth remote and/or joystick, anyways, so it's rare that a mouse is actually used.
Well, I guess you could create a thread which disables and de-focuses your window once every second. Wouldn't that workaround the problem?

I only used ffdshow to check the levels, the very same problem occurs with LAV alone.....apparently it's due to my gamut mapping PS scripts(used as post-scaling in PotP).

Could it be that your BTB/WTW expanding "trick" gives the aforementioned issue if there originally was data in those areas somehow? Or maybe it's just not compatible with what this PS script expects? How could I fix it then please? :o

If I don't enable this PS script, then indeed PC is lighter than TV on this sample and this PS script works fine on 16-235 content.
Don't know why the script would make problems. Do the same problems occur when using the same script in MPC-HC?

Yes I tried that.
That breaks playback, I get blank screen but with audio.

With windowed mode and AMD card I still get around 50 - 60ms rander times and its jittery and lots of frame drops.
The card is not been utilized properly, gaming works fine. I think I need to stick with HD4000.
That sounds weird to me. So it seems your AMD card is slower than the HD4000 when using madVR, is that correct? But is it (much) faster than the HD4000 for gaming? I don't really understand why it would be slower for madVR, but faster for gaming, because madVR mostly works similar to a game...

Does your AMD card have on-board RAM for video? Or does it use a part of your system RAM? How much RAM does it have? Maybe it's running out of RAM, similar to problem karamancho seems to have?

Well that makes sense, even just one frame of 8bit RGB 720x480 video is 8.3MB so you don't have enough video RAM for the present queue.
Yeah, that makes sense! @karamancho, try to decrease the GPU queue and present queue to lower values. E.g. try using 4 for both. Then check how much RAM is used.

[petran79]

In order to revert to the old rendering path, you need to uncheck "present several frames in advance" in the /rendering/exclusive mode settings/ tab and it would also help to check "use managed upload textures (XP only)" in the /rendering/general settings/ tab as that latter option would smoothen windowed/FS changes IME. I've tried the new rendering path on several occasion but it would very often hiccup right after skipping when OTOH the old one has always worked perfectly for me.

you also seem to imply that CUVID hardware acceleration in LAV would be part of the issue, so how about software decoding then?

some additional feedback would be greatly appreciated please if you got time to run more tests. :thanks:

Unfortunately video continues to show occasional frame drops, even after checking those options.

Usually that happens a few seconds after loading the video, then video runs smooth, then another frame drop occurs after few seconds.

the odd thing is that it happens on particular video parts, usually in the part where bitrate peeks. Even if I start the video exactly from where the drop occured, it happens again.
When I set the slider to a part with lower bitrate, video plays smoothly.

Even with these options enabled or disabled, same thing happens again.

[truexfan81]

madshi i am trying to respond to you on the bug tracker but its not working, i type a response, click the "add note" button and nothing happens

edit: i wonder if this is a google chrome bug, will try firefox, see if it works

[madshi]

Unfortunately video continues to show occasional frame drops, even after checking those options.

Usually that happens a few seconds after loading the video, then video runs smooth, then another frame drop occurs after few seconds.

the odd thing is that it happens on particular video parts, usually in the part where bitrate peeks. Even if I start the video exactly from where the drop occured, it happens again.
When I set the slider to a part with lower bitrate, video plays smoothly.

Even with these options enabled or disabled, same thing happens again.
This sounds like the decoder (= your CPU?) is not fast enough. Enable the madVR OSD (Ctrl+J) and check the state of the decoder queue when the frame drop occurs. Is it nearly empty in that situation? Or is it near full?

madshi i am trying to respond to you on the bug tracker but its not working, i type a response, click the "add note" button and nothing happens

edit: i wonder if this is a google chrome bug, will try firefox, see if it works
Please make sure you're logged in. You can read the bug tracker without being logged in, but you have to be logged in to change anything.

[truexfan81]

This sounds like the decoder (= your CPU?) is not fast enough. Enable the madVR OSD (Ctrl+J) and check the state of the decoder queue when the frame drop occurs. Is it nearly empty in that situation? Or is it near full?


Please make sure you're logged in. You can read the bug tracker without being logged in, but you have to be logged in to change anything.

i was logged in, it apparently does not like google chrome, i was able to comment using firefox

[madshi]

Using chrome myself. Works fine here.

[truexfan81]

oh madshi i have been having a weird issue lately, but i think maybe its an nvidia bug. every couple of days madvr reports "gpu/driver does not support overlays." only way to fix it is to reinstall the nvidia driver and then reinstall madvr (a reboot does not even make the error go away) this has happened with nvidia 320.14 and 320.18. so i'm tempted to revert back to 320.00 to see if the problem goes away.

[madshi]

Sounds like a driver problem to me. madVR asks Direct3D whether overlay is supported. Seemingly in your case sometimes Direct3D thinks/reports it's not supported, for whatever reason...

[pie1394]

That sounds weird to me. So it seems your AMD card is slower than the HD4000 when using madVR, is that correct? But is it (much) faster than the HD4000 for gaming? I don't really understand why it would be slower for madVR, but faster for gaming, because madVR mostly works similar to a game...



That indeed sounds weird..


HD8730M is 384 cores @ 650 MHz 128 Bit @ 1000 MHz DDR3
It should be more than enough for Lanczos3 scaling if deinterlacing job is not required.


As I know, some NB vendors choose the cost-down solution to wire some particular output port(s) like LVDS / TMDS to only 1 GPU, not both via the switching IC. The usual design is always to use Intel GPU to send out all video signals while AMD/nVidia GPU is the active one. So extra framebuffer copy back from dGPU to iGPU is always required and it creates extra latency.

Maybe it would work if all FLUSH settings are turned OFF?

[nekromantik]

That indeed sounds weird..


HD8730M is 384 cores @ 650 MHz 128 Bit @ 1000 MHz DDR3
It should be more than enough for Lanczos3 scaling if deinterlacing job is not required.


As I know, some NB vendors choose the cost-down solution to wire some particular output port(s) like LVDS / TMDS to only 1 GPU, not both via the switching IC. The usual design is always to use Intel GPU to send out all video signals while AMD/nVidia GPU is the active one. So extra framebuffer copy back from dGPU to iGPU is always required and it creates extra latency.

Maybe it would work if all FLUSH settings are turned OFF?

Yes the actual output to the screen is via the Intel card, the AMD is only there as a processor type card. So all data goes through 2 cards to get outputed. Will try no flushing.
Do you think Jin3 would be too much for the card?
As with Intel I can do Jinc3 image and Softcubic no AR 100 on chroma.
Thanks

[leeperry]

Don't know why the script would make problems. Do the same problems occur when using the same script in MPC-HC?
The script works fine with that 0-255 sample in EVR using PotP 1.5.3776 and MPC-HC 1.6.7.7069 but it looks equally too bright with madVR in both players...strangely the problem doesn't occur on 16-235 source files, it really only happens when they are 0-255(even if it's just padding data and not actual video content)....which would explain why I've randomly encountered this problem :o

Hope you can look into it and lemme know if I should add it to the bug tracker or something, :thanks:

Even with these options enabled or disabled, same thing happens again.
I've got a remuxed BD with high bitrate that would exhibit the problem you're describing but I can force software decoding with ffdshow(libavcodec) instead of LAV/CUVID and presto! all is well.....the GPU doesn't take care of the video decoding anymore so its bitrate doesn't matter, doesn't that fix the issue for you as well :confused:

[pie1394]

Yes the actual output to the screen is via the Intel card, the AMD is only there as a processor type card. So all data goes through 2 cards to get outputed. Will try no flushing.
Do you think Jin3 would be too much for the card?
As with Intel I can do Jinc3 image and Softcubic no AR 100 on chroma.
Thanks

Without deinterlacing job and anti-ring option, Jinc3 might be ok up to 30 fps on HD8730M.

I have a HD7970 which is 950 Mhz 2048 GCN core + 384-bit DDR5-5500. Its performance should be at least 7 times as fast as HD8730M's.

The estimated maximum performance for 1440x1080i content to 1920x1080p with Luma/Chroma Jinc3+AR scaling is about 120~150 fps and 60 interlaced frames' vector-adaptive deinterlacing job per second.

In reality, there is no such content. Unless madshi designs some other useful features (any in-progress? :D ) which require more computation power than Jinc3+AR mode, the GPU with near 1000 GCN / Kepler CUDA cores, or 384 Fermi CUDA cores should be enough for real-world contents up to 4K 60 fps.

[madshi]

For those having problems with newer Intel GPU drivers...

It seems that Intel drivers 9.18.10.3071 (and .3111) have a bug which occurs when using the madVR option "use a separate device for presentation". You have 2 choices: Either go back to older drivers. Or disable that madVR option. FWIW, I've notified my Intel contact about this, but I've no idea how fast they'll fix this.

The script works fine with that 0-255 sample in EVR using PotP 1.5.3776 and MPC-HC 1.6.7.7069 but it looks equally too bright with madVR in both players...strangely the problem doesn't occur on 16-235 source files, it really only happens when they are 0-255(even if it's just padding data and not actual video content)....which would explain why I've randomly encountered this problem :o

Hope you can look into it and lemme know if I should add it to the bug tracker or something
From what I can see madVR does its job correctly. Fullrange content is converted properly *before* the custom pixel shaders are executed. Do you have any "trade quality for performance" options activated? If so, try to check whether unchecking them helps.

You could also try whether replacing "float4 c0 = tex2D(s0, tex);" with "float4 c0 = tex2D(s0, tex); saturate(c0);" makes any difference. Probably not, but maybe worth a try...

[DragonQ]

Most web pages relating to drivers for "3rd Generation Intel Core Processors with Intel HD 4000/2500 Graphics" are error pages anyway, for me at least. Their automatic updater never does anything either. :rolleyes:

I'm sure I managed to find the download page for the 9.18.10.3071 drivers last week via Google but I didn't save it lol.

[nevcairiel]

3071 for Ivy Bridge is here:
x86: https://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=22610
x64: https://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=22605

[DragonQ]

So what's the difference between 9.17.10.3071 and 9.18.10.3071? Is one for desktops and one for laptops?

[ajp2k11]

So what's the difference between 9.17.10.3071 and 9.18.10.3071? Is one for desktops and one for laptops?

Some unreleased Intel/AMD stuff here...

asder00.blogspot.se

[leeperry]

Do you have any "trade quality for performance" options activated? If so, try to check whether unchecking them helps.

You could also try whether replacing "float4 c0 = tex2D(s0, tex);" with "float4 c0 = tex2D(s0, tex); saturate(c0);" makes any difference.
OK, thanks for the help but I don't have any "trade quality for performance" option checked and changing those lines didn't help either :(

BTW, problem is identical whether it's used before or after scaling.

[Yups]

So what's the difference between 9.17.10.3071 and 9.18.10.3071? Is one for desktops and one for laptops?


This is the same driver, there is no 9.17.10.3071, that's just a mistake from Intel.

[karamancho]

try to decrease the GPU queue and present queue to lower values. E.g. try using 4 for both. Then check how much RAM is used.

video memory usage decreased by about 20 mb but the present queue still stays empty

btw. enabling smooth motion results in render queue 1-3/4 (and 1-3/8 when gpu queue set to 8)

[ryrynz]

There seems to be an issue filling the present queue (at least for me) on the HD 4000. As I reported in the bugtracker increasing the FSE frames in advance and continuing playback without restarting the player the present queue fills better.
I am wondering if this is another limitation of Intel's driver or something MadVR can do better in regards to the present queue.

For those having problems with newer Intel GPU drivers...

It seems that Intel drivers 9.18.10.3071 (and .3111) have a bug which occurs when using the madVR option "use a separate device for presentation".


*update* I've just upgraded to the .3190 drivers from the site ajp2k11 linked (asder00.blogspot.se) us and the bug I informed Madshi about above has been fixed. This update is available for both Ivy and Sandy Bridge processors and use the older non tile based UI.

My present queues in FSE are still low 0/4-1/4 and nothing I change improves that but haven't had any glitches or drops. Windowed mode and it's backbuffers fill just fine.

[sgraves66]

Well, I guess you could create a thread which disables and de-focuses your window once every second. Wouldn't that workaround the problem?

I was thinking about trying something similar, but the mouse wheel issue is a bit more complicated. I would explain more, but it's a bit off topic. Don't want to take too much time away. Thanks for the suggestion.

On a different note, is there something special that needs to be done to display the seek bar in madVR? I simply query IAMStreamSelect on the filter graph to perform absolute positioning. i.e:

this.MediaSeeking.SetPositions(DsLong.FromInt64(next), AMSeekingSeekingFlags.AbsolutePositioning, DsLong.FromInt64(0), AMSeekingSeekingFlags.NoPositioning);

Unlike MPC-HC, the seek bar doesn't show. I do have it enabled it in settings (rendering\exclusiveSettings\enableSeekbar). I planned to look through MPC source, but figured I'd ask here. It's been 4-5 years since working with DirectShow, so I'm sure I'm overlooking something obvious.

Playback quality is unsurpassed with madVR. Between this and LAV filters, it's the combination I've been searching for since the late 90's, early 2000's. Thanks so much for the hard work.

[madshi]

OK, thanks for the help but I don't have any "trade quality for performance" option checked and changing those lines didn't help either :(

BTW, problem is identical whether it's used before or after scaling.
Then I don't know where the problem comes from. I don't think it's madVR's fault, but then who knows?

video memory usage decreased by about 20 mb but the present queue still stays empty

btw. enabling smooth motion results in render queue 1-3/4 (and 1-3/8 when gpu queue set to 8)
Don't know why this happens. You could try re-installing the GPU drivers, just as a test. If that doesn't help, you could create a debug log, covering maybe 30 seconds of playback and upload it somewhere (zipped, please) for me to look at. Maybe I can see something...

There seems to be an issue filling the present queue (at least for me) on the HD 4000. As I reported in the bugtracker increasing the FSE frames in advance and continuing playback without restarting the player the present queue fills better.
I am wondering if this is another limitation of Intel's driver or something MadVR can do better in regards to the present queue.
As I mentioned in the bug tracker, I can't reproduce this issue on my HD4000 (win8 x64). My present queue fills perfectly fine. Without being able to reproduce the issue, it's going to be hard to do anything about it. Maybe a debug log (30 seconds of playback) could help shine some light on this, but I have my doubts...

*update* I've just upgraded to the .3190 drivers from the site ajp2k11 linked (asder00.blogspot.se) us and the bug I informed Madshi about above has been fixed. This update is available for both Ivy and Sandy Bridge processors and use the older non tile based UI.
Interesting!

On a different note, is there something special that needs to be done to display the seek bar in madVR?
In theory it should automatically appear if the mouse cursor moves to the bottom of the screen. Maybe the madVR rendering window doesn't get the mouse events if the window is disabled? If so, you could try forwarding the mouse move messages to the madVR rendering window...

[ryrynz]

Without being able to reproduce the issue, it's going to be hard to do anything about it. Maybe a debug log (30 seconds of playback) could help shine some light on this, but I have my doubts...


As requested, a 30 second log (https://mega.co.nz/#!jVRQVIhQ!QSDN61ONhGk6563L8o8ph0E6df0iwVFVNDfBZaAnR7c).

At 17 seconds I increased the exclusive mode frames to be rendered in advance from 4 to 8, hope you find something.

*EDIT* Solved.

[petran79]

This sounds like the decoder (= your CPU?) is not fast enough. Enable the madVR OSD (Ctrl+J) and check the state of the decoder queue when the frame drop occurs. Is it nearly empty in that situation? Or is it near full?



this is what happens.
I play an anime Opening (AVC, 720x480, 29.97 fps) though this happens also later in the episode.

for a few seconds or even for 1 minute, at that said scene "display" goes at 0000000 Hz instead of 59

decoder queue is normal at 11-12. frames drop. queue number doesnt change. But after video goes smooth again, que peaks gradually, reaches 45-52/12 max. then gradually drops to normal level.

I have an i3 560 at 3.3 Ghz. It should be fine for that kind of video or for any video. On Windows 7 there are no issues. It can play all videos, even 10-bit HD with Jinc3, just fine.

Problem lies in how the CPU and GPU handle threads in Windows XP. Probably Nvidia didnt bother with XP support that much. Because the much weaker GTS450 I replaced, played videos just fine with MadVR.



I've got a remuxed BD with high bitrate that would exhibit the problem you're describing but I can force software decoding with ffdshow(libavcodec) instead of LAV/CUVID and presto! all is well.....the GPU doesn't take care of the video decoding anymore so its bitrate doesn't matter, doesn't that fix the issue for you as well :confused:

Same issue, whether I use ffdshow or LAV. Even if I use all trade quality for performance options in Madshi, same problem occurs.

Plus there is also tearing if I dont use exclusive mode.
I guess I'll stick to VLC for Windows XP.

[madshi]

As requested, a 30 second log (https://mega.co.nz/#!rZRmDKYC!UzueaX-RRmeH7Qr215yFulkVaDdmqvDNxqhl2NO3YiA).

At 17 seconds I increased the exclusive mode frames to be rendered in advance from 4 to 8, hope you find something.
Are you sure that's the correct download link? It says "Tribute Album.rar (458.4 MB)".

for a few seconds or even for 1 minute, at that said scene "display" goes at 0000000 Hz instead of 59
Oh, that. Yeah, sounds like a GPU driver issue. madVR highly depends on being able to get up-to-date vsync information all the time. If the display goes to 0000000 Hz that means that the GPU driver isn't reliably providing vsync information. There's probably not much I can do about it, sadly...

News about the Intel driver problems:

The Ivy Bridge / Sandy Bridge driver series (begins with version number 15.28) does not have any problems with madVR. The latest driver from this series is 15.28.17.64.3190. However, the new Ivy Bridge / Haswell driver series (begins with version number 15.31) *does* have a bug which results in visible artifacts when using the madVR option "use a separate device for presentation". The latest driver from this series is 15.31.11.64.3186 and it still has the bug.

So Ivy Bridge users: Either stay with the Ivy Bridge / Sandy Bridge driver series until Intel has fixed the problem, or alternatively turn off the madVR option "use a separate device for presentation". Haswell users: You have no other choice than to disable the mentioned madVR option for now...

You will know which driver is from which series by looking at the GUI. The new Haswell drivers have a different GUI.

[leeperry]

Then I don't know where the problem comes from. I don't think it's madVR's fault, but then who knows?
Oh lol, OK.....so basically we put my levels problem with PS scripts in the "known issues" drawer and that's it? :(

FWIW the aforementioned script (http://www.avsforum.com/t/912720/color-correction-with-a-htpc-simpler-solution-and-now-it-really-works) has always worked fine with VMR9 & EVR in MPC/PotP/KMP(using stolen code from MPC I presume) and even through this Avisynth PS script wrapper (http://forum.doom9.org/showthread.php?t=87295) in FFDshow.

Sadly the only application from this list that comes with a source code is MPC and even if I were to ask JohnAd(who wrote the gamut mapping PS script, using 3DLUT code from yesgrey) for help, he wouldn't be able to look at what mVR does either :(

I remember you saying that MPC wasn't applying PS scripts properly on BTB/WTW but quite frankly I've never seen anything wrong with test patterns so would that be possible that you'd apply PS scripts exactly as they are in MPC pretty please? Or at least provide a "MPC broken PS script implementation compatibility fix"? :o

I realize that you said it was broken by design, but it gets the job done you know.....and all the apps previously mentioned use the exact same approach as MPC, which is the original spec that needs to be abiden with.....broken or not.

I'm entirely willing to believe that it was partially broken in the first place but it now randomly processes a levels conversion, how broken is that really http://forum-images.hardware.fr/images/perso/mlc.gif

I was under the impression that the whole plan was to get mVR to apply PS scripts exactly as they are in MPC.......why not creating a new PS script spec if the current one is REALLY broken but still allow the old scripts to work as they've always had in MPC(and other apps abiding by the exact same specs) :confused:

I could also look for other scripts that don't work in mVR as they do in MPC but tbh this gamut mapping script is prolly the most important one to many people so it's a major bummer to see it processing a levels conversion randomly.....and it's so darn convenient to be able to create automatic profiles in PotP that roll gamuts on the fly =(

:thanks:

there is also tearing if I dont use exclusive mode.
I guess I'll stick to VLC
Oh, tearing now? Never had any with mVR....either way, thanks for the report!

[ryrynz]

Are you sure that's the correct download link?

*EDIT* Don't worry found the cause of the issue with the queue.