madVR - high quality video renderer (GPU assisted)

[Zed86]

You can just overwrite the files. No uninstall/install needed in most cases. If you want to be sure you can click on uninstall before overwriting the files, and then on install after overwriting the files. In any case, no need to delete the old files.


No tearing. Better performance. More stability/reliability. If you have a perfect experience in windowed mode then of course it's worth a thought disabling the exclusive mode, because it comes with some user interface disadvantages.


madVR does not show an OSD when seeking, unless the media player asks for that. You may have to talk to the Potplayer developer about this.





Thanks for the responses madshi.

As for the OSD, I might not have been clear about the small grey OSD that pops up on top left corner of the screen while jumping a minute or 5 mins, I don't want it to be disabled completely,
I want to use Potplayer's own OSD time-stamp while jumping or seeking.. Is there a way to do this? why does it only show up in full screen and not windowed?!

- Also, I just noticed yesterday while trying to capture a frame I would get a blurred/corrupt image. This didn't happen when using EVR, so I'm guessing I need to configure something in madVR?

Thanks for your time, and keep it up.

[emueyes]

Hi all

Sorry to have such a newby question, but 473 pages is too much to go through and the question too generic to search for

running install.bat (as admin) pops up the usual dialog, and tells me the files haven't been copied anywhere

but then madVR shows up in MPC-HC greyed out

am using
Win7 x64 (no SP)
GTS250 card with 275.33 drivers
MPC-HC 1.5.3.3677 (this might be the problem, I suspect)

Thanks for any help, and I'll keep looking. I actually just discovered the LAV CUVID and ppls there reckon madVR is the best renderer to be using

[namaiki]

Try run install.bat not as admin.

[emueyes]

run install.bat as myself (admin privilege account) the same thing happens, madVR shows up greyed out in MPCs renderer list

running as a standard user tells me that registering the directshow filters failed :(

[Zed86]

run install.bat as myself (admin privilege account) the same thing happens, madVR shows up greyed out in MPCs renderer list

running as a standard user tells me that registering the directshow filters failed :(

Just login as admin, then LEFT click on intall.bat. without right-click then run as admin. Just one left click will do, and it's normal for it to say that it did't copy any files because it doesn't need to, it says that so you won't move or delete that folder, always keep it in the same path/directory. Try again

[namaiki]

emueyes, are you using MPC-HC 32-bit?

[madshi]

I've recently noticed the same thing.

I am a Nvidia user with a refresh rate of 60hz playing 23.976fps content.
Try "use separate device for presentation". That often helps. If not, try some of the "not recommended" exclusive mode tweak settings.

LAV Videos current RGB converter will not modify levels (at least its not supposed to, it might be a bug if it is). If input is limited-range YUV, its supposed to output limited range RGB.

The new RGB converter i'm planning will offer an option for you to force TV or PC levels, but default to the same logic as its now, not doing any level conversions (which i think is the best way to interface with madVR)
Sounds good to me. Once you implement this, could you please also tell madVR which levels you convert to (DXVA_ExtendedFormat)? For that you'd only have to set the NominalRange part of the structure. You could leave the other fields empty, until you add full support for all those values.

So, I watched the GPU clock with GPU-Z and it seemed constant at 796 MHz (don't know why it isn't 800 as shown in catalyst though...) all the time. So I guess it isn't downthrottling.

Could the GPU memory size be a problem? Or what else?

Its also suspicious to me that the GPU usage graph (in process explorer) never goes above ~15% if the GPU would lack the power wouldn't it be much higher?
Have you tried reinstalling the GPU drivers? I'm not sure where the problem is coming from. Don't know what else to suggest.

Why is there (can be) tearing in windowed mode, compared to exclusive? Also does exclusive means what it implies, that other programs can't use the GPU at all?
In windowed mode the OS copies the rendered frames to screen. If the copy is done while the VSync is in the middle of the screen, you'll get tearing. In exclusive mode the rendered frames are not copied to screen, they're swapped via VSync interrupt. So tearing can't occur.

In exclusive mode other programs may eventually still be able to use the GPU, but they can't show anything visible.

You say 400000 means 25p or 50i. Is madVR able to make the difference between progressive and interlaced content?
madVR shows "frames per second" not "fields per second". The current madVR version can't do deinterlacing, so it expects progressive content from you.

Told you how. The sample is limited range. When ffdshow or LAVV output converted full range RGB madVR still thinks it is limited range, and it double expands. Other videos work fine.
Ok, I can reproduce the problem. Looks like a simple bug which should be easy to fix (without breaking anything else) for ffdshow. LAV Video is a different topic. Accordingly to nevcairiel's posts LAV Video does currently not do what it's supposed to do, so I consider that a bug in LAV Video. This problem should be fixed in a future LAV Video version.

Yep, that is a different issue, should have separated it. Want a fraps sample?
Yes, please. Thanks.

If you know that, and that's the key here, then offer option(s) so we can bypass the limitations.
There already is an option, see my previous post.

RGB is like the holy grail, it bypasses all the postprocessing and crap drivers do
It does not, unfortunately. Even if you feed RGB to EVR/VMR/Haali, the GPU might still screw up the levels. E.g. set ATI to "RGB Limited" and the GPU will stretch 0-255 to 16-235 behind your back. Or use NVidia with an "SD" or "HD" standard resolution, and you have the same problem. With NVidia you have to create a custom resolution to work around the problem.

Besides, we here are not average users. I can't believe you offer options to configure a lot of uber minor things and you are so frontal against something so simple as levels, which are one of the most common problems out there.
I want to make things easy for the average user. Which means that ultimately madVR will get a display setup wizard which will guide the user through setup of every newly detected display (PC levels vs. video levels etc). Once that is done, madVR will make sure that the required levels are actually output to the display. This can only work if madVR can automatically detect what levels upstream filters are sending to madVR. I believe I should be able to make the autodetection work in 99.9% of all cases. Without autodetection, the user would have to manually tweak all the decoder filters etc to make sure that RGB is converted to the right levels. Furthermore, if the user moves the media player from his computer type LCD monitor to the secondary projector, suddenly he'd have to switch RGB levels, which I consider a usability catastrophe.

I had some issue reading very high bitrate files in MPC-HC. I had several frame drops. I tried different filters and could not make it work.
Which queue is at which state in the madVR OSD (Ctrl+J) when you get the frame drops?

Moreover, for all files, I get lots of frame drops when I go back to windowed mode. Moving the windows fixes the issue. Any clue how to fix this in the settings. Maybe different flushing strategy?
Same question as above.

As for the OSD, I might not have been clear about the small grey OSD that pops up on top left corner of the screen while jumping a minute or 5 mins, I don't want it to be disabled completely,
I want to use Potplayer's own OSD time-stamp while jumping or seeking.. Is there a way to do this?
Basically you've repeated your question. So I'll repeat my answer: ;)

madVR does not show an OSD when seeking, unless the media player asks for that. You may have to talk to the Potplayer developer about this.

Also, I just noticed yesterday while trying to capture a frame I would get a blurred/corrupt image. This didn't happen when using EVR, so I'm guessing I need to configure something in madVR?
Can you reproduce that? If so, please upload a screenshot with madVR vs. EVR.

[Zed86]

Basically you've repeated your question. So I'll repeat my answer: ;)

madVR does not show an OSD when seeking, unless the media player asks for that. You may have to talk to the Potplayer developer about this.


Can you reproduce that? If so, please upload a screenshot with madVR vs. EVR.

Here ya go.

http://img279.imagevenue.com/loc66/th_170765191_Monk.S05E07.avi_000304.142_122_66lo.jpg (http://img279.imagevenue.com/img.php?image=170765191_Monk.S05E07.avi_000304.142_122_66lo.jpg) http://img232.imagevenue.com/loc125/th_170767438_Monk.S05E07.avi_000304.309_122_125lo.jpg (http://img232.imagevenue.com/img.php?image=170767438_Monk.S05E07.avi_000304.309_122_125lo.jpg)



Oh and as for the OSD, last time ;),
I want it to display it as EVR or Haali or even VMR9,
(the same font, color, size..) madVR is the only one to show it's own OSD and I wanna know, if possible, how to revert to the original blue Potplayer OSD. I know I can let Potplayer not show it, but I need it, just not the black one lol

Thanks.

[madshi]

Here ya go.
Weird. Do you actually see the corrupted image on screen in PotPlayer? Or does the corruption only occur if you try to capture? How do you capture? Using PotPlayer's internal capture functionality? Or pressing Ctrl+Print? Or some other way?

Oh and as for the OSD, last time ;),
I want it to display it as EVR or Haali or even VMR9,
(the same font, color, size..) madVR is the only one to show it's own OSD and I wanna know, if possible, how to revert to the original blue Potplayer OSD. I know I can let Potplayer not show it, but I need it, just not the black one lol
I don't have any control over what kind of OSD PotPlayer shows. I don't show my own OSD when a seek is done. But PotPlayer might invoke madVR's OSD, there's an API for that, I don't know if PotPlayer is doing that. You will have to talk to the PotPlayer developer. There's nothing I can do here.

[emueyes]

emueyes, are you using MPC-HC 32-bit?

I'm running 64bit MPC-HC.

Also tried just running the batch file, with the same result.


Is madVR 32bit only? I guess I should have looked first before making a silly mistake like that. The Arcsoft drives were also 32bit, but gave a slightly different message.

[namaiki]

madVR is 32-bit only.

[Zed86]

Weird. Do you actually see the corrupted image on screen in PotPlayer? Or does the corruption only occur if you try to capture? How do you capture? Using PotPlayer's internal capture functionality? Or pressing Ctrl+Print? Or some other way?


I don't have any control over what kind of OSD PotPlayer shows. I don't show my own OSD when a seek is done. But PotPlayer might invoke madVR's OSD, there's an API for that, I don't know if PotPlayer is doing that. You will have to talk to the PotPlayer developer. There's nothing I can do here.

- No, it only looks like that in the output folder after capture or when a I open the photo file of course. The frame looks fine within Potplayer.
I use the Potplayer internal frame capture.


- But PotPlayer might invoke madVR's OSD, there's an API for that, I don't know if PotPlayer is doing that.

Ok that makes sense, I assume that Potplayer is invoking/forcing madVR to produce an OSD.
Btw, excuse my ignorance, but what do you mean by API?

Thanks..

[jimwhite]

Btw, excuse my ignorance, but what do you mean by API?

Thanks..

Google is your friend...

[madshi]

- No, it only looks like that in the output folder after capture or when a I open the photo file of course. The frame looks fine within Potplayer.
I use the Potplayer internal frame capture.
Then it's most probably a bug in PotPlayer.

[Zed86]

Then it's most probably a bug in PotPlayer.


I tried to capture a frame from different video files using MPC-HC, once with EVR CP and once with madVR. EVR would produce a jpeg file tha's saved on my desktop,
however, madVR would not, and instead I would get this error message from MPC-HC "GetDIB failed, hr = 80004005"
and that's it I click ok and continue playing the file! Why is that you think?

[namaiki]

I tried to capture a frame from different video files using MPC-HC, once with EVR CP and once with madVR. EVR would produce a jpeg file tha's saved on my desktop,
however, madVR would not, and instead I would get this error message from MPC-HC "GetDIB failed, hr = 80004005"
and that's it I click ok and continue playing the file! Why is that you think?

I believe it's because MPC-HC hasn't implemented "Save image" function with madVR yet.

[madshi]

madVR does not support screen capture yet. You can work around that by pressing the "Print" key in windowed mode. I've no idea what PotPlayer does to make screen capture work with madVR, and I don't really care much, because (as I said) it's not supported by madVR yet.

[mzso]

Have you tried reinstalling the GPU drivers? I'm not sure where the problem is coming from. Don't know what else to suggest.

OK then. Thanks! Actually I just updated the drivers. Anyway I'll just keep experimenting.

In windowed mode the OS copies the rendered frames to screen. If the copy is done while the VSync is in the middle of the screen, you'll get tearing. In exclusive mode the rendered frames are not copied to screen, they're swapped via VSync interrupt. So tearing can't occur.

Thanks for the info!

[STaRGaZeR]

@madshi: It seems it's a lost cause. 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.

[cyberbeing]

Thinking about what STaRGaZeR has been saying, maybe it wouldn't be a bad idea to release a separate stripped down version of madVR for people who just want a basic renderer or have crappy GPUs.

Remove the settings dialog completely, remove 3dlut/gamma/gamut correction, modify required shader operations for speed, remove built-in decoders, remove refresh-rate changer, have three resizer presets Fast (bilinear) + Soft (softcubic) + Normal (bicubic), assume RGB is always fullrange while auto-detecting YUV range, always output PC->PC and TV->PC levels by default, have selected resizer and overrides toggled by keyboard shortcuts, and call it madVR_lite.

As much as this goes against your goal for madVR, I could see how madVR not being a drop-in replacement for EVR/VMR9 or Haali could turn people off from using it. Some people don't care about color accuracy or customization, and just want a low system-requirements renderer which is reliable and works as expected without user intervention. Since madVR_lite and madVR would target two different subsets of users, I don't see why they couldn't co-exist.

Of course, you could also just modify the entire madVR shader chain so the 3DLUT does 0-255 -> 0-255 instead of 16-235 -> 16-235 to overcome all these input levels limitations. That way you could safely default to RGB being pc-range as is normal. Is there some merit in processing the video in 16-235 vs converting to 0-255 and then processing? Since you see no problem of converting 0-255 to 16-235 for processing and then back to 0-255, I assume not.

[madshi]

maybe it wouldn't be a bad idea to release a separate stripped down version of madVR for people who just want a basic renderer or have crappy GPUs.
No such thing coming. Not anytime soon, probably not ever.

Of course, you could also just modify the entire madVR shader chain so the 3DLUT does 0-255 -> 0-255 instead of 16-235 -> 16-235 to overcome all these input levels limitations. That way you could safely default to RGB being pc-range as is normal.
"Input levels limitations"? Not sure what you mean with that. And I don't consider RGB being PC range as "normal" in the video playback world. It's just one of two options. If you e.g. switch CoreAVC to RGB output, it will output 16-235 as default, for limited range h264 content. Also you can configure ffdshow to output either 0-255 or 16-235. nevcairiel has similar plans for LAV Video. And he will output 16-235 by default, too, for RGB. So if I changed madVR to always consider RGB 0-255, that would be a very very bad solution. That's also not what STaRGaZeR wants. He wants madVR to passthrough RGB untouched, without *any* processing at all. So basically he wants ffdshow to decide whether the display needs video or PC levels, rendering the madVR display management superfluous.

Is there some merit in processing the video in 16-235 vs converting to 0-255 and then processing?
Yes, processing in 0-255 means BTB and WTW are lost.

[Zed86]

madVR does not support screen capture yet. You can work around that by pressing the "Print" key in windowed mode. I've no idea what PotPlayer does to make screen capture work with madVR, and I don't really care much, because (as I said) it's not supported by madVR yet.

OK so why did you say it's a bug in Potplayer?
since it's not supported anyway even in other players?

[madshi]

It was PotPlayer who created that corrupted image, was it not? So who's fault can it be, if not PotPlayer's? There's no way for PotPlayer to make madVR do a screen capture, so it can't be madVR's fault.

[STaRGaZeR]

If you e.g. switch CoreAVC to RGB output, it will output 16-235 as default, for limited range h264 content.

That's incorrect. This (http://img59.imageshack.us/img59/1162/core32evr.png) is how CoreAVC 2.5.5 outputting RGB32 with default settings looks. Compare it to the shots in post #9451 (http://forum.doom9.org/showpost.php?p=1521326&postcount=9451). It outputs full range RGB for both limited range and full range H.264. And of course it gets double expanded in madVR.

[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.

[BetaBoy]

STaRGaZeR... nevcairiel... I've asked the guys to look into it.

[Zed86]

It was PotPlayer who created that corrupted image, was it not? So who's fault can it be, if not PotPlayer's? There's no way for PotPlayer to make madVR do a screen capture, so it can't be madVR's fault.


Would any other player be able to do a frame capture while using madVR? if yes please let me know as I might use it.
But if not then it is a "missing" function of madVR, which pretty much means it's madVR fault to begin with.
Now if it is able to produce a frame capture with any other player, then yeah it would be Potplayer's fault.

[madshi]

But if not then it is a "missing" function of madVR, which pretty much means it's madVR fault to begin with.
Bah. If you require a feature complete product then go away and come back once madVR has reached v1.0. It has been discussed multiple times in this thread that madVR does not yet support screen capture. There's a reason why the madVR version number still starts with a "0".

That's incorrect. It outputs full range RGB for both limited range and full range H.264. And of course it gets double expanded in madVR.
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.

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.

STaRGaZeR... nevcairiel... I've asked the guys to look into it... but iirc it has already been addressed in CoreAVC 3.0.
Thanks for the heads up!! :)

[BetaBoy]

Thx for the DXVA info.

[Zed86]

Bah. If you require a feature complete product then go away and come back once madVR has reached v1.0. It has been discussed multiple times in this thread that madVR does not yet support screen capture. There's a reason why the madVR version number still starts with a "0".

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.

[mzso]

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]

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]

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. :)

"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]

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.

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]

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/patents.html?patnums=US_7929754

A bit worrying, since it sounds like OpenMediaFormat (http://sourceforge.net/projects/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. :D
Besides, why would MS sue you for using their openly documented structure, in their DirectShow environment, on their OS? o.O

[vivan]

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).

Which decoder are you using?internal and ffdshow.

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 (http://home.halden.net/mordor/game_of_thrones.png)

[cyberbeing]

We're in europe, we don't care about the USes idea of software patents. :D
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]

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]

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 :mad:

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]

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/patents.html?patnums=US_7929754

A bit worrying, since it sounds like OpenMediaFormat (http://sourceforge.net/projects/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]

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.

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.


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 :mad:

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]

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 :eek:... more and more "HTPC's" every day are hooked up to Largescreen TV's of the LCD/PLASMA persuasion which expect VIDEO (limited) levels.... :p

[6233638]

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?
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]

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)http://forum-images.hardware.fr/images/perso/3/ostro%20gaud.gif

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 :devil: