madVR - high quality video renderer (GPU assisted)

[NicolasRobidoux]

NNEDI3 is really impressive, but I do not like the way it fails when it fails, and IMHO it is more about creating a good looking alternate reality than a "faithful" one.

[NicolasRobidoux]

Originally Posted by madshi

...
I agree, trying is the best idea. My impression is that with AR activated Jinc3 and Jinc4 look very very similar...

Makes sense. AR changes the game.
Without AR, however, I'd never use Jinc4 over Jinc3.

[madshi]

@Guys, could we please *not* have another LCD vs. Plasma discussion in this thread? We've already had enough of that a while ago. Let's all just agree to disagree there, ok? Thanks.

@NicolasRobidoux, maybe analyzing an image and running NNEDI3 only on specific areas could do the trick?

[NicolasRobidoux]

Mathias: Yes, local content adaptivity---meaning that the blend of methods used locally will not only depend on the geometrical transformation (like for the Lohalo method in the GEGL library and bleeding edge GIMP, which is designed to robustly handle wild warps without adding any haloing or being overly compute intensive) but also on the content (like for DDL = Data Dependent Lanczos, like in the SAR Image Processor)---is clearly the way things will eventually be done.

[agustin9]

Originally Posted by madshi

Can I have a log from PotPlayer, please, which shows this problem? Please try to keep it as short as simple. Meaning: Start PotPlayer, reproduce the issue quickly, then close PotPlayer quickly. Thanks.

Yes, of course.

madvr - log 2012-11-20 PotPlayer
Alternative Download Link

Thanks!!

[Razoola]

I dont want to derail the thread but the 2012 panasonic plasmas are a total letdown. I had the VT50 and it had three big issues...

1) vertical band down right side of screen.
2) suffered bad linebleed
3) image retention and burn in issues.

Don't get me wrong the picture was fantastic although very low lightoutput in professional modes. The above three issues however forced me to return the panel for a refund. The F1 logo burnin on the panel after a 2hour formula1 race was the last straw for me. And yes it was burnin and not retention.

(edit)
sorry madshi, I read you post after I put this one.

[ryrynz]

Don't plan on derailing either but I have an ST30 and I love it it's no VT but it's good enough.

[leeperry]

Well, I believe madshi really wanted to avoid pages of Plasma Vs LCD arguments but quite frankly those flat screens are prolly great to watch the news while eating, play videogames or watch a movie once in a while.....but for video nutcases like us, they are a no-go IMHO...except if you manage to score a golden sample somehow, or are willing to accept visible/audible defects(clouding, posterizing, buzzing, vertical banding, you name it)

QA at the slovakian factory of Sammy seems very very poor(if it turns on = it can be sold ) and asking 1K€ for those fubar TV's is ludicrous. Do they realize that this is the monthly salary for many/most ppl in western europe? I guess someone has to pay for their 3y on site warranty one way or the other.

I see that in the US they can get 40 inchers for $180, then yeah OK shoot! I won't be nitpicking (too) much for 140€ but for a grand it'd better be purrfect, especially when TI are releasing cheap DC3 1080p chips that will soon flood the market....it took them while to wake up, huh! They promised affordable DC4's for everyone years ago but nothing ever showed up under $10K. I guess they've managed to improve the yielding rates and lower their manufacturing costs so they are ready to deliver large quantities for a low price

[Mangix]

Originally Posted by 6233638

I can think of one or two examples where anti-aliasing could potentially improve video quality, but chances are that implementing SMAA would not be worth the development time, as post-process AA has a habit of smoothing over sharp areas too. (Though SMAA is considerably better than FXAA or MLAA in this regard)

Wouldn't you be better off using some AviSynth filter or something? doing Anti-Aliasing on a video makes no sense. In games, it makes sense to smooth out the edges since they're generated during rasterization and should be eliminated to make the image more appealing. But video? If you have a properly done video clip, why anti-alias?

[ryrynz]

Because it can at times improve overall quality. I've given it a go in Avisynth and it's quite resource consuming it also wiped out some fine line detail so I ditched it.
When you're dealing with sharpening low quality content anti-aliasing can be a very nice addition to the arsenal.

[schweinsz]

Does the madVR support 3D rendering?

[turbojet]

Originally Posted by Keiyakusha

The main problem with spline144 is ringing, I didn't noticed that much aliasing. It was spline100 whose only difference from avisynth's bicubic (its like Mitchell-Netravali in madvr, no?) is amount of aliasing. Ringing may look like sharpness for live action. But if you somehow remove ringing, spline144 will lose half of its "sharpness". As to your screenshots, I can't really say anything. I watch live action rarely so never tried to learn how to make it look better. But still with such low quality source I don't see much reason to be picky with resize, whatever will do... Especially if you do use separate sharpening. You may consider using more sharpening instead. Probably masked sharpening, because sharping these artifacts even more is a no go.

I misread your post a bit, thought you meant aliasing was the problem with both spline's not just 100. I picked a complicated scene and it was probably a bframe but it was intentional. Complexity for more to discuss, bframe so the artifacts would stand out more. A majority of the aliasing was from bicubic75ar chroma upsampling, switching to lanczos3ar eliminated a lot of it with the rest of the picture looking nearly identical. Almost all eliminated with softcubic100ar but the picture is way too soft. These same artifacts were in the Jinc3 pic as well. Ringing I don't have a problem with spline144 on hd sources, on sd->hd there's some but a lot less then bicubic75/100 or lanczos 3/4. I sharpen pre-resize so resizer artifacts aren't sharpened. Do you know of a resizer that's just as sharp as Finesharp but reduces the edge artifacts?

My experience with other sharpeners is: LSF/LSFMod isn't nearly as sharp and it's inconsistent, a face can go from sharp to blurry just by turning a little, it's better with edge artifacts though. SeeSaw from what I remember years ago was mainly an edge sharpener with quite a few edge artifacts, not nearly as sharp non-edge details as Finesharp. SharpenComplex PS, Unsharp, Xsharp are basically edge sharpeners that when tuned up to finesharp's strength are full of edge artifacts.

Originally Posted by madshi

I'm not sure. Spline100 looks overly soft to me. Why using 5 taps when the result is so soft? Spline144 looks over-sharpened too me. I don't think either Spline100 nor Spline144 are just higher taps versions of Spline36/64. There's something very different about Spline100 and Spline144, which make me wonder if there's either something wrong, or maybe they're based on a completely different logic.

Thanks for replying, they are based on a different theory. Spline16/36/64 are natural cubic splines explained in this pdf. Spline100/144 theory is explained in this doom9 thread. You showed interest in the theory in 2009 before 100/144 dll was published, the coeffecients including 256 are there as well. Might you renew your interest in them at some point? Splineresize I can't find documentation on what it really is, but my guess is based on natural splines (spline16/36/64)

Those wishing Jinc was sharper could try that. But those wanting the "natural look" won't be happy with Spline100/144.

The 'natural look' excludes Jinc in that post, which resizer do you think is more natural in that case?

My thoughts are all the bicubic variations blur non-edges a sharpens or blurs it's edges, not very natural to me, it also has a tendency to smear grain quite a bit but it's the only MadVR PS resizer I can use with BD's. Spline36/64 is a bit blurry and has some inaccuracy problems, I notice blocks in faces that shouldn't be there, even on fairly clean sources, and a bit of grain smear. Lanczos3/4/8 handle grain fairly well but with a ton of ringing (AR helps) and grainy faces have a bunch of dots on them (even with AR) which is really ugly and unnatural. Nearest neighbor and bilinear don't really require discussion do they? Some avisynth compare() of the resizers might be required to show which best represents the source. Better to go up/down 16,9px or is large up/down a more realistic test?

[Mangix]

Originally Posted by schweinsz

Does the madVR support 3D rendering?

not at the moment

[madshi]

Originally Posted by turbojet

Thanks for replying, they are based on a different theory. Spline16/36/64 are natural cubic splines explained in this pdf. Spline100/144 theory is explained in this doom9 thread. You showed interest in the theory in 2009 before 100/144 dll was published, the coeffecients including 256 are there as well. Might you renew your interest in them at some point?

Maybe, but not now.

Originally Posted by agustin9

Yes, of course.

madvr - log 2012-11-20 PotPlayer
Alternative Download Link

Thanks!!

The reason for the delay is that PotPlayer is asking madVR to redraw the current video frame over and over again. PotPlayer does that so that it can draw animated GUIs. The only way for madVR to handle this is to drop all rendered frames and render them again. So basically while playback is paused with PotPlayer, the madVR rendering queues stay empty. MPC-HC does not draw animated GUIs and doesn't ask madVR to rerender the same frame all the time, so the madVR rendering queues can stay full with MPC-HC. So when you resume playback, with MPC-HC all queues are already full and playback can resume immediately. But with PotPlayer, the queues are empty and must be filled before playback can resume (since you asked madVR to delay playback start until all queues are full).

Originally Posted by turbojet

The 'natural look' excludes Jinc in that post, which resizer do you think is more natural in that case?

I think no other resizer is as "natural" looking as Jinc. Of course a lot depends on the source material and the scaling factors.

Originally Posted by turbojet

Some avisynth compare() of the resizers might be required to show which best represents the source. Better to go up/down 16,9px or is large up/down a more realistic test?

A long time ago I compared different resizers by doing 400% upscale, then 400% downscale, and the only algorithm where the final downscale looked almost identical to the original source was Lanczos.

Originally Posted by schweinsz

Does the madVR support 3D rendering?

Not yet, but I plan to work on this soon.

[madshi]

Today's date is 21.11.12, and we've reached page 777. I think this is a good time to announce the first madVR version which has no significant limitations compared to VMR/EVR, anymore. So here we go:



madVR v0.85.0 released

http://madshi.net/madVR.zip

* added support for external DXVA2 decoders
* added support for DXVA2 scaling
* added support for custom pixel shaders (pre- and post-scaling)
* added support for media player color controls (IVMRMixerControl9)
* added support for "IQualProp" interface for media player statistics display
* added (crappy) support for high-bitdepth, 4:2:2 and 4:4:4 DXVA2 deinterlacing
* changed default scaling settings

The list of changes appears to be small, but the changes are quite important. Let me add some comments:

(1) External DXVA2 decoders should now work just fine in native mode without needing "copyback". This should improve performance, especially for ATI/AMD users.

(2) DXVA2 scaling uses the GPU hardware/drivers to do image scaling. Scaling is done from NV12 -> NV12, so the GPU has to scale both luma and chroma, but madVR still has to upscale chroma to full resolution afterwards. Unfortunately most GPUs don't support YCbCr 4:4:4 output, so I can't do it any other way. Ok, I could let the GPU convert to 8bit RGB, but we really don't want that because then the GPU does the color conversion, in low bitdepth, without dithering.

Since scaling is done by the GPU hardware/drivers, scaling quality will differ depending on the GPU hardware/drivers. Also I've been told (not sure if it's true) that Intel has dedicated hardware circuits to do the scaling while NVidia and AMD are using pixel shaders instead. So it's possible that the performance benefit on Intel hardware might be bigger than on NVidia/AMD hardware. Please test this and let me know the quality of the scaling algorithms, and the performance compared to madVR scaling algorithms with your GPU. Please also note that the video settings in the GPU control panel may very well affect DXVA2 scaling results.

(3) Custom pixel shaders in MPC-HC should work just fine now with madVR. However, a new MPC-HC build will be necessary. I'll make the necessary changes available to the MPC-HC devs later today. For now I've uploaded a custom MPC-HC build here, so you can start playing with it:

http://madshi.net/mpc-hc.zip

Please note that madVR always runs custom pixel shaders in R'G'B' with black at 16.0/255.0 and white at 235.0/255.0. I'm not sure how EVR/VMR runs custom pixel shaders. Maybe I'll need to adjust this to match EVR/VMR, we'll have to wait and see.

(4) madVR now supports media player color controls (brightness, contrast, saturation and hue). Currently you can't adjust these settings inside of madVR, the media player has to do that, by using the official IVMRMixerControl9 interface.

For brightness and contrast, I'm not using the usual algorithms. The standard GPU brightness control adds a fixed value to every RGB channel, so it increases both the black and white levels by the same amount. The standard GPU contrast control stretches the data, so white and black levels move away from (or nearer to) each other. While these standard GPU controls appear somewhat intuitive, using them means that brightness and contrast fight with each other. When setting up your display, you have to change both all the time and go back and forth.

The madVR brightness control only modifies the white level, but keeps the black level identical. The madVR contrast control only modified the black level, but keeps the white level identical. The name "brightness" somewhat fits to what madVR does, but the "contrast" name doesn't really fit well. It's more like "blackness" or "black level". I decided to implement it this way because I think it makes setting up the displays easier. But this is open for discussion: If you don't like madVR's brightness/contrast behaviour, let me know, maybe we can find a better solution together.

The madVR saturation and hue settings work as usual, however I'm performing the modifications in linear light (which is the only correct way to do saturation/hue adjustments), while the other renderers and GPU drivers usually adjust these things in gamma corrected light.

(5) DXVA2 deinterlacing (and DXVA2 scaling, too) now works with all YCbCr formats which madVR supports, regardless of bitdepth and chroma format. *However*, since all GPUs perform the best deinterlacing only with NV12, madVR automatically converts all YCbCr formats down to NV12, when doing DXVA2 deinterlacing. And madVR does not contain high-quality downconversion routines for this yet. It's a simple round down at the moment. This might be improved in a (far away) future build. For now you might get slightly better quality by letting LAV Video Decoder downconvert to NV12. IIRC nevcairiel has implement some nice downconversion routines with dithering etc...

(6) When using any DXVA2 related functionality with madVR, there's a small blur added to the chroma channel, when using NVidia or Intel hardware. This does not happen with AMD hardware. Currently I've no way to fix this. But it has always been this way and nobody complained until now, so it doesn't seem to be much of a problem. I have it on my to do list to fix this, but it will require a new CUDA version from NVidia and I'll need Sandy Bridge hardware (which I currently don't have) to test a possible fix for Intel.

(7) The new default scaling settings are Lanczos3 AR for image upscaling, Catmull-Rom AR with Linear Light for downscaling and Bilinear for Chroma. I've selected these algorithms with an eye on performance, as well as quality. If your GPU is fast enough, you definitely want to use something better than Bilinear, but for users with slow GPUs the best quality compromise IMHO is to use Bilinear chroma upsampling. Just my personal opinion, of course, and everybody please feel free to disagree. For really fast GPUs my recommended settings now would be Jinc3 AR for both chroma and image upscaling and Catmull-Rom AR with Linear Light for image downscaling.

Since many of these features are brand new, please expect a couple new bugs. I haven't tested especially DXVA2 decoding and scaling too much yet, so me might have to do some polishing before everything works perfectly.

Oh yes, and before anybody asks why this isn't v1.0 yet: While madVR now has no major limitations compared to VMR/EVR, anymore, I still don't consider it feature-complete. There's still a list of things I want to add. Afterwards there'll be a period of tweaking and polishing. Then some kind of manual. And then maybe it's time for v1.0. But that's still some time away...

[leeperry]

w00t, for the new build!

oh, PS script need to be invoked from within the media player, gonna have to whine to the coder of PotP this time(PS: email sent ^^)

PS scripts work in 0-255 in MPC AFAIK, but I might have misunderstood what you wrote.

[SamuriHL]

WOW, madshi. Very impressive!!!

[crotecun]

Thanks, madshi! Testing both the new madVR build and the custom mpc-hc build.

[wanezhiling]

Oh god... Great!!!!!!!

[Octo-puss]

wow, just wow