madVR - high quality video renderer (GPU assisted)

[Siso]

Madshi,
is it possible to add an option like the one "zoom small black bars away"(which works very good on 21:9 displays for 2.35:1, 2.39:1, 2.40:1 ratios),a new option which crops the picture, in other words some sort of smart crop feature?

[madshi]

Originally Posted by baii

Having problem with render queue not filling(stuck at 1-2 and frame drops) after pasue(s),where using stop and play again will fix the issue. This is on amd and windows 10. Any way I can track the issue with log or w.e? The are no crash etc.

Things like this can very hard to debug. Have you tried toggling/modifying all those countless rendering options in madVR? My first suggestion would be to restore the standard settings. If that doesn't help, try increasing or decreasing the queue size or the number of prepresented frames. Does this only occur in fullscreen exclusive mode or also in windowed mode? Primary or secondary display?

Originally Posted by clsid

This should help solve the batch script problems:
https://sites.google.com/site/eneerg.../batchgotadmin

Thanks. When researching all this I've seen this solution, too, but creating a temp vbs script file sounded quite scary to me. Isn't scripting also disabled on some (many?) PCs for security reasons?

Originally Posted by XRyche

Actually, I forgot to rename the files back to their original names after the last debug.......oops again. Maybe I should make the word "oops" part of my signature.

Anyway, here are the three separate debug logs: http://www.mediafire.com/download/8o...3_FSE-_log.zip ,http://www.mediafire.com/download/w2...2CFSE-_log.zip ,http://www.mediafire.com/download/uj...r_FSE-_log.zip . Just to reiterate, the long delay only happens with image doubling and that's why I used Super-xbr in one of the debug sessions.

Thanks. The good news is that all those logs have the same problem: It's still the NNEDI3 kernel compilation. It seems that I'm compiling the kernel even if you use super-xbr or NEDI instead of NNEDI3. I'll fix that for the next build, so then you should hopefully be able to use super-xbr or NEDI without delay. But I would still like to find out why the NNEDI3 kernel is recompiled on your PC every single time. That's not right, either.

The bad news is that the logs are still created by the old build, not the special build I made for you. To be honest, I'm not sure if it's my fault or yours. Maybe I just sent you the wrong build or something. Can we make one last try:

1) Install standard v0.89.3.
2) Extract the XRyche special build I uploaded and linked to earlier.
3) Simply copy the special build into the madVR folder and overwrite the old file.
4) Create the log.

No file renamings at any time. No batch files. Nothing. After you're done, reinstall standard v0.89.3.

Originally Posted by dansrfe

I was referring to the 'apply SuperRes first' checkbox in the upscaling refinement section.

Please always quote me (the part that replies to you), otherwise I have to manually search through the thread to find the related posts. Thanks.

Originally Posted by dansrfe

What is the quality difference between applying SuperRes before/after image upscaling? Is this difference only visible when upscaling 2x or more?

The "apply SuperRes first" option defines whether madVR first applies SuperRes and afterwards e.g. AdaptiveSharpen, or the other way round. According to my own tests it probably makes more sense to apply SuperRes first because the other way round means that SuperRes often undoes what AdaptiveSharpen did. But in the end, it's your choice.

Originally Posted by dansrfe

I'm watching Interstellar and when going from 2.41 => 16:9 it flickers for a fraction of a second when it disables the crop. Is it plausible to disable the crop one second prior to rendering a larger frame?

I'm seeing zero flickering here. Are we talking about windowed or fullscreen playback? Can you describe how the flickering looks like exactly? Maybe can could even capture it with a screen recoding software somehow?

Originally Posted by dansrfe

On a separate note, black bar detection isn't quite working as expected between timecode 01:29:07 - 01:29:18 of Interstellar, instead it goes back and forth between 2.41 and 16:9. You must start play back 5-10 seconds prior to 01:29:07 for the problem to appear.

I do have Interstellar here, but I can't reproduce any problems around 01:29:07 - 01:29:18. Maybe we have a different country edition with slightly different time codes? At 01:29:07 etc there's no switch between 2.41 and 16:9 at all, it's all straight 2.41 here.

Originally Posted by dansrfe

Let me know if you require a cut. Settings: detect hard coded black bars, crop black bars, rest disabled.

Would be great if you could create a cut which allows me to easily reproduce the problem you're seeing.

Originally Posted by Siso

is it possible to add an option like the one "zoom small black bars away"(which works very good on 21:9 displays for 2.35:1, 2.39:1, 2.40:1 ratios),a new option which crops the picture, in other words some sort of smart crop feature?

Activating both "zoom small black bars away" + "crop black bars" should already do that, I think.

Originally Posted by ShadyCrab

Okay, using the newest MPC-HC + LAV Filters (internal) which both now support HEVC 10 bit DXVA2 Native decoding, I am having issues using Native with madVR. My GPU is a GTX 960 which supports 10 bit HEVC decoding in full, driver is 355.98 on Win 10,.

Though, in general, I noticed a lot of instability with DXVA2 Native in madVR (no issues with copy-back).
1. If I enable 'use a separate device for DXVA decoding' for 8-bit content, I get a black screen but audio. If I skip forward slightly relatively fast to see the following warning, I see that madVR reports 'creating dxva decoding surface fails'. If I disable this option, 8-bit content works correctly with no black screen or crashing.

Seems to work fine here. Does that happen with all videos or just with some? Is that with DXVA deinterlacing active or inactive?

Originally Posted by ShadyCrab

2. In general, in 10-bit, I get the same black screen, but if you skip forward, I just get green screen. I think this might be because madVR doesn't accept 10 bit DXVA input, I don't know.

I'm not sure how LAV handles that, but I suppose LAV should detect that madVR doesn't accept 10bit DXVA input and switch DXVA native off? I don't know, I can't test it because I don't have a GPU capable of decoding 10bit via DXVA at the moment. Or are you using a different decoder than LAV?

Originally Posted by ShadyCrab

My last question with regards to native is about Chroma upscaling. I see the two options to use DXVA2 Chroma upscaling when native decoding is enabled, but I was wondering about the behaviour when you disable them. I remember in older builds, you would get a slight blur to the Chroma when using a NVidia card because they didn't support a certain texture format or something. Is this still the same behaviour when you disable those options to use madVR chroma upscaling?

Originally Posted by huhn

you should avoid DXVA native with nvidia it degrades picture quality with madVR.

^

Native DXVA is only for people who want low power consumption or who have slow PCs. If you can, use DXVA copyback or software decoding instead.

Originally Posted by ShadyCrab

Want to report that updating my graphics driver fixed NNEDI3 upscaling. It might be a good idea to regenerate whatever data NNEDI3 uses when updating to the D3D11 interop build for the first time, might help fix many peoples issues in regards to NNEDI3 (or in general, when using a newer build, regenerate the data). Or put a warning on the front page, saying if NNEDI3 isn't working, reinstall/update your video driver.

Regenerating the compiled kernel shouldn't be necessary or even useful because the compiled kernel is a totally separate thing from the interop. Whether I do interop or not and in which form is totally unknown to OpenCL at the moment when I run the kernel.

[nevcairiel]

Originally Posted by madshi

I'm not sure how LAV handles that, but I suppose LAV should detect that madVR doesn't accept 10bit DXVA input and switch DXVA native off? I don't know, I can't test it because I don't have a GPU capable of decoding 10bit via DXVA at the moment. Or are you using a different decoder than LAV?

When LAV connects using P010 and then asks the renderer to switch into DXVA-Surface mode, and the renderer doesn't complain - then how would LAV tell that the renderer doesn't actually support P010-DXVA?

[madshi]

Originally Posted by nevcairiel

When LAV connects using P010 and then asks the renderer to switch into DXVA-Surface mode, and the renderer doesn't complain - then how would LAV tell that the renderer doesn't actually support P010-DXVA?

I don't know. You didn't tell me yet that there was a problem with this... So what would be the best moment to reject DXVA mode? E.g. when you call SetSurfaceType, I can't check the format yet, I think? When is the best time and the best way to check the format? To be honest, it's been ages since I looked into my native DXVA2 code, so I'm kinda out of touch on the implementation details...

[ryrynz]

Originally Posted by madshi

I'm not sure what the two of you mean. Can you clarify?

If I update the window behaviour it doesn't show instantly, only when I change the window size.

Originally Posted by madshi

Have you tried installing a different GPU driver version?

Reverted and it was okay. Did a fresh upgrade over it and that's fixed it.

[madshi]

Originally Posted by ryrynz

If I update the window behaviour it doesn't show instantly, only when I change the window size.

What does "window behaviour" mean? Do you mean zoom modes like "touch window from inside" etc? The media players currently do not inform madVR about these modes. madVR just *guesses* the mode based on which target rect the media player sends to madVR. Now imagine you play e.g. a 720p file and MPC-HC displays it as 1280x720 pixels. madVR cannot know whether this is 100% view, touch window from inside, touch window from outside or stretch to window. All of those are possible. Only when you scale, madVR can find out which mode is really active. In a future build I'll add an interface for the media players to tell madVR which zoom mode they're in, so that madVR doesn't have to guess.

[nevcairiel]

Originally Posted by madshi

I don't know. You didn't tell me yet that there was a problem with this... So what would be the best moment to reject DXVA mode? E.g. when you call SetSurfaceType, I can't check the format yet, I think? When is the best time and the best way to check the format? To be honest, it's been ages since I looked into my native DXVA2 code, so I'm kinda out of touch on the implementation details...

Actually, I mentioned it in a PM in August (around the 11th, i think?).

Best would be of course if you just add P010 support, check the surface type and handle it accordingly.

Otherwise failing in GetAvailableSurfaceTypeByIndex/SetSurfaceType would be best. The Media Type is present at that time, since this is called in CompleteConnect.

[madshi]

Originally Posted by nevcairiel

Actually, I mentioned it in a PM in August (around the 11th, i think?).

Best would be of course if you just add P010 support, check the surface type and handle it accordingly.

Otherwise failing in GetAvailableSurfaceTypeByIndex/SetSurfaceType would be best. The Media Type is present at that time, since this is called in CompleteConnect.

Thanks. Must have missed it or forgot about it, sorry. Will add it to the next (official) build.

[clsid]

Originally Posted by madshi

Thanks. When researching all this I've seen this solution, too, but creating a temp vbs script file sounded quite scary to me. Isn't scripting also disabled on some (many?) PCs for security reasons?

The most important part is the admin check.
The vbs should work on most systems, even with AV installed. You could check for failure and prompt user to run as admin. Or just leave it out and always prompt.

[abotiz]

Hi
If i only watch 1080 or remux from my htpc to a projector with both are connected to a AV receiver, does it matter if i use MPC-HC with madvr or Total media theater?
could i get a better picture if i use this filter Or does the AV receiver handle all the signals and it doesn't matter what filter or player i use?
i Am after for the best sound and picture.
thnx

[huhn]

Originally Posted by abotiz

Hi
If i only watch 1080 or remux from my htpc to a projector with both are connected to a AV receiver, does it matter if i use MPC-HC with madvr or Total media theater?
could i get a better picture if i use this filter Or does the AV receiver handle all the signals and it doesn't matter what filter or player i use?
i Am after for the best sound and picture.
thnx

than you need it. it about complicated YCbCr conversation and high bit deep processing. you can read about it here: http://forum.doom9.org/showthread.ph...16#post1271416

[madshi]

Originally Posted by Serhiyko

That's too bad. I thought it could go into "trade quality for performance" subcategory just fine

I'll try to make this work by getting MPC-HC/-BE devs to notify me when subtitles are enabled/disabled.

Originally Posted by FreeFall

I think Lav Video Decoder renders the subtitles, you'll have to ask nevcairiel for more information.

nevcairiel has agreed (thanks!) to give madVR some control over DVD subtitles. So this problem should hopefully be solved in a future build. Not this weekend yet, though.

Originally Posted by clsid

The most important part is the admin check.
The vbs should work on most systems, even with AV installed. You could check for failure and prompt user to run as admin. Or just leave it out and always prompt.

I'll add it to my to do list to find a better solution for debug/release switching. Not sure exactly which solution I'll end up with, though. And it may take a while until I get to that. Thanks for your suggestions, in any case.

[XRyche]

Originally Posted by madshi

Thanks. The good news is that all those logs have the same problem: It's still the NNEDI3 kernel compilation. It seems that I'm compiling the kernel even if you use super-xbr or NEDI instead of NNEDI3. I'll fix that for the next build, so then you should hopefully be able to use super-xbr or NEDI without delay. But I would still like to find out why the NNEDI3 kernel is recompiled on your PC every single time. That's not right, either.

Maybe the fact that NNEDI3 isn't visual working right either might be a clue.

Having Super-xbr work without the delay would be much appreciated in itself. I prefer NNEDI3 but Super-xbr is pretty close.

Originally Posted by madshi

The bad news is that the logs are still created by the old build, not the special build I made for you. To be honest, I'm not sure if it's my fault or yours. Maybe I just sent you the wrong build or something. Can we make one last try:

1) Install standard v0.89.3.
2) Extract the XRyche special build I uploaded and linked to earlier.
3) Simply copy the special build into the madVR folder and overwrite the old file.
4) Create the log.

No file renamings at any time. No batch files. Nothing. After you're done, reinstall standard v0.89.3.

This is what I did last time. It even says in the madVR cpl that it is v0.89.3. I honestly didn't pay attention what the version number was when I used the madvr.ax file from madVRXRyche1.

Actually, I did use the "activate debug mode.bat" could that be the reason why it's showing it's an old build?

If not I'll re-download v.0.89.3 and madVRXRyche1 and use those. If it was because I was using the .bat file I'll just make 3 new logs without using the batch file and replacing madvr.ax with the file in madVRXRyche1. Either way it will be 5 or 6 hours before I can actually do it. Sorry for the delay.

[madshi]

Originally Posted by XRyche

This is what I did last time.

[...]

Actually, I did use the "activate debug mode.bat".

See the bold part in my quote. Just follow my instructions to the letter and it should work this time. The delay is not a problem. And one log should be good enough. Thanks.

[dansrfe]

Originally Posted by madshi

Would be great if you could create a cut which allows me to easily reproduce the problem you're seeing.

https://www.dropbox.com/s/s4f3i4dlvkzet7r/cut.mkv?dl=1

So, this cut show's 2.39 <=> 1.78 crop loop problem.

I can't reliably reproduce the initial transition partial flicker problem; if I can in another source then I'll post a cut of that.

[madshi]

Originally Posted by dansrfe

https://www.dropbox.com/s/s4f3i4dlvkzet7r/cut.mkv?dl=1

So, this cut show's 2.39 <=> 1.78 crop loop problem.

I can't reliably reproduce the initial transition partial flicker problem; if I can in another source then I'll post a cut of that.

That's a quite interesting sample, thanks! However, the problem only occurs if you start the movie and then directly seek to that position. Try the following:

1) Create an empty file named "ShowBlackBars" in the madVR folder, so you can see which rectangle madVR detects.
2) Start playback, wait until the Cinemascope AR is detected by madVR (green rectangle), then let video play for 10 seconds. Now this AR is stored as a "known good" AR.
3) Seek to some IMAX section, wait until madVR detects the AR (green rectangle), then let video play for 10 seconds. Now this AR is stored as a "known good" AR, too.
4) Now seek to the problematic timecode and play it through. It should play perfectly now.

Can you confirm the above? That means if you simply play the whole movie through from start to finish, the problem should not occur. I'll still look into this, maybe I can improve it.

About the flickering: Can you describe how it looks? Maybe it will be easier to describe with that green rect (ShowBlackBars, see above) active, and in fullscreen mode?

[dansrfe]

Originally Posted by madshi

That's a quite interesting sample, thanks! However, the problem only occurs if you start the movie and then directly seek to that position. Try the following:

1) Create an empty file named "ShowBlackBars" in the madVR folder, so you can see which rectangle madVR detects.
2) Start playback, wait until the Cinemascope AR is detected by madVR (green rectangle), then let video play for 10 seconds. Now this AR is stored as a "known good" AR.
3) Seek to some IMAX section, wait until madVR detects the AR (green rectangle), then let video play for 10 seconds. Now this AR is stored as a "known good" AR, too.
4) Now seek to the problematic timecode and play it through. It should play perfectly now.

Can you confirm the above? That means if you simply play the whole movie through from start to finish, the problem should not occur. I'll still look into this, maybe I can improve it.

About the flickering: Can you describe how it looks? Maybe it will be easier to describe with that green rect (ShowBlackBars, see above) active, and in fullscreen mode?

I followed your steps and can confirm that the section in question disables the crop and remains at IMAX aspect until the transition to Cinemascope after the scene completes.

As for the flicker, the green rectangle transitions from Cinemascope to IMAX as expected however if stare directly at the center of the frame yet focus on the entire frame you should see some sort of "rapid vertical frame stretch and snap" that happens within a small fraction of a second.

IMAX to Cinemascope doesn't have the same issue however there is minor visible distortion near the center of the frame that vaguely looks like it's contracting.

It looks distinctly different from the transition that occurs without black bar cropping enabled.

[madshi]

Originally Posted by dansrfe

I followed your steps and can confirm that the section in question disables the crop and remains at IMAX aspect until the transition to Cinemascope after the scene completes.

Just to be safe: So you agree that playback should be alright as long as you play the movie from start to finish?

Originally Posted by dansrfe

As for the flicker, the green rectangle transitions from Cinemascope to IMAX as expected however if stare directly at the center of the frame yet focus on the entire frame you should see some sort of "rapid vertical frame stretch and snap back" that happens within a small fraction of a second.

It may just be an illusion that the brain is perceiving however it does look distinctly different from the transition that occurs without black bar cropping enabled.

Interesting. You don't have "notify media player about cropped black bars" activated, do you? If not, then I'm not sure where such a problem could come from. madVR does have to reconfigure the rendering algorithms if you use "crop black bars" when an AR change is detected, but that should not be visible, at least not if your queues are decently filled. If you get a chance to film this with a digicam, or some other way, I'd love to look into that.

[FreeFall]

madshi,

Sounds good, Thanks.

[aufkrawall]

madshi, we talked about this via PM: When doing ground truth comparisons, should the base image be downscaled linear light or gamma correct?
Linear light introduced aliasing into the lighttower example picture of leeperry. Now question is, is this always supposed to happen, so that linear light shouldn't be used? Or is this dependent on how the actual source material already has been downscaled?