madVR - high quality video renderer (GPU assisted)

[M@ssy]

If I keep active the image doubling with the cuvid, the images freezes once in full screen :(

[huhn]

known issue with CUVID use DXVA copy back.

[madshi]

I mean jumping to different parts of the video. Remember the crash involving smooth motion? Like that.

The anime I tested with is 1080 with no black bars, so it takes up the full screen when upscaled to 4k, I guess a 1080 screen with a 1080 source would also work. When I have "to the bottom of the screen/window" selected and I start the video, the subtitles start on the very bottom as expected. But if I jump around, the subtitles move north, and end up where the subtitles would be if I had selected "into active video area". So I guess you could say the first option in 'move subtitles' doesn't work correctly.
Are you 100% sure you're using XySubFilter 745? What you're describing very much sounds like 744. Please double and triple check - thanks! If you're absolutely and totally sure you're using 745 then please provide me with a small sample of that video file.

0.89.9: at start goes to 330k and stays about there no matter what I do
0.89.11: at start goes to 330k, then after first max.->min. to 580k, 2nd max.->min. to 820k and just keeps on growing with roughly that speed to 1G, 2G...
I've tried, but I can't reproduce it. Not sure if I have asked this before: Are you using hardware or software decoding? Try software. Do you maybe have a different PC you could try this with? This does sound a bit like the AMD beta driver bug leaking memory, but then I don't know why it should only affect v0.89.11 and not v0.89.9, that doesn't make sense to me.

If all else fails, I'll have to create a couple of test build between v0.89.9 and v0.89.11 to get to the bottom of which exact change caused this issue for you. But really, none of the changes look like they could cause this issue to me, so I'm quite confused about this one.

The subtitle margin changes with scale using XySubFilter, not with the internal mpc engine.
You mean the amount of space between the bottom of the video and the bottom of the subtitles? Yeah, I'm currently using a fixed number of pixels. I suppose I should use a certain percentage of the video height instead.

i actually do have a problem i can't seem to resolve on my own: for a few releases automatic refresh rate changing hasn't worked. it's not a big deal as the only thing it helps with is 25 fps (i have 50, 60, and 66 profiles in nvidia settings) which i don't watch often. all that happens is occasionally the screen will flicker after player close, if it happens at all

doesn't matter if i use dx9 or 11, fse or not, switch on playback start or fullscreen

win 8.1, gtx 970, 358.50 drivers, MPC-BE x64 1.4.5 787, madvr 89.11, lav 66
If you think a recent madVR build introduced the problem then please try to isolate which exact build that was. You can download all older builds here:

http://www.videohelp.com/software/madVR/old-versions#download

Otherwise, you could try to create a debug log, then I can tell whether madVR tried to switch refresh rates.

I switched to the internal subtitle renderer in MPC-BE and all problems are gone.
What is "all problems"? Your post contains almost zero information.

[ashlar42]

I still see subs size changing with rescaled size changing. Now, I post two extreme options, taken from desktop, but even at 1080p and ten feet use with HTPC... it means I can't select an ideal subs size because it's either too small, too big, according to the rescaled size. With the flurry of new releases, which I've tried to keep on top of, I forgot whether this was something that was supposed to be already fixed, if it's a planned fix or if it's going to stay like this. Sorry... :)

http://i57.tinypic.com/2qscqo9.jpg

http://i60.tinypic.com/2mfibq.jpg

madVR 0.89.11, XySubFilter 3.1.0.745

[madshi]

The text subtitles are supposed to be scaled with the video size. All subtitle renderers behave that way. What the subtitles are not supposed to do is change their size if you tell madVR to move them (they did that in v0.89.9). Letting madVR move them should only change their position, but not their size.

[aufkrawall]

Worked fine for me. Most likely an error in your script. There's a little green check mark that comes up when it thinks everything is correct.
Thank you so far.
I still need some help though.

My idea is very simple:
I want madVR to pick the appropriate profile based on scaling factor and fps. I was hoping that a simple enumeration of "if" conditions would do the job, but unfortunately it doesn't.

My script looks like this:
if (scalingFactor.x = 1.0) and (scalingFactor.y = 1.0) "1.0"
if (scalingFactor.x < 1.0) and (scalingFactor.y < 1.0) "< 1.0"
if (scalingFactor.x > 1.0) and (scalingFactor.y < 1.5) "> 1.0 < 1.5"
if (scalingFactor.x > 1.5) and (scalingFactor.y < 2.2) and (deintFps <= 30) "> 2.2 <= 30fps"
if (scalingFactor.x > 1.5) and (scalingFactor.y < 2.2) and (deintFps > 30) "> 2.2 > 30fps"

Problem is, it only activates profile "1.0" (script is valid, according to madVR). I tried to insert "else" at various places, but it didn't help the way I did it.
I'd be very thankful for ideas. :)

[ashlar42]

The text subtitles are supposed to be scaled with the video size. All subtitle renderers behave that way. What the subtitles are not supposed to do is change their size if you tell madVR to move them (they did that in v0.89.9). Letting madVR move them should only change their position, but not their size.Ok, maybe my example was the wrong one, sorry.

What I wanted to show is that, unless I'm mistaken, when scaling to 1080p the subs size seems to change according to the amount of scaling.

So I watch all stuff from 10 feet on a 60" screen but subs size varies according to the source size and the factor it needs to be scaled to. Is this intended behaviour?

[nevcairiel]

Problem is, it only activates profile "1.0" (script is valid, according to madVR). I tried to insert "else" at various places, but it didn't help the way I did it.
I'd be very thankful for ideas. :)

All but the first if should probably be "else if" instead, otherwise I see nothing wrong. Never tried to use it myself, I can give it a go in a while if it still doesn't work out.

[madshi]

madVR flashes frame from the future (probably last in the queue) on frame step. Not on every one, but very often. It looks like that Frame1->Flashes Frame (something from the queue)->Frame2 it is easily reproducible with MPC-HC and CTRL+left arrow to frame step. Seems to happen only with DX11. Here is log http://1drv.ms/1MswFTV
I've tried to reproduce it, but can't. With my AMD GPU and DX11 there's no flashing at all here. I'm still on Windows 8.1 x64, though, maybe that's the difference? Have you tried resetting madVR to default settings (just change to DX11 presentation afterwards)? Still the same problem? Software or copyback or native hardware decoding? Does it occur with every video or just some?

For me, the flashing was occurring on every subtitle line. Fortunately with v0.89.10 and XySubFilter 3.1.0.745, it seems the flashing only occurs on the first subtitle that occurs now instead of every line. And only when the video is played at a non-native aspect ratio / resolution of the file.
I think this should be fixed in the next build. If not, please let me know.

I have a sample from an HDTV cap that SM FRC has trouble with, maybe you can improve it's behavior.
With the latest MPC-HCx64, madVR and LAV, in the first 5 seconds there's heavy frame jumping/repeating and after that it plays fine, disabling SM fixes issue at the start.
I tried different decoding modes in LAV to no avail, but madVR's rendering path made a difference.
The issue above only happens as described with D3D9 new path, with Overlay and D3D11 it's almost gone, and there's still something going on (huge rendering time spikes etc).
When tested with MPC-BEx64 and it's internal decoder the issue isn't as bad, but doesn't stop after 5 seconds and keeps occurring till the end.
Ah, an old German Premiere HD broadcast. I know those well... :)

No problems on my PC at all. Ok, smooth motion FRC always has one small judder after about 1 second of playback or so, but that's normal. Other than that, playback is perfect on my PC, with both D3D9 new path and D3D11, both in Windowed and FSE modes.

Are you using software or copyback or native DXVA hardware decoding? Try software decoding, and try the "delay playback start" option in madVR. Maybe your CPU/decoder is simply too slow to deliver enough video frames for smooth motion FRC to work with, at the start of playback. Also check that deinterlacing is not turned on. It's not needed for this stream. Or if you want to turn it on, try with forced film mode.

[kasper93]

I've tried to reproduce it, but can't. With my AMD GPU and DX11 there's no flashing at all here. I'm still on Windows 8.1 x64, though, maybe that's the difference? Have you tried resetting madVR to default settings (just change to DX11 presentation afterwards)? Still the same problem? Software or copyback or native hardware decoding? Does it occur with every video or just some?

I've reseted settings. I changed only to DX11 and enabled ED and can reproduce. It is ED issue. I missed that. Yes, it happens with all videos. Doesn't happen when OSD Stats are enabled. Software decoding. You may need to frame step few frames before is starts to happen, but it is reproducible every time on my PC.

[chros]

Are you suggesting to do not use Superres in chroma upscaling? Just to understand.
Yes, I suggest not to use it (as madshi told us it uses a different algorithm, and wasn't updated for a while).
What about image refinement in case of image not upscaled (I.e. 1080p>1080p)? Which refinement do you suggest ?
If there's no upscaling (1080p>1080p) then those settings don't do anything! That's why it called "upsacling refinement". In contrast, "image enhancements" does, but there's no Superes under it.

But I don't use any of these sharpening filters, so you should ask the smarter guys about them :)

[tahaa7]

Sounds strange. Has that always been that way? Or is it a new problem? Are you using software decoding or copyback or native hardware decoding? What GPU? OS? This is not an Optimus system, is it?

It hasn't always been that way. I'm using MPC's built-in LAV filters with hardware (CUVID) decoding. The OS is Windows 7 Ultimate 32-bit. No, it is not an Optimus system.

[chros]

My script looks like this:
if (scalingFactor.x = 1.0) and (scalingFactor.y = 1.0) "1.0"
if (scalingFactor.x < 1.0) and (scalingFactor.y < 1.0) "< 1.0"
if (scalingFactor.x > 1.0) and (scalingFactor.y < 1.5) "> 1.0 < 1.5"
if (scalingFactor.x > 1.5) and (scalingFactor.y < 2.2) and (deintFps <= 30) "> 2.2 <= 30fps"
if (scalingFactor.x > 1.5) and (scalingFactor.y < 2.2) and (deintFps > 30) "> 2.2 > 30fps"

Problem is, it only activates profile "1.0" (script is valid, according to madVR). I tried to insert "else" at various places, but it didn't help the way I did it.

All but the first if should probably be "else if" instead, otherwise I see nothing wrong. Never tried to use it myself, I can give it a go in a while if it still doesn't work out.

As Nevcairiel says, use elseif, and since you want to use intervals, start it from 1 end and go to the other. Last, always leave a "Default" profile at the end, just in case :)
And I'm not sure that you need both x and y scalinfactor check but just one, if you prevent the change of aspect ratio.

if (scalingFactor.x < 1.0) "< 1.0"
elseif (scalingFactor.x = 1.0) "1.0"
elseif (scalingFactor.x > 1.0) "> 1.0 < 1.5"
elseif (scalingFactor.x > 1.5) and (deintFps <= 30) "> 2.2 <= 30fps"
elseif (scalingFactor.x > 1.5) and (deintFps > 30) "> 2.2 > 30fps"
else "Default"

[michkrol]

Problem is, it only activates profile "1.0" (script is valid, according to madVR). I tried to insert "else" at various places, but it didn't help the way I did it.
I'd be very thankful for ideas. :)

It seems to be a bug in madvr, your script should work. Using elseif is not necessary, althought recommended.

@madshi: I've narrowed it down to decimals not working in profile rules - the script is marked as valid (green "tick"), but rules don't work.
To give an example:
if (scalingFactor.x>1) "Profile 1" works correctly, while
if (scalingFactor.x>1.0) "Profile 1" doesn't work and
if (scalingFactor.x>1.5) "Profile 1" doesn't work either.

[nevcairiel]

madshi is german, did you try "1,0" instead? It would technically be the german way to write it.... =p

[michkrol]

Yes, I did try "1,0", but the rules didn't "validate" (a triangle over the textbox).
FWIW, my system('s lang settings) also expects commas (not dots) for decimals ;)

[aufkrawall]

Thanks for looking after this, I'd assume it's probably an easy fix for madshi. :)

[chros]

And I messed up the intervals check earlier, here's the proper one:
if (scalingFactor.x < 1.0) "< 1.0"
elseif (scalingFactor.x = 1.0) "1.0"
elseif (scalingFactor.x <= 1.5) "> 1.0 < 1.5"
elseif (scalingFactor.x > 1.5) and (deintFps <= 30) "> 2.2 <= 30fps"
elseif (scalingFactor.x > 1.5) and (deintFps > 30) "> 2.2 > 30fps"
else "Default"

[aufkrawall]

Ah, an old German Premiere HD broadcast. I know those well... :)

No problems on my PC at all. Ok, smooth motion FRC always has one small judder after about 1 second of playback or so, but that's normal. Other than that, playback is perfect on my PC, with both D3D9 new path and D3D11, both in Windowed and FSE modes.

Are you using software or copyback or native DXVA hardware decoding? Try software decoding, and try the "delay playback start" option in madVR. Maybe your CPU/decoder is simply too slow to deliver enough video frames for smooth motion FRC to work with, at the start of playback. Also check that deinterlacing is not turned on. It's not needed for this stream. Or if you want to turn it on, try with forced film mode.
I can confirm the problem. It occurs when the GPU queue is relatively long (e.g. 16 frames) and Smooth Motion is enabled at the same time.
Doesn't matter if FSE, D3D9 or not. :)
With a GPU queue of 8, it looks normal. But it can't be a problem with performance or video memory, it must be some weird coincidence.

[SecurityBunny]

I think this should be fixed in the next build. If not, please let me know.


Sure thing. As soon as the new build is available, I'll be sure to test and let you know if it is fixed from my end.

[Jtacdf]

I mean jumping to different parts of the video. Remember the crash involving smooth motion? Like that.

The anime I tested with is 1080 with no black bars, so it takes up the full screen when upscaled to 4k, I guess a 1080 screen with a 1080 source would also work. When I have "to the bottom of the screen/window" selected and I start the video, the subtitles start on the very bottom as expected. But if I jump around, the subtitles move north, and end up where the subtitles would be if I had selected "into active video area". So I guess you could say the first option in 'move subtitles' doesn't work correctly.

I've seen this behavior on some anime with ssa/ass subtitles as well. Using madvr 0.89.11 and Xysubfilter 746.

It will start at the botton and then push itself into the active box after a while. Here is a sample below that happens consistently for me.

https://www.dropbox.com/s/ivp11mz3s0inlw1/%5BCommie%5D%20One-Punch%20Man%20-%2002%20%5B2166BEE3%5D%20%281%29.7z?dl=0

[madshi]

Ok, maybe my example was the wrong one, sorry.

What I wanted to show is that, unless I'm mistaken, when scaling to 1080p the subs size seems to change according to the amount of scaling.

So I watch all stuff from 10 feet on a 60" screen but subs size varies according to the source size and the factor it needs to be scaled to. Is this intended behaviour?
I think the size should depend only on the size of the final video (after upscaling). But I don't really have much control over that. Does XySubFilter behave differently than the internal MPC-HC subtitle renderer?

I've reseted settings. I changed only to DX11 and enabled ED and can reproduce. It is ED issue. I missed that. Yes, it happens with all videos. Doesn't happen when OSD Stats are enabled. Software decoding. You may need to frame step few frames before is starts to happen, but it is reproducible every time on my PC.
Oh, thanks! Yes, was able to reproduce it with ED and the OSD off (two important things). The next build will fix this. And who knows - maybe it could even help for Intel users have those flashes when using DX11 presentation? Don't really know, though...

It hasn't always been that way. I'm using MPC's built-in LAV filters with hardware (CUVID) decoding. The OS is Windows 7 Ultimate 32-bit. No, it is not an Optimus system.
Does the problem go away if you use DXVA copyback? That's superior to CUVID, anyway.

I've narrowed it down to decimals not working in profile rules - the script is marked as valid (green "tick"), but rules don't work.
True. Will be fixed in the next build.

I can confirm the problem. It occurs when the GPU queue is relatively long (e.g. 16 frames) and Smooth Motion is enabled at the same time.
Doesn't matter if FSE, D3D9 or not. :)
With a GPU queue of 8, it looks normal. But it can't be a problem with performance or video memory, it must be some weird coincidence.
Hmmmm... No problem here with 16 frames.

I've seen this behavior on some anime with ssa/ass subtitles as well. Using madvr 0.89.11 and Xysubfilter 746.

It will start at the botton and then push itself into the active box after a while. Here is a sample below that happens consistently for me.

https://www.dropbox.com/s/ivp11mz3s0inlw1/%5BCommie%5D%20One-Punch%20Man%20-%2002%20%5B2166BEE3%5D%20%281%29.7z?dl=0
Ok, thanks. I can see the problem. Will work on a fix, but I'm not sure if I'll make it this weekend.

[ibius]

Ah, an old German Premiere HD broadcast. I know those well... :)

No problems on my PC at all. Ok, smooth motion FRC always has one small judder after about 1 second of playback or so, but that's normal. Other than that, playback is perfect on my PC, with both D3D9 new path and D3D11, both in Windowed and FSE modes.

Are you using software or copyback or native DXVA hardware decoding? Try software decoding, and try the "delay playback start" option in madVR. Maybe your CPU/decoder is simply too slow to deliver enough video frames for smooth motion FRC to work with, at the start of playback. Also check that deinterlacing is not turned on. It's not needed for this stream. Or if you want to turn it on, try with forced film mode.

I did mention that no decoding mode in LAV made a difference, I use copyback by default.
'Delay playback start' is also on by default here, and all queues are full, I use 12 and 8, present in advance also at 8.
Deinterlacing is off, and I also checked with default flush settings to rule that out as I have "don't flush" everywhere, didn't help.
I use MPC-HC and it only happens during first 4-5 seconds and stops as soon as you see the Universal globe, so it doesn't bother me much, but if I were using MPC-BE that would be another matter (see my first post), that's why I thought I should let you know.

[ashlar42]

I think the size should depend only on the size of the final video (after upscaling). But I don't really have much control over that. Does XySubFilter behave differently than the internal MPC-HC subtitle renderer?

Yes it does. I did precise measurings, with a ruler applied to my Kuro.

With style using Calibri bold, size 18, MPC-HC internal subfilter renders the O character at a fixed 1.8cm size. XySubFilter renders it at 1.5cm with black bars (2.40:1 aspect ratio), 2.0cm with no black bars (16:9 aspect ratio).

Tried with both MPC-HC and Kodi.

[madshi]

I did mention that no decoding mode in LAV made a difference, I use copyback by default.
'Delay playback start' is also on by default here, and all queues are full, I use 12 and 8, present in advance also at 8.
Deinterlacing is off, and I also checked with default flush settings to rule that out as I have "don't flush" everywhere, didn't help.
I use MPC-HC and it only happens during first 4-5 seconds and stops as soon as you see the Universal globe, so it doesn't bother me much, but if I were using MPC-BE that would be another matter (see my first post), that's why I thought I should let you know.
Then I suppose the MPC-BE internal decoder probably sends wrong timestamps. Just guessing, though.

Yes it does. I did precise measurings, with a ruler applied to my Kuro.

With style using Calibri bold, size 18, MPC-HC internal subfilter renders the O character at a fixed 1.8cm size. XySubFilter renders it at 1.5cm with black bars (2.40:1 aspect ratio), 2.0cm with no black bars (16:9 aspect ratio).
Is that with the MPC-HC ISR option "position subtitles relative to the video frame" checked or unchecked? Try with it checked, that's how XySubFilter calculates the font size.

[aufkrawall]

Then I suppose the MPC-BE internal decoder probably sends wrong timestamps. Just guessing, though.

Maybe there's something wrong with the encode of the first 5s, also Windows 10 Metro player seems to drop lots of frames with it.
So it's probably not a bug in madVR, but the exception treatment with SM maybe could be better?
But if it's really due to a weird encode, it might not be important imho.

[sneaker_ger]

Are you using hardware or software decoding?
I am using software decoding. DXVA Copy-Back is affected in the same way.
Memory consumption using DXVA native seems totally different. Quickly reaches ~50k but barely reaches 53k by end of sample even with all the maximizing<>100%zoom I can do.

Do you maybe have a different PC you could try this with?
No, not right now.

[ashlar42]

Is that with the MPC-HC ISR option "position subtitles relative to the video frame" checked or unchecked? Try with it checked, that's how XySubFilter calculates the font size.
I'll check but... If that's the case what's the logic behind having a setting that varies subs size according to source's aspect ratio?

Edit: I checked, yes, the correct behaviour (in my opinion) happens with internal subs renderer, in MPC-HC with "position subtitles relative to the video frame" unchecked. If there's already a way to get the same behaviour in XySubsFilter, I'd be interested to know it. If there isn't, as per above, I'd like to understand the logic behind the behaviour. Is there any time when changing subs size according to aspect ratio would be desirable?

[madshi]

Maybe there's something wrong with the encode of the first 5s, also Windows 10 Metro player seems to drop lots of frames with it.
So it's probably not a bug in madVR, but the exception treatment with SM maybe could be better?
But if it's really due to a weird encode, it might not be important imho.
I don't have the time to go on a wild goose chase for a video which is suspected to be a weird encode, and which furthermore seems to play just fine on my PC. If I could easily reproduce the problem, I would have had a look, but if it's just one video out of many that makes problems, then it's just not worth the bother. My development time is *VERY* limited. I need to spend it wisely.

I am using software decoding. DXVA Copy-Back is affected in the same way.
Memory consumption using DXVA native seems totally different. Quickly reaches ~50k but barely reaches 53k by end of sample even with all the maximizing<>100%zoom I can do.
Alright. <sigh> Guess I'll make some test builds. Not today anymore, though, maybe tomorrow.

Edit: I checked, yes, the correct behaviour (in my opinion) happens with internal subs renderer, in MPC-HC with "position subtitles relative to the video frame" unchecked.
But that was not my question. I wanted to know if you get the same varying font sizes with that option CHECKED, not unchecked. I explicitly wrote "Try with it checked".

[tahaa7]

Does the problem go away if you use DXVA copyback? That's superior to CUVID, anyway.

I am going to do some more testing and report back. Would you please elaborate on your statement that DXVA is superior to CUVID? And why copy-back, why not native? Shouldn't native be faster? Thanks.

[Knight77]

Yes, I suggest not to use it (as madshi told us it uses a different algorithm, and wasn't updated for a while).

If there's no upscaling (1080p>1080p) then those settings don't do anything! That's why it called "upsacling refinement". In contrast, "image enhancements" does, but there's no Superes under it.

But I don't use any of these sharpening filters, so you should ask the smarter guys about them :)

Ahhh I ment image enhancement!

However it would be interesting to know if superres in chrome upscaling is really not visible and what is the real influence of the image enhancement when there is not upscaling...

[ashlar42]

But that was not my question. I wanted to know if you get the same varying font sizes with that option CHECKED, not unchecked. I explicitly wrote "Try with it checked".
Sorry :(

Yes, with the option checked the subs size changes.

I didn't pay attention to this because with the option checked subs stayed inside the video frame and were not moved to the black bars, hence I mentally discarded it.

[Warner306]

Ahhh I ment image enhancement!

However it would be interesting to know if superres in chrome upscaling is really not visible and what is the real influence of the image enhancement when there is not upscaling...

Image Enhancements will do the same thing as Upscaling Refinement when applied to an image already resized. It sharpens the luma to add detail to the image. Upscaling Refinement does the same but waits for resizing to take place. So, both could be considered post-resize sharpening.

[aufkrawall]

I am going to do some more testing and report back. Would you please elaborate on your statement that DXVA is superior to CUVID? And why copy-back, why not native? Thanks.
Native will give you inferior quality with Nvidia and CUVID lacks control for developers and is partly broken on Windows 10.
With DXVA2 CB you will get the same performance & quality like with CUVID, just without the drawbacks.

[tahaa7]

Native will give you inferior quality with Nvidia

Inferior video quality? Why is that? Isn't copyback the same as native, plus one additional step of copying the data back from GPU to main memory (which would from a purely logical perspective make it slower and more resource-demanding)?

[aufkrawall]

It should be, but due to driver limitations, it isn't:
An ugly chroma conversion will make it look like bilinear scaling.
Copyback of LAV Filters is efficient, you won't notice it (unless you stare at the memory consumption of the media player or the very few percent additional CPU load).

[agustin9]

You mean the amount of space between the bottom of the video and the bottom of the subtitles? Yeah, I'm currently using a fixed number of pixels. I suppose I should use a certain percentage of the video height instead.

Yes, that's what I mean. That should do it, thanks!

[tahaa7]

It should be, but due to driver limitations, it isn't:
An ugly chroma conversion will make it look like bilinear scaling.
Copyback of LAV Filters is efficient, you won't notice it (unless you stare at the memory consumption of the media player or the very few percent additional CPU load).

OK, but I still don't understand where the difference in video quality would come from (between native and copyback, perhaps even CUVID for that matter), given everything else is the same. Shouldn't the only difference between them be in terms of performance and GPU/CPU load? Sorry, but I'm not a huge expert in all this, and I would like to learn about the differences and advantanges and disadvantages and why they occur.

[aufkrawall]

I'm not an expert either, but it'd assume there gets some control lost for the renderer when you want the GPU to output DXVA frames (with copyback, you can do whatever you want with the frame).
There was an option to prevent this via OpenCL (some kind of frame copy on the GPU?), but it didn't work with Nvidia.
I don't know if it's silently activated for AMD or Intel with DXVA2 native or if they would suffer worse quality too.

In the end, this is quite a luxury problem with DXVA2 CB of LAV.
It's a good thing that madshi currently spends his time on more useful things.

[madshi]

Yes, with the option checked the subs size changes.
Ah, thanks, that's as expected.

To explain: madVR has no direct control over the font size selected by any subtitle renderer. All madVR delivers to the subtitle renderer are rectangles into which the sub renderers are asked to draw, and then the sub renderers themselves pick the font size they find suitable for each such rectangle.

In older madVR builds (builds before v0.89.7) madVR always asked XySubFilter to draw the subs into the active video area, which is similar to what the MPC-HC internal subtitle renderer does when the option "position subtitles relative to the video frame" is checked.

Starting with v0.89.7 (up to v0.89.9) madVR tried to simulate what the MPC-HC ISR does when unchecking the mentioned option. However, this caused all sorts of trouble with SSA/ASS subtitles. Also it made the font size change, when users activated or deactivated the "move subtitles" option in madVR, which some users complained about. Some users also found the font sizes to simply be too large overall.

So in v0.89.10+ I went back to let XySubFilter render into the active video rect, and then afterwards I'm simply changing the positions of the subtitles to go into the black bars. The benefit of this solution is that when users activate and deactivate the "move subtitles" option in madVR, the font size does *not* change. It stays the same. However, the disadvantage is that now depending on the video aspect ratio, the font size might differ somewhat. That's really out of my control, though.

The final solution should be for XySubFilter itself to be more consistent about font sizes. cyberbeing (the XySubFilter maintainer) has already invested some thoughts about this. But he isn't really a developer, so don't expect anything any time soon. As it stands, it is what it is. Both solutions I could implement have their own advantages and disadvantages.

OK, but I still don't understand where the difference in video quality would come from (between native and copyback, perhaps even CUVID for that matter), given everything else is the same?
Both CUVID and "copyback DXVA" are very similar. CUVID also always includes a copyback operation. The only advantage CUVID offers over copyback DXVA is that CUVID supports deinterlacing inside of LAV Video Decoder, which copyback DXVA currently does not support. But that's really not very important, when using madVR. So there's pretty much zero reason to use CUVID. It used to be a good solution, but copyback DXVA has improved so much that it's overall quite a bit better than CUVID now.

Native DXVA saves the copyback, so it lowers CPU usage. However, DXVA decodes to a format that it hard to work with for madVR. This results in a certain loss in chroma quality. In most situations you probably won't see the difference, but it's there. So unless you have to use native DXVA for some reason, using copyback DXVA is the better choice. Personally, I even use straight software decoding because for me it's the fastest and most reliable decoder.

[ashlar42]

Starting with v0.89.7 (up to v0.89.9) madVR tried to simulate what the MPC-HC ISR does when unchecking the mentioned option. However, this caused all sorts of trouble with SSA/ASS subtitles. Also it made the font size change, when users activated or deactivated the "move subtitles" option in madVR, which some users complained about. Some users also found the font sizes to simply be too large overall.

So in v0.89.10+ I went back to let XySubFilter render into the active video rect, and then afterwards I'm simply changing the positions of the subtitles to go into the black bars. The benefit of this solution is that when users activate and deactivate the "move subtitles" option in madVR, the font size does *not* change. It stays the same. However, the disadvantage is that now depending on the video aspect ratio, the font size might differ somewhat. That's really out of my control, though.
But what would be the reason for moving subs up and down? You either want them in the video frame or you don't, do you?

I'm asking because I don't know if something could be done for ASS/SSA subs but the "moving subs up and down depending on videos" seems like a less likely scenario than just wanting subs to be at the right size for reading them at any given distance... I don't think I'm that peculiar in my use case, am I?

[nevcairiel]

But what would be the reason for moving subs up and down? You either want them in the video frame or you don't, do you?

I'm asking because I don't know if something could be done for ASS/SSA subs but the "moving subs up and down depending on videos" seems like a less likely scenario than just wanting subs to be at the right size for reading them at any given distance... I don't think I'm that peculiar in my use case, am I?

But the point is, its not madVR controlling the size. It always asks for subs that match the video. You should ask the subtitle renderer developers about that instead.
Right now, madVR works like it has always worked (except for 3 recent versions where a new way was tested and deemed not ideal). It just lets the subtitle renderer control the font size. That seems like its the most logical solution. If more control about the size is needed, the subtitle renderer should control that.

[ashlar42]

I was asking because I don't fully understand what were the reasons that led to the previous 3 versions being deemed not ideal, in case those solved this problem.

If the problem was with people wanting to move subs up and down, I simply state that it seems less likely than people wanting to choose one subs size and forget about it.

The way it is now, they're either too small on 2.35 material or too large on 1.78 material (covering more picture than necessary, by the way, considering the length we go to get that same picture at its best possible quality...).

If it's not solvable... I'll go back hoping somebody will start to take more care of XySubsFilter in the future. I get it that madshi is already going above and beyond what one could reasonably expect.

Actually, thanks again madshi for trying. :)

[nijiko]

How about the mem leak? Was it pointed and fixed?

[seiyafan]

Does SystemCompute fairly accurately reflect MadVR's overall performance (ED, NNEDI3, etc.)?

[dansrfe]

If its not too time consuming, is it possible to implement nested if/else profile logic? It would make them a bit easier to manage and test.

[tahaa7]

Native DXVA saves the copyback, so it lowers CPU usage. However, DXVA decodes to a format that it hard to work with for madVR. This results in a certain loss in chroma quality. In most situations you probably won't see the difference, but it's there.

OK, but aren't decoded frames the same with both native and copyback? The only difference is where they are located after decoding (GPU memory vs main memory). So madvr receives the same decoded frame, whether from GPU memory or main memory, no?

So, when you say "DXVA decodes to a format that it hard to work with for madVR", that would mean that it's a general DXVA issue, not a native vs copyback issue.

[Knight77]

Image Enhancements will do the same thing as Upscaling Refinement when applied to an image already resized. It sharpens the luma to add detail to the image. Upscaling Refinement does the same but waits for resizing to take place. So, both could be considered post-resize sharpening.

I've seen from your posts and your (very good) guide that when there's not image upscaling (ex. 720p>1080p) you prefer to do not activate Superres in Chroma Upscaling but you prefer Finesharp in Image Enhancement, is because you do not think that SR in that case is visible/useful?

Another thing that really interest me is to understand the "real" difference between xbr-100 and 150, I could not find any comparison but just people preferring one or the other but without a real explanation of the reason.

[huhn]

OK, but aren't decoded frames the same with both native and copyback? The only difference is where they are located after decoding (GPU memory vs main memory). So madvr receives the same decoded frame, whether from GPU memory or main memory, no?

So, when you say "DXVA decodes to a format that it hard to work with for madVR", that would mean that it's a general DXVA issue, not a native vs copyback issue.

that's an issue with nvidia and madVR.

DXVA copy back is not effected and AMD/INTEL DXVA native is not known for this issue.

[nevcairiel]

OK, but aren't decoded frames the same with both native and copyback? The only difference is where they are located after decoding (GPU memory vs main memory). So madvr receives the same decoded frame, whether from GPU memory or main memory, no?


Its a D3D9 issue, it doesn't offer a way to do a 1:1 conversion from a DXVA video surface to a normal D3D9 Texture, which madVR would need for further processing.
Some more "tricky" ways to perform this conversion have different levels of success on different GPUs. It can result in a slightly blurred chroma channel.

Software decoding or DXVA-CopyBack don't have this issue, because madVR doesn't have to perform such a conversion then and can instead feed the texture from the memory buffer instead.
Trying to do the same for DXVA-Native would end up being practically the same as a CopyBack operation, so madshi decided to just let the user use LAV's copyback instead, since thats rather optimized.