madVR - high quality video renderer (GPU assisted)

[SirMaster]

Originally Posted by ryrynz

No issues with resolution, location is the problem.

if (srcHeight <= 480) and (filepath = "E:\*.*")
"480"

E: is the ISO mounted location.
I've also tried E:\Video_TS\*.* but that doesn't work either. I've had to resort to using an else statement to get it to select the appropriate profile.

Can anyone else confirm this?

In MPC, enable the web interface and open up the variables page:

http://localhost:13579/variables.html

Here you can see the paths for playing media files that MPC will be sending to madVR, so check the paths of your playing ISOs to see how you would write your profile selection rules.

[Sunspark]

Originally Posted by el Filou

@Sunspark: can you create a file named ShowRenderSteps (with no file extension) in madVR's program files folder, and then take screenshots of madVR OSD during playback (wait for the clocks and GPU utilization to stabilize) on both Win7 and Win10 and compare the figures? To check if the GPU utilization is due to one particular step of madVR's pipeline or if all steps have higher rendering times on Windows 10.
(I know it's cumbersome, but I don't see another way to find out what is causing that much higher usage)

Thanks el Filou for the suggestion to look closer again with the ShowRenderSteps.

The mystery is solved.

In Win7 I wasn't using exactly the same settings, so I thought to myself, let's try to make it more like the setup in Win10 for consistency in measurement so I added a module I wasn't using there, and all of a sudden, heavy usage in Win7 too.

It was the subtitle renderer that was adding all the extra usage, but also another setting as well. Different combinations of stuff will vary cpu & gpu usage, etc. slightly but it generally came down to 2 settings together. Overlay mode and the subtitle renderer.

overlay mode on, xysubfilter on - heavy usage
overlay mode off, xysubfilter on - heavy usage
overlay mode on, internal subtitle renderer on - heavy usage
overlay mode off, internal subsubtitle renderer on - normal usage
overlay mode on, assfilter on - heavy usage
overlay mode off, assfilter on - heavy usage

There is only 1 combination in mpc-hc that doesn't crank up the power if you need to have subtitles on as I do. DON'T use D3D9 Windowed Overlay mode and ONLY use the player's internal subtitle renderer.

Such a shame, because xysubfilter has sharper rendering and better positioning. Sigh..

Incidentally, in D3D9 windowed (non-overlay) mode backbuffers has lower cpu/gpu usage than frames in advance.

Image below is what it looks like with xysubfilter active.. all the extra rendering steps that doesn't happen with the internal subtitle renderer.

[el Filou]

Excellent news.
Have you tried D3D11 presentation to see if it worked better than D3D9? Broadwell's iGPU should be recent enough to work well with it, but sometimes there are quirks.

Originally Posted by SirMaster

In MPC, enable the web interface and open up the variables page. Here you can see the paths for playing media files that MPC will be sending to madVR

That's really strange, it shows the correct path (E:\VIDEO_TS\VIDEO_TS.IFO), but the rule still doesn't work when it's a DVD. Are you sure that's how madVR gets its file info?

[clsid]

MPC does not send any filenames to madVR. I assume madVR uses standard DirectShow interfaces to get the filename from the source filter. The DVD navigator probably does not implement that interface.

Originally Posted by Sunspark

Such a shame, because xysubfilter has sharper rendering and better positioning. Sigh..

Nonsense. You can let the internal renderer run at 4k resolution if you want. You need to check your settings.

[ryrynz]

Originally Posted by clsid

MPC does not send any filenames to madVR. I assume madVR uses standard DirectShow interfaces to get the filename from the source filter. The DVD navigator probably does not implement that interface.

Can we fake it somehow so the path can be parsed for MadVR to pick up on? Having a profile specifically for DVD ISOs would be quite a boon.

[clsid]

If it isn't working properly, then it is something that madshi has to fix. I have checked and the DVD Navigator does also expose the required interface for getting file path.
https://docs.microsoft.com/en-us/win...lesourcefilter

What you could try is to check if the path variable is empty for ISOs. Or if it does not contains any / or \ characters.

[doffen]

Originally Posted by clsid

MPC does not send any filenames to madVR. I assume madVR uses standard DirectShow interfaces to get the filename from the source filter. The DVD navigator probably does not implement that interface.

Nonsense. You can let the internal renderer run at 4k resolution if you want. You need to check your settings.

Is there still any advantages of using xysubfilter then?

[huhn]

Originally Posted by doffen

Is there still any advantages of using xysubfilter then?

sub title moving, smooth motion compatible and calibration but sharpness was never part of it.

[doffen]

Thanks! I'll stick with xysubfilter then since I use 3dlut with madvr. (assuming these works for the subtitles as well)

[huhn]

xy does the internal renderer doesn't.

[Sunspark]

I'm not so sure about the whole sharpness is the same aspect. It might be player specific because even with two different ones set to use the internal subtitle renderer and both set to use "desktop" as the texture resolution, one is sharper than the other. But on mpc-be xysubfilter is noticeably sharper than the internal renderer set to desktop on my system. Whereas on mpc-hc (1.7.13) it doesn't make a difference, both internal and xysubfilter are both sharp so it makes sense to use the internal one to reduce gpu load otherwise it will be 3x load. The converse is true on mpc-be because xysubfilter does not increase gpu load when paired with the mpc video renderer so in that player xysubfilter should be used instead of the internal subtitle renderer if you are using d3d9 as I am.

The subtitle moving support in madvr, I don't believe it works all that well with the internal subtitle renderer in mpc-hc because I did test it out. Made sure dxva2 copy-back was being used because I determined the following things: subtitle moving will not take place if you do not have black bar detection turned on (which in turn is dependent on having copy-back). When this condition is met, and the subtitle is moved, only one of the two options works well. Moving into the active video area does work and will move the subtitle into the video picture itself. However, most people want the subtitle below for non 16:9 content, and the option "move subtitles to bottom of screen/window" just doesn't work at all. So, in that scenario don't even waste your time with that option. Leave it off along with black bar detection off since you won't need them, and instead in subtitle style settings for the margin for top and bottom, change it from 20 to 1. It'll be a compromise. Subtitles with 2 lines will be nicely centered in the black portion below the video. Subtitles with 1 line unfortunately will be at the bottom of the monitor. Nothing can be done about it, not even turning the madvr option for "bottom" back on. Movies and shows that aren't 16:9 will have black bars which is why this situation of subtitle moving or lack thereof may not always be noticed if all your content is exclusively 16:9.

So, I have another stupid edge case bug to warn you about in Windows 10 with madvr. If you are using dxva2 copy-back and have exclusive mode turned on (and yes for good measure i also have "disable full-screen optimisations" checked in the player's windows file properties) do not have "frames in advance" selected in madvr options for both windowed mode (which is where your playback begins first) and exclusive mode. If you have frames in advance selected for both, what happens is that something gets stuck with the gpu load, it is higher than it should be when in windowed mode and remains higher when you switch into fullscreen exclusive. Windowed mode needs to have frames in advance unchecked, and it's ok to use frames in advance for exclusive. If you have the two separate, one with backbuffers and the other with frames in advance, then the gpu load will be ok for both and not get stuck at a higher utilization. Unfortunately, there is no benefit in using backbuffers for exclusive also, because it will be higher gpu usage than with frames in advance. It doesn't make sense to me that windowed mode uses lower gpu with backbuffers and exclusive is lower with frames, but you can't have both set to the same thing at the same time, or that if you reverse the options and make windowed frames, and exclusive backbuffers then both will have higher gpu usage.

What can you do? There is no such thing as a perfectly implemented player anywhere, always edge case bugs and glitches. Even Microsoft's Movies & TV (Films & TV) player which is backed by a huge corporation has the following annoyances that I have noticed: subtitles are unable to show outlines, everything else works just not the option to choose outline, raised, etc. so you have to live with subtitles that have no separation from the video unless you are willing to accept a black bar behind it. It cannot play AC3/E-AC3 audio. It cannot play 10-bit anime files. It does however have the best lower power consumption which is important to know about if you're running off batteries for awhile.

[clsid]

You are using a 4 year old version of MPC-HC. Latest one is 1.9.14.

If you want subs below video, then simply disable the option in MPC-HC to render relative to the video frame. Then it will render relative to window. Or semi-checked (= default) which means relative to window for normal subs, and relative to video for anime stuff.

[huhn]

the new interface can move text only and does not move typeset and such.

what so ever a device with dead driver should not be considered as the general state of things.

[ashlar42]

Originally Posted by SamuriHL

No, something is wrong there. Are you SURE your LG is set to low? Because it absolutely should be Limited, FULL, Limited (madvr, gpu, display).

Sorry for quoting an old post but I just wanted to double check on this.

While this works fine, and I understand it's the best choice (no scaling during color conversion YCbCr-->RGB), is it normal to have crushed blacks on desktop applications, right?
It's not a problem, as I can select a different picture mode (maybe Game) when I need to play a game (and have Black Level set to Full for that picture mode) but I just want to be sure that it's normal for that to happen.

Thanks.

Edit: for people curious about this, I find this post to be quite informative https://kodi.wiki/view/Video_levels_and_color_space

[el Filou]

Yes, it's expected.

Edit:

Originally Posted by Sunspark

Windowed mode needs to have frames in advance unchecked, and it's ok to use frames in advance for exclusive. [...] Unfortunately, there is no benefit in using backbuffers for exclusive also, because it will be higher gpu usage than with frames in advance. It doesn't make sense to me that windowed mode uses lower gpu with backbuffers and exclusive is lower with frames, but you can't have both set to the same thing at the same time, or that if you reverse the options and make windowed frames, and exclusive backbuffers then both will have higher gpu usage.

I think those observations are highly specific to your iGPU. I've tested every combination just out of curiosity, with both DXVA scaling and madVR shaders scaling, and there is 0 difference between backbuffers and presented frames in advance on my GeForce and my legacy Radeon. Exclusive mode has a very small GPU usage advantage on the Radeon but it's 14% Vs. 18% at best which isn't worth the inconvenience.
Also, if you're going to use DXVA chroma & image scaling anyway, you may as well not use madVR at all except if you need some specific misc. feature.

[huhn]

the kodi page is incomplete the range is 16-235 for luma and 16-240 for chroma.

so the argument ycbcr -> rgb limited doesn't need a level conversation is invalid.

the fact that ycbcr to limited and to full are float point operation and can be done directly and even have existing coefficients to do it directly so there is no scaling.
https://mymusing.co/bt-709-yuv-to-rgb-conversion-color/

there is one exception that's black white Y only to RGB (test pattern) where the limited conversation is lossless no dithering needed i guess that's the reason they don't dither with limited range even through it's just wrong...

the recommended levels are still full full full.
https://www.avsforum.com/threads/mad...#post-23457822

[chros]

I'm not sure about that, if you use an sdr 3dlut:
- full, full, full: clips whiter than white (wtw)
- limited, full, limited: passing through wtw

You can try it with white clipping pattern form avshd bt709 set.
I still use full, full, full, because I didn't create a 3dlut for the other one, but I have set limited, full, limited for HDR10 otput.

[huhn]

3D lut can be bugged with madVR if they come from displaycal/argyllCMS.

WTW and BTB can go crazy.
there is a fix clipping btb and wtw but madshi says it should be fixed in displaycal/argyllcms and they say wtw or btb as input is not allowed and should be clipped neither fixed it.
try a clipping shader.

this has nothing to do with out put level the 2D LUT will still do 100 % the same it's just with showing wtw and btb you can see heavy artifacts.

if that's even the issue you are talking about.

[chros]

Good question, not sure, I would have to create one 3dlut for limited to see whether it behaves the same or not. But if you have a full 3dlut for madvr (created by displaycal) then you can quickly try it out.

[huhn]

if it is the same issue i may not be affected at all.

even if you create a limited range LUT madVR still feeds WTW or BTB and that compromised by something like the chroma scaler or even image scaler and it is not able to output it. it's not made for it. it should never be feeding it into a 3D LUT with limited or full range output.

BTW. the 3D LUT doesn't at all it's always limited range as input and just to stop the confusion this is irrelevant for output ranges.

edit: my current 3D LUT does not seem to expose the issue. it's hard to judge with the coating of this TV...