madVR - high quality video renderer (GPU assisted)

[omarank]

Originally Posted by madshi

I can't confirm that. That seems to work here.

Can you try this script?

if (deintFps > 24.5) and (deintFps < 25.5) "Off"
else "On"

In the "On" profile, enable smooth motion with the option "only if there would be motion judder without it...".

{Basically I want to use smooth motion the way it is selected in the "On" profile, but I need to disable it specifically for 25 fps content as LAV outputs still images as 25 fps video and there is a reported bug in madVR due to which a black screen is produced for still images if smooth motion is enabled.}

Originally Posted by madshi

Oh well, I actually didn't get around implementing this yet... Will add that in the next build, too. What do you mean with an example? You mean you're wondering what the purpose of this functionality is and what it could be good for? Well, I don't know, to be honest, with the current feature set. But one of the next planned features will make the command line stuff useful for some users.

You have answered my questions. I am looking forward to these features.

[The 8472]

Originally Posted by madshi

WHAT!?

On my PC (Windows 8.1 x64, AMD HD7770) I get the following rendering times:

1080p24 playback, 1680x1050 monitor:
- random dithering: 2.0 ms
- error diffusion: 8.3 ms

1080p60 playback, 1680x1050 monitor:
- random dithering: 2.6 ms
- error diffusion: 10.1 ms

With a 1920x1080 monitor cost of error diffusion would be about 15% higher, but that's it. Sure, error diffusion is not free. But it's not *that* demanding, either. And we're talking about a HD7770 here. There are some much more powerful beasts out there

• GTX 760
• Smooth motion on
• 60Hz
• doubling 720p -> 1440p with nnedi 32 neurons
• 2560x1440 display

random dithering: 51-55% GPU load
error diffusion: 90+% load, occasional frame drops

I only see present times in the OSD, no rendering times.

Have you considered using void and cluster ordered dither instead of error diffusion? It would only require a lookup table instead of inspecting neighboring pixels. That might be more shader-friendly.

[omarank]

Originally Posted by madshi

On my PC (Windows 8.1 x64, AMD HD7770) I get the following rendering times:

1080p24 playback, 1680x1050 monitor:
- random dithering: 2.0 ms
- error diffusion: 8.3 ms

1080p60 playback, 1680x1050 monitor:
- random dithering: 2.6 ms
- error diffusion: 10.1 ms

With a 1920x1080 monitor cost of error diffusion would be about 15% higher, but that's it. Sure, error diffusion is not free. But it's not *that* demanding, either.

Below are the rendering times on my system (Windows 7 32 bit, GTX 260):

Smooth Motion OFF:
- Random dithering: 8.7 ms
- Error diffusion: 18.5 ms

Smooth Motion ON:
- Random dithering: 10.3 ms
- Error diffusion: 27.8 ms

This is for 720p video on 1280x1024 monitor (no image scaling in the output).
[Settings: FSE, CPU – 24, GPU – 16, frames in advance – 12, default flush settings, Chroma – Jinc3 AR]

Is the performance hit with error diffusion due to OpenCL implementation or the algorithm itself?

[cyberbeing]

Originally Posted by madshi

With a 1920x1080 monitor cost of error diffusion would be about 15% higher, but that's it. Sure, error diffusion is not free. But it's not *that* demanding, either. And we're talking about a HD7770 here. There are some much more powerful beasts out there.

Relatively speaking, the OpenCL error-diffusion dither has the same cost at 1080p 24hz as Jinc4|AR Luma + Jinc4|AR Chroma 1280x720 -> 1920x1080 scaling + Random Dither. Overall I'd say it's probably the second most expensive thing in madVR behind NNEDI3 now, considering it's a couple ms slower than NNEDI3|16 1280x720 -> 2560x1440 display. At least that's the case with my GTX 770.

You may want to consider implementing something similar to the 'dither fruit' method from MPV, which is essentially an ordered dither with optional temporal randomization. It would give people another low-noise dither alternative, at much lower performance cost.

Originally Posted by madshi

So would it be fair to say that error diffusion is more true to the source compared to random dithering?

Yes, I'd say its more true to the source, but the dither quality feels somewhat questionable on less than pristine sources. From what I can tell, it only does a hard mix of existing source colors, lightness, hues. For example, I saw it create a dither comprising dark specks on a light surface. Similarly I've seen it hard mix red specks and green specks in a pattern. While this works to some extent perceptually, it seems like it would be superior if the dither created new colors to better assist in creating smooth transitions.

[The 8472]

Originally Posted by cyberbeing

Relatively speaking, the OpenCL error-diffusion dither has the same cost at 1080p as Jinc4|AR Luma + Jinc4|AR Chroma 1280x720 -> 1920x1080 scaling + Random Dither.

You're comparing apples and oranges here. Upscaling depends on input framerate, dithering on output framerate. Both also depend on the target resolution. And one is implemented as shaders and the other as OpenCL, so implementation efficiency might also differ between vendors.

So the relative costs can vary substantially between different setups.

[leeperry]

Originally Posted by madshi

XP was a bit faster and more seamless when doing FSE/FSW transitions. There's nothing we can do about that. Well, maybe I could find a way (or maybe not), but I consider that a cosmetical problem and as such not very important at the moment.

Windows never had the intention to guarantee that every thread is getting enough CPU time without any serious interruptions. When talking about 60fps, every frame is only visible for ~16.7ms. If you don't use FSE, playback can only be smooth if madVR always gets enough time in every 16.7ms slot to prepare and present the required frame. If only once Windows fails to give madVR enough CPU time for a duration of about 16.7ms, automatically you'll get a frame drop. This is where FSE helps: By presenting several frames in advance, you increase the critical time window from 16.7ms to a multiple of 16.7ms. E.g. with 8 presented frames in advance playback will still be perfect even if Windows stops giving madVR CPU time for 100ms.

OK thanks for the details, I'll stick to FSE then

Luckily PotP's coder was kind enough to accept a few of my feature requests regarding its D3D GUI which makes me plenty happy now, especially as it never breaks FSE. Of course the black frames flashing is still there but it wouldn't appear to be nearly as annoying if I pause the movie before selecting context menus(such as manually rolling gamuts via PS scripts).

Sometimes I don't only get black frames but previous frames from the movie huh.

My only current problem is that I've set mVR to automatically roll refresh rates when going FS and when going from 1080p60 windowed to 1080p24/50 FSE, I randomly get an "Exclusive mode failed" error message in the top left corner of mVR...and no FSE for me

It seems completely random so I'm not sure wth is going on here? Would you care for a log?

I've checked the windows event viewer and it seems that PotP asks Windows to disable Aero before going FSE, is that part of the standard FSE procedure?

I've also tried to disable Aero when going FS in the mVR settings but then FSE didn't work anymore.

If Aero helps with tearing in windowed modes but sometimes makes FSE fail, I might just disable it altogether

Originally Posted by madshi

Does it support 3D playback via HDMI 1.4? And does it support 4:4:4 at every refresh rate, or just at 60Hz?

No 3D support, 4:4:4 only in 60Hz. 24p is dead smooth, though

IIRC only their "6" serie in the 2013 F lineup will allow for 3D but only the "5" serie allows for BFI without FI.......Sammy's FI hiccups on 24p and doesn't look all that good, OTOH their BFI provides the nice added value of removing motion blur and most visible flicker. I'm very sensitive to flicker BTW.

[leeperry]

Humm, I ran more tests and apparently FSE randomly fails if I tell mVR to automatically roll refresh rates when going FS but it doesn't fail if mVR was set to roll refresh rates when playback starts...is that expected behavior? I really like the FS condition, would you care for some logs?

[cyberbeing]

Originally Posted by The 8472

You're comparing apples and oranges here.

I only used a Jinc example, since that's something people are already familiar with as being rather costly in performance.

Originally Posted by The 8472

So the relative costs can vary substantially between different setups.

Which is true, but I can say pretty affirmatively that it is indeed the second most costly option overall in madVR with my GTX 770 setup.

Relatively speaking, it's expensive on mid-range to high-end NVIDIA Kepler compared to all other madVR options except NNEDI3.

[petran79]

with version 0.87.4, if I enable NNEDI3, video doesnt freeze, but I get green color levels all over the video image.
Probably because its Nvidia.

If it was AMD, I'd get red color levels.....

[hannes69]

Ver Greeneyes
It doesn't seem to take much juice (2-3ms) on my laptop's Radeon Mobility HD 4650, which surprises me a little (especially given that it's stuck on the legacy driver).

madshi
Do you have 13.12 drivers installed? As I wrote in the v0.87.0 announcement post, OpenCL only works with AMD GPUs if you update to the latest drivers.

hannes69
Today I played around with my AMD 4550 GPU to test all the new features of madvr. Debanding and the profile stuff is working great.
Just for info concerning the OpenCL stuff: I don´t use it (no need for the features in my setup) and it doesn´t seem to work properly. That´s no problem because this ancient video card could certainly not handle this stuff, even if the implementation of these functions would be correct.
NNEDI3 chroma upscaling: GPU load rises, but the load is independent of the number of neurons ...
image doubling: GPU load stays the same, it doesn´t matter which settings are made (tested with lowres video)
OpenCL DXVA NV12 surfaces: no effect when using DXVA native or copyback decoder (GPU load the same)
OpenCL error diffusion: GPU load stays the same.

I doubt that any of the OpenCL stuff is working with my good old card. GPU-Z reports full OpenCL support for this GPU.
Maybe the old generation cards HD2000 - HD4000 series with legacy drivers don´t support all the OpenCL features.

All no problem for me, just wanted to notify.

Beside that the recent version of madvr works stable for me.

General idea: it would be really nice in a mid-term future that all the computing of video could be freely allocated to CPU/GPU. My CPU is bored at the moment with just decoding the video. I thought the idea of OpenCL was to use CPU and GPU interchangeable for all purposes...
Of course it is too time consuming to make code implementations for GPU and CPU for every little feature, but isn´t OpenCL comparable to a sort of cross-compiler (have no better comparison) so code can rather easily be converted?
Sorry for my non-expert point of view, just interested.

I think it is not possible to install the "normal" (non-legacy) drivers for HD2000-HD4000 series ...

[GCRaistlin]

Why the picture with madVR is so dark compared to other renderers?
VMR9 renderless
madVR

[Ver Greeneyes]

Originally Posted by madshi

Do you have 13.12 drivers installed? As I wrote in the v0.87.0 announcement post, OpenCL only works with AMD GPUs if you update to the latest drivers.

Ah sorry, I missed this. Unfortunately my laptop's card falls under legacy support, so it is stuck on the 13.9 Legacy Driver. This comes with OpenCL driver version 10.0.937.2 (regular driver 13.12 comes with OpenCL driver version 10.0.1348.5). Enabling error diffusion on my laptop doesn't seem to cause any problems, I just don't know if it's doing anything.

[James Freeman]

Originally Posted by GCRaistlin

Why the picture with madVR is so dark compared to other renderers?
VMR9 renderless
madVR

MadVR "stretches" a 16-235 (video) shades of grey to 0-255 (PC).
In video format 16 is the black, in PC 0 is.

What you see in the "VMR9 renderless" picture is black that is not truly black (not equal to 0), while in MadVR its true black.

If you think the blacks are actually clipped (or madvr did not guess correctly),
you can change the input range by pressing Ctrl+Alt+Shift+I while watching your film.

[huhn]

Originally Posted by GCRaistlin

Why the picture with madVR is so dark compared to other renderers?
VMR9 renderless
madVR

is the file name something like black 1970 ? are you using 87.4? the black number didn't work in 87.4 only black=number

MadVR "stretches" a 16-235 (video) shades of grey to 0-255 (PC).
In video format 16 is the black, in PC 0 is.

VMR 9 is doing this too

[DragonQ]

Originally Posted by GCRaistlin

Why the picture with madVR is so dark compared to other renderers?
VMR9 renderless
madVR

The MadVR output looks correct, the VMR9 one is not using the correct output range.

[MSL_DK]

OpenCL > 334.67

http://www.avsforum.com/t/1471169/ma...#post_24278588

[GCRaistlin]

Originally Posted by huhn

is the file name something like black 1970 ? are you using 87.4? the black number didn't work in 87.4 only black=number

It's "The Seventh Seal" Blu-Ray. I can see the same difference for other videos, too:
http://tinypic.com/m/i2j4tf/4
http://tinypic.com/m/i2j4te/4
And the result is the same for 0.86.1.

Originally Posted by DragonQ

The MadVR output looks correct, the VMR9 one is not using the correct output range.

All I can say is the details are lost in madVR picture (see links in the post).

[fairchild]

Has anybody noticed if there is a visible quality difference between using 32 neurons vs 64 neurons to double Luma resolution with NNEDI3, since in several of my media files it's the difference between increasing/decreasing the rendering times to prevent frame drops.

I guess it would overall be better using NNEDI3 with 32 neurons + Lanczos 3 AR is better than just using Lanczos 3 AR by itself.

[Thunderbolt8]

Originally Posted by MSL_DK

OpenCL > 334.67

http://www.avsforum.com/t/1471169/ma...#post_24278588

someone should slap them for this.

one thing regarding the trade quality for performance window: maybe it would be more newbie friendly to rename those functions that way that in general always ticking or always unticking the checkbox has the same effect, meaning either lower or higher quality for all options.

[James Freeman]

Originally Posted by MSL_DK

OpenCL > 334.67

http://www.avsforum.com/t/1471169/ma...#post_24278588

EDIT:

No It does not work.