madVR - high quality video renderer (GPU assisted) - Page 1427

tobindac · 30th March 2015, 15:05

Quote:

Originally Posted by kasper93

DXVA chroma upscaling use built-in scaling in your GPU. It is faster, but most likely offers lower quality than madVR's algorithms (at least some of them).

I suspected the new setting does something other than just changing the algorithm the way we change it manually in settings. It refers to "decoding". But decoding is now removed from madvr, and when I use native DXVA decoding in LAV, the new madvr OSD still reports the nnedi3 algorithm I had set.

kalston · 30th March 2015, 15:16

Nice update.

Anyone else ditched the fullscreen exclusive mode completely in favour of the windowed overlay mode btw? Performance for me is about the same (say 1-2ms increased rendering times at the most) but it has the advantage of not enabling g-sync* and having perfectly smooth transitions between windowed and fullscreen (not the slightest dropped or delayed frames or glitches). No tearing issues either despite running with Aero disabled (and thus v-sync along with it). Also, it only outputs 24fps instead of 144hz but I don't see that as being a problem, it's equally smooth. Oh and I can keep the JRiver overlay UI in fullscreen with the audio path info etc. being clearly visible. Really nice.

*disabling g-sync on a per-application basis doesn't work very well with current nvidia drivers, it works with MPC for example but not with JRiver MC20. Having to disable the global g-sync feature every time I want to watch a film is a hassle.

clsid · 30th March 2015, 15:35

madshi, can you give more details regarding the Optimus fix? That might help the MPC-HC devs to fix similar issues with EVR-CP.

Quote:

Isn't chroma upscaling on Intel done via Lanczos?

Someone said it is comparable in quality, so it probably uses an algorithm similar to Lanczos. The benefit of DXVA scaling is that it doesn't use Shaders, but fixed function stuff on the GPU.

Quote:

I suspected the new setting does something other than just changing the algorithm the way we change it manually in settings. It refers to "decoding". But decoding is now removed from madvr, and when I use native DXVA decoding in LAV, the new madvr OSD still reports the nnedi3 algorithm I had set.

No, it isn't directly related to decoding. It just means that if you are using DXVA decoding, you can use DXVA for other stuff as well without extra overhead. The new options apply to chroma scaling only, not luma scaling.

vivan · 30th March 2015, 15:38

I have a 6-bit IPS display with really terrible built-in dithering (even perfect gradients have very noticeable banding) and it confirms this

Quote:

Originally Posted by madshi

In theory setting your display to a lower bitdepth in the madVR "device" setup should result in stronger dithering, which should increase the noise floor slightly, but should decrease banding artifacts.

Dithering to 8 and even 7 bit depth is not enough, it looks good only at 6.

However there's no one oddity that I can't explain: when dithering to a lower bitdepth some parts of the image are shifted by ~1 pixel. For example bottom half of the image is moving here:
8 bit http://i.imgur.com/Rd3SIlm.png
6 bit http://i.imgur.com/4rHnHMe.png
At first I thought it's a madVR bug, but then I compared screenshoots on other displays and they don't show this difference. Same happens with my own dithering. I wonder what my display is even doing...

The main problem of DXVA-things is that they're limited to 8 bit precision. It leads to banding and extra noise (from dithering before it).
Lanc3+AR: http://firepic.org/images/2015-03/30/mhg6xqrhqr6f.png
DXVA: http://firepic.org/images/2015-03/30/kzuelukvcncj.png
(2x upscaling)

I wonder if it would be noticeable on chroma...

madshi · 30th March 2015, 16:09

Quote:

Originally Posted by tobindac

Can you explain this setting? I use the internal LAV on mpc-hc to do DXVA native decoding but the new OSD reports the nnedi3 setting I had for upscaling.

Are you using NNEDI3 for chroma or image/luma upscaling? And are you really doing native DXVA decoding or maybe copyback DXVA?

Quote:

Originally Posted by kasper93

I believe the reasoning behind this change is to give better performance for DXVA users out of the box. If they use DXVA it is most likely that they want performance.

Exactly.

Quote:

Originally Posted by clsid

madshi, can you give more details regarding the Optimus fix? That might help the MPC-HC devs to fix similar issues with EVR-CP.

I'm not fully sure the fix is working yet. I don't have an Optimus laptop to test this. I suspect that the VSync scanline APIs (GetRasterStatus etc) don't work properly on Optimus laptops. So the fix is make sure rendering still works (more or less) even those APIs don't work.

Quote:

Originally Posted by vivan

The main problem of DXVA-things is that they're limited to 8 bit precision. It leads to banding and extra noise (from dithering before it).
Lanc3+AR: http://firepic.org/images/2015-03/30/mhg6xqrhqr6f.png
DXVA: http://firepic.org/images/2015-03/30/kzuelukvcncj.png
(2x upscaling)

True. That shouldn't harm when using DXVA decoding/deinterlacing, though, because those are usually 8bit, anyway. So the new DXVA trade for quality options shouldn't suffer much from the 8bit limitation.

Vyral · 30th March 2015, 16:10

Thanks for the new version madshi !

Quote:

* added scaling algorithm information to OSD

Nice ! I don't need to open madVR settings to make sure the right scaling algorithms are used anymore.

Quote:

* removed option "use alternative interop hack (not recommended, AMD only)"

The original interop hack for AMD GPU is still here, right ?

vivan · 30th March 2015, 16:16

For some reason new version detects some 1080p videos (.m2ts from BD, .mts from camera) as BT.601.
http://i.imgur.com/8mL1KOe.png

0.87.14 detects them as BT.709.

madshi · 30th March 2015, 16:19

Quote:

Originally Posted by Vyral

The original interop hack for AMD GPU is still here, right ?

Not sure what you mean. The v0.87.15 OpenCL behaviour should be identical to the v0.87.14 default setup.

Quote:

Originally Posted by vivan

For some reason new version detects some 1080p videos (.m2ts from BD, .mts from camera) as BT.601.

0.87.14 detects them as BT.709.

Weird! Can you provide a small sample? Probably 10MB should do, just enough so that I can see the incorrect detection.

vivan · 30th March 2015, 16:20

Sample http://s000.tinyupload.com/index.php...92264598428867
10 MB sample http://s000.tinyupload.com/index.php...37763555941348

FireFreak111 · 30th March 2015, 16:29

Is there a reason I get 0.87.14 when I open the link on any browser? I have tried 11 times, keep getting 0.87.14. Is there anything I can do to not get the seemingly cached version?

kalston · 30th March 2015, 16:36

Tried simply ctrl + f5 to refresh the cache? Alternatively go here http://www.videohelp.com/software/ma...sions#download

Vyral · 30th March 2015, 16:37

Quote:

Originally Posted by FireFreak111

Is there a reason I get 0.87.14 when I open the link on any browser? I have tried 11 times, keep getting 0.87.14. Is there anything I can do to not get the seemingly cached version?

Try that link : http://www.videohelp.com/software/ma...sions#download

derpycat · 30th March 2015, 17:16

I've been using madvr for a couple of years, and in that time I've always had LAV Video filter set to DXVA2 copy-back on my AMD card, with the understanding that native doesn't support hardware acceleration, or something like that. I've just always read that AMD users should pick copy-back.

I'm now seeing some people recommend native over copy-back. I gave it a try and I see no difference in GPU load, though native seems to be using about 70mb more Vram on one video (not a big deal). Rendering stats seem almost identical as well. I'm making sure that the LAV Video filter is reporting the correct active decoder each time I change.

Can someone please tell me if native is now the preferred option, and also why I might not be seeing any difference in performance?

madshi · 30th March 2015, 17:20

Quote:

Originally Posted by vivan

Sample

Thanks, will be fixed in the next build.

Quote:

Originally Posted by derpycat

Can someone please tell me if native is now the preferred option

No, it's not. All the options have their advantages and disadvantages. If one option was clearly preferred, there would be no need to offer an option at all.

derpycat · 30th March 2015, 17:28

Quote:

Originally Posted by madshi

Thanks, will be fixed in the next build.

No, it's not. All the options have their advantages and disadvantages. If one option was clearly preferred, there would be no need to offer an option at all.

Ok. I assumed some of the options were there for compatibility, as is often the case with these things. I was also asking because I couldn't find what those advantages and disadvantages might be. All I found were technical definitions of the two. Could you give me an example of a practical difference?

madshi · 30th March 2015, 17:38

Simply try them and use what works best for you. I would recommend to use either DXVA copyback, or software decoding, but that's just my personal opinion. Some madVR features don't work with native DXVA, mainly forced film mode.

huhn · 30th March 2015, 17:39

Quote:

Originally Posted by derpycat

Ok. I assumed some of the options were there for compatibility, as is often the case with these things. I was also asking because I couldn't find what those advantages and disadvantages might be. All I found were technical definitions of the two. Could you give me an example of a practical difference?

DXVA native doesn't work with other filter like vsfilter. you can't use force film mode or the decimation feature of madVR.

derpycat · 30th March 2015, 17:54

Alright, thanks. I'll go back to copy-back.

Edit: Turns out I have a file (the only one) that shows a difference between copy-back and software decoding. It's a 120fps clip, and apparently AMD's cards, or at least the drivers, aren't capable of playing back 120fps. I guess I'll stick with software decoding then.

FireFreak111 · 30th March 2015, 18:04

Last thing, assuming the 'Use separate device' options are DXGI options (I'm likely wrong), is there any chance of using the new DXGI flip model on Windows 8+ (only the OS needed, no new hardware) for performance, or is that at the player level (MPC-HC)?

Quote from page:
'Performance improvements of DXGI flip model are significant when the app is in windowed mode.'

It would be awesome to see even less CPU copying

.

Also thanks for that link, got a new madVR version before my internet goes for a month.

mark0077 · 30th March 2015, 20:00

Thanks madshi, new version works great. Quick question for anyone. If it has been already answered please delete this, I couldn't find the answer in the guide or from searching.

Does madVR still use the logic that if height > 1024, to use 709 matrix, or should I be using profiles to achieve this? Currently watching blu-rays like Avatar, the matrix is seen to be set to "BT.601 [best guess]" and primaries "SMPTE C [best guess]". I can only assume it should be BT.709 but I'm not sure whether I need to add this to a profile myself?

30th March 2015, 16:20	#28529 \| Link
vivan /人 ◕ ‿‿ ◕ 人\ Join Date: May 2011 Location: Russia Posts: 643	Sample http://s000.tinyupload.com/index.php...92264598428867 10 MB sample http://s000.tinyupload.com/index.php...37763555941348 Last edited by vivan; 30th March 2015 at 16:40.

30th March 2015, 17:54	#28538 \| Link
derpycat Registered User Join Date: Apr 2013 Posts: 31	Alright, thanks. I'll go back to copy-back. Edit: Turns out I have a file (the only one) that shows a difference between copy-back and software decoding. It's a 120fps clip, and apparently AMD's cards, or at least the drivers, aren't capable of playing back 120fps. I guess I'll stick with software decoding then. Last edited by derpycat; 31st March 2015 at 03:59.

30th March 2015, 18:04	#28539 \| Link
FireFreak111 Registered User Join Date: Apr 2014 Posts: 48	Last thing, assuming the 'Use separate device' options are DXGI options (I'm likely wrong), is there any chance of using the new DXGI flip model on Windows 8+ (only the OS needed, no new hardware) for performance, or is that at the player level (MPC-HC)? Quote from page: 'Performance improvements of DXGI flip model are significant when the app is in windowed mode.' It would be awesome to see even less CPU copying . Also thanks for that link, got a new madVR version before my internet goes for a month. Last edited by FireFreak111; 30th March 2015 at 18:08.

30th March 2015, 15:16	#28522 \| Link
kalston Registered User Join Date: May 2011 Posts: 164	Nice update. Anyone else ditched the fullscreen exclusive mode completely in favour of the windowed overlay mode btw? Performance for me is about the same (say 1-2ms increased rendering times at the most) but it has the advantage of not enabling g-sync* and having perfectly smooth transitions between windowed and fullscreen (not the slightest dropped or delayed frames or glitches). No tearing issues either despite running with Aero disabled (and thus v-sync along with it). Also, it only outputs 24fps instead of 144hz but I don't see that as being a problem, it's equally smooth. Oh and I can keep the JRiver overlay UI in fullscreen with the audio path info etc. being clearly visible. Really nice. *disabling g-sync on a per-application basis doesn't work very well with current nvidia drivers, it works with MPC for example but not with JRiver MC20. Having to disable the global g-sync feature every time I want to watch a film is a hassle.

30th March 2015, 16:16	#28527 \| Link
vivan /人 ◕ ‿‿ ◕ 人\ Join Date: May 2011 Location: Russia Posts: 643	For some reason new version detects some 1080p videos (.m2ts from BD, .mts from camera) as BT.601. http://i.imgur.com/8mL1KOe.png 0.87.14 detects them as BT.709.

30th March 2015, 16:29	#28530 \| Link
FireFreak111 Registered User Join Date: Apr 2014 Posts: 48	Is there a reason I get 0.87.14 when I open the link on any browser? I have tried 11 times, keep getting 0.87.14. Is there anything I can do to not get the seemingly cached version?

30th March 2015, 16:36	#28531 \| Link
kalston Registered User Join Date: May 2011 Posts: 164	Tried simply ctrl + f5 to refresh the cache? Alternatively go here http://www.videohelp.com/software/ma...sions#download

30th March 2015, 17:16	#28533 \| Link
derpycat Registered User Join Date: Apr 2013 Posts: 31	I've been using madvr for a couple of years, and in that time I've always had LAV Video filter set to DXVA2 copy-back on my AMD card, with the understanding that native doesn't support hardware acceleration, or something like that. I've just always read that AMD users should pick copy-back. I'm now seeing some people recommend native over copy-back. I gave it a try and I see no difference in GPU load, though native seems to be using about 70mb more Vram on one video (not a big deal). Rendering stats seem almost identical as well. I'm making sure that the LAV Video filter is reporting the correct active decoder each time I change. Can someone please tell me if native is now the preferred option, and also why I might not be seeing any difference in performance?

30th March 2015, 17:38	#28536 \| Link
madshi Registered Developer Join Date: Sep 2006 Posts: 9,140	Simply try them and use what works best for you. I would recommend to use either DXVA copyback, or software decoding, but that's just my personal opinion. Some madVR features don't work with native DXVA, mainly forced film mode.

30th March 2015, 20:00	#28540 \| Link
mark0077 Registered User Join Date: Apr 2008 Posts: 1,106	Thanks madshi, new version works great. Quick question for anyone. If it has been already answered please delete this, I couldn't find the answer in the guide or from searching. Does madVR still use the logic that if height > 1024, to use 709 matrix, or should I be using profiles to achieve this? Currently watching blu-rays like Avatar, the matrix is seen to be set to "BT.601 [best guess]" and primaries "SMPTE C [best guess]". I can only assume it should be BT.709 but I'm not sure whether I need to add this to a profile myself?