madVR - high quality video renderer (GPU assisted)

[Knight77]

Originally Posted by chros

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]

Originally Posted by madshi

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]

Originally Posted by Knight77

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]

Originally Posted by tahaa7

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]

Originally Posted by aufkrawall

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]

Originally Posted by madshi

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]

Originally Posted by 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).

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]

Originally Posted by ashlar42

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.

Originally Posted by tahaa7

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]

Originally Posted by madshi

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]

Originally Posted by ashlar42

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]

Originally Posted by madshi

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]

Originally Posted by Warner306

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]

Originally Posted by tahaa7

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]

Originally Posted by tahaa7

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.