madVR - high quality video renderer (GPU assisted)

[mzso]

Originally Posted by Zed86

I know it isn't complete yet. But you could've just said that madVR does not yet support screen capture instead of saying that it was a bug in Potplayer, (how is that a bug exactly if there's no capture at the first place),
which was confusing and made me go and download MPC-HC thinking that it would solve the issue. Anyway, good luck with your work and will be waiting for v1.0.

But it is a bug in potplayer, because it produces a corrupted image.

[pankov]

Zed86,
the developers of PotPlayer are aware that madVR doesn't support frame capture yet so they have implemented some kind of hack to try and get that frame but obviously it still doesn't work. So actually it's a bug in their player. The correct way to do this is just show a message that this functionality is not supported yet but they didn't do it - so after all it's their fault that the capture is corrupted.

[BetaBoy]

Originally Posted by nevcairiel

CoreAVCs RGB converter does not honor its own settings anyway.. The output-levels option only has an effect for YUV output, RGB is always full-range.

We are not understanding the issue here.

"It outputs full range RGB for both limited range and full range H.264." <- this is what CoreAVC does, which is the correct way it should be handled.

But please help us to better understand the issue and define 'limited range' RGB Vs. 'full range'... and what you mean by it.

[nevcairiel]

Originally Posted by madshi

IMHO decoders should tell which levels they're outputting. Microsoft has introduced the DXVA_ExtendedFormat information structure exactly for this purpose, and madVR supports it. Unfortunately decoders don't seem to fill this structure yet. Hopefully that will change in the near future. At least nevcairiel has it on his to do list.

I can confirm that setting NominalRange in that structure makes madVR output proper levels.

Originally Posted by BetaBoy

"It outputs full range RGB for both limited range and full range H.264." <- this is what CoreAVC does, which is the correct way it should be handled.

You have an option for PC (full range) or TV (limited range) level output. But your RGB output is always PC level.

If you think that's the correct way to handle RGB conversion - what specifys that? Not criticizing, just wondering how you come to the conclusion that it should always be full-range. Maybe there is something we're missing?

[madshi]

Originally Posted by nevcairiel

I can confirm that setting NominalRange in that structure makes madVR output proper levels.

Nice! I hadn't actually tested this yet, due to lack of decoders providing this type of information.

Originally Posted by BetaBoy

We are not understanding the issue here.

"It outputs full range RGB for both limited range and full range H.264." <- this is what CoreAVC does, which is the correct way it should be handled.

But please help us to better understand the issue and define 'limited range' RGB Vs. 'full range'... and what you mean by it.

RGB can have black at 0. Or it can have black at 16. Computer type monitors usually expect black to be RGB 0,0,0. While TVs and projectors usually expect black to be RGB 16,16,16. ffdshow allows the user to choose whether black is RGB 0,0,0 or RGB 16,16,16. Since CoreAVC has a switch for output levels, it would make a lot of sense (at least IMHO) if that switch would apply to RGB, too.

Or let's talk practical effects: If an end user switches CoreAVC to RGB output, currently you always output black as 0,0,0. However, if the end user has a TV or projector which expects black to be at 16,16,16, he'll lose shadow detail when using EVR, VMR or the Haali Video Renderer, because all those renderers pass RGB through untouched to the display.

[BetaBoy]

madshi... thank you for the details, its appreciated.

[cyberbeing]

Originally Posted by madshi

Microsoft has introduced the DXVA_ExtendedFormat information structure exactly for this purpose, and madVR supports it.

The patent for that looks like it was filed two months after madVR was born (coincidence?), and approved just recently:
http://www.patentlens.net/patentlens...ums=US_7929754

A bit worrying, since it sounds like OpenMediaFormat would be in violation of that patent if madVR ever started using it...

[nevcairiel]

We're in europe, we don't care about the USes idea of software patents.
Besides, why would MS sue you for using their openly documented structure, in their DirectShow environment, on their OS? o.O

[vivan]

Originally Posted by madshi

Your GPU and CPU should be plenty fast enough to do 60fps without any problems.

Yes, CPU and GPU load are less then 10%.
And with other renderers (overlay, EVR, Haali) everything is ok.
So bottleneck is somewhere in the GPU and not in the raw computing power... And it is related to chroma upsampling (YV12, NV12, YUY2, UYVY -> RGB32 conversion).
Tested b/w video - 0 framedrops.

And another strange thing - in exclusive mode even presentation queue is full (3-4/4).
Number of dropped frame is about the same (1000-1200 out from 9240) at any resolution (from native 1024x576 to desktop 1920x1080) and mode (windowed/exclusive).

Originally Posted by madshi

Which decoder are you using?

internal and ffdshow.

Originally Posted by madshi

Please make sure you have antialiasing, anisotropic filtering etc turned off or set to application preference.

everything is set to "use application settings"

[kerimcem]

madvr external filter(lav,dscaler ) problem dvd vob files..(pc and notebook)
deinterlacing problem =http://imageshack.us/photo/my-images/853/ekrntsw.jpg/
ı am back mpeg2 internal codec
my english is poor sorry..thanks
good work..

[Xaurus]

I may be way off track here or misunderstanding something, but why is so many people talking about the lack of screen capture with madvr?
I have no problems taking screenshots in exclusive mode (mpc-hc).

Example (uncompressed png, 6 MB):
Click here

[cyberbeing]

Originally Posted by nevcairiel

We're in europe, we don't care about the USes idea of software patents.
Besides, why would MS sue you for using their openly documented structure, in their DirectShow environment, on their OS? o.O

Who knows, legal departments can be funny sometimes in who they choose to sue. Using the non-Microsoft madVR (instead of EVR/VMR), with a non-Microsoft OpenMediaFormat (instead of DXVA_ExtendedFormat), while using Microsoft components to compete against Microsoft in a way that violates the claims of the patent could be justified enough, if they ever felt threatened by madVR's presence or popularity. Luckily it appears the European Patent application is EP_1625509 is not yet approved. This is why software patents suck...

[nand chan]

Originally Posted by cyberbeing

Who knows, legal departments can be funny sometimes in who they choose to sue. Using the non-Microsoft madVR (instead of EVR/VMR), with a non-Microsoft OpenMediaFormat (instead of DXVA_ExtendedFormat), while using Microsoft components to compete against Microsoft in a way that violates the claims of the patent could be justified enough, if they ever felt threatened by madVR's presence or popularity. Luckily it appears the European Patent application is EP_1625509 is not yet approved. This is why software patents suck...

I don't see why they would see a reason to be threatened by madVR. It's the best renderer, and it's windows-only. What's not to love?

If anything, madVR would be causing people /to use/ Windows (over eg. mplayer2 on FOSS operating systems)

[fairchild]

Originally Posted by STaRGaZeR

Nevermind, as I've found the combination of EVR+Reclock to be as good as madVR in the vsync department, doesn't have any RGB issues, cuts the CPU consumption when playing in half, down to 0% when paused, and makes my CPU consume 10W less (20W for 1080p60 content) for the exact same visual quality. Sorry if I bothered you with all this RGB stuff.

I don't know about you, but nothing ever matches the smoothness of MadVR on my system. Sometimes Aero will cause the composition rate to change to 30Hz which causes massive problems. (I notice this when I look at the stats with MadVR) If the composition rate is 30Hz instead of what it should be which is 60Hz, then the video gets mega choppy. When using FSE with MadVR it fixes this issue and the videos are smooth as they should be.

When this issue happens and I'm using EVR choppy video makes me

I've tried a multitude of options in MPC-HC/PotPlayer such as disable desktop composition (Aero) and D3D fullscreen to remove the tearing from disabling desktop composition, but the video is still not smooth. MadVR > all

[e-t172]

Originally Posted by cyberbeing

The patent for that looks like it was filed two months after madVR was born (coincidence?), and approved just recently:
http://www.patentlens.net/patentlens...ums=US_7929754

A bit worrying, since it sounds like OpenMediaFormat would be in violation of that patent if madVR ever started using it...

Ahah. Considering the current state of the software patents landscape, I wouldn't be surprised if madVR already violated hundreds of software patents in itself without even knowing it. Nowadays, an independent developer has no choice but to ignore software patents: if he doesn't, then he can't make any software whatsoever.

Anyway, the developers live in Europe, where software patents are legally invalid, so we don't have to worry about anything.

[STaRGaZeR]

Originally Posted by madshi

Ooops, it seems I only tested the CoreAVC output level switch with YUV output, not with RGB output. Anyway, what happens if the user has a display which needs TV levels when he's using CoreAVC with RGB output for decoding? He'll get incorrect levels with all renderers, not just with madVR.

There are these little circular spots where you can click called options, that let you configure it the way you want

If they don't work the way they should, well that's another issue.

Originally Posted by BetaBoy

We are not understanding the issue here.

"It outputs full range RGB for both limited range and full range H.264." <- this is what CoreAVC does, which is the correct way it should be handled.

But please help us to better understand the issue and define 'limited range' RGB Vs. 'full range'... and what you mean by it.

madshi thinks that what the decoder should do is if the input is limited range, output it as limited range. If the source is full range, output is as full range. And then let the renderer do its job and convert that if necessary.

The problem madshi doesn't seem to fully understand is that all renderers except madVR don't do any conversions to RGB, so if you want proper image with them you have to give them the image fully converted, ready to be displayed. And 99.9% of users out there have a PC monitor expecting full range RGB, so that is what all known decoders (including CoreAVC) that output RGB do by default, except the future LAV Video if nevcairiel uses the default he said he was going to use. There is no correct or incorrect, but doing what the majority has been using for ages is the wise decision IMHO. Some filters offer options to control the conversion, like CoreAVC, but others don't, so changing this established behavior will just break things like it is doing now in madVR. All the correctness you may have in your software is useless if the final result is bad.

BTW, nevcairiel is correct. The default is what it is, but the options for changing it don't work. You should fix that.

Originally Posted by fairchild

I don't know about you, but nothing ever matches the smoothness of MadVR on my system. Sometimes Aero will cause the composition rate to change to 30Hz which causes massive problems. (I notice this when I look at the stats with MadVR) If the composition rate is 30Hz instead of what it should be which is 60Hz, then the video gets mega choppy. When using FSE with MadVR it fixes this issue and the videos are smooth as they should be.

When this issue happens and I'm using EVR choppy video makes me

I've tried a multitude of options in MPC-HC/PotPlayer such as disable desktop composition (Aero) and D3D fullscreen to remove the tearing from disabling desktop composition, but the video is still not smooth. MadVR > all

EVR sucks at vsync and general smoothness, but that part is provided by Reclock and it works just fine here. My monitor is configured to 119.88Hz, not sure if the high rate affects stuff or not. But if madshi fixes his stuff I'll go back to madVR, that's for sure.

[jimwhite]

Originally Posted by STaRGaZeR

The problem madshi doesn't seem to fully understand is that all renderers except madVR don't do any conversions to RGB, so if you want proper image with them you have to give them the image fully converted, ready to be displayed. And 99.9% of users out there have a PC monitor expecting full range RGB, so that is what all known decoders (including CoreAVC) that output RGB do by default, except the future LAV Video if nevcairiel uses the default he said he was going to use.

That is a HUGELY gross overestimate ... more and more "HTPC's" every day are hooked up to Largescreen TV's of the LCD/PLASMA persuasion which expect VIDEO (limited) levels....

[6233638]

Originally Posted by STaRGaZeR

The problem madshi doesn't seem to fully understand is that all renderers except madVR don't do any conversions to RGB, so if you want proper image with them you have to give them the image fully converted, ready to be displayed. And 99.9% of users out there have a PC monitor expecting full range RGB, so that is what all known decoders (including CoreAVC) that output RGB do by default, except the future LAV Video if nevcairiel uses the default he said he was going to use. There is no correct or incorrect, but doing what the majority has been using for ages is the wise decision IMHO. Some filters offer options to control the conversion, like CoreAVC, but others don't, so changing this established behavior will just break things like it is doing now in madVR. All the correctness you may have in your software is useless if the final result is bad.

I don't think you understand the purpose of madVR.

The whole entire point of starting madVR was to do the best job of converting videos from 4:2:0 YUV to 4:4:4 RGB by doing the best chroma (and luma) upsampling possible.

I don't understand why you would want to send it RGB at all, when the main point of madVR is that it does an amazing job of the conversion to RGB, unlike pretty much everything else. (take a look at the second post in this topic)

Where are you getting RGB encoded/full range source material from, or what is your reason for not wanting to send YV12/NV12 to madVR?

Originally Posted by nand chan

If anything, madVR would be causing people /to use/ Windows (over eg. mplayer2 on FOSS operating systems)

It's actually the reason my main computer is a Windows PC and not a Mac now, no joke.

I would probably just be using a Mac and a stand-alone Blu-ray player if it weren't for madVR. (combined with ReClock for DVD)

[nand chan]

I'm reposting this here to raise awareness of the issue,

have you considered a “reset video device CLUT during playback“ feature for madVR? It's a hassle to always run a manual script to reset them before playback (and reload afterwards).

[leeperry]

Originally Posted by nand chan

have you considered a “reset video device CLUT during playback“ feature for madVR? It's a hassle to always run a manual script to reset them before playback (and reload afterwards).

You could always use Overlay, as it's immune to CLUT's by design(or lack thereof)

This said, now that your LUT app allows to merge ARGYLLCMS calibration files together w/ yCMS/cr3dlut 3DLUT's, this feature would be more than welcome! It would finally allow the use of all-in-one 3DLUT's providing both calibration and gamut mapping at once