Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Hardware & Software > Software players

Reply
 
Thread Tools Search this Thread Display Modes
Old 15th May 2015, 11:09   #30021  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by cyberbeing View Post
That was the problem. Is this something you can fix, considering 16 could be used with DX11 in previous versions, or will 15 now be the new limit going forward?
DX9 allows up to 32/31 frames. DX11 only 16/15. So for DX11 15 will be the upper limit.

Quote:
Originally Posted by nijiko View Post
I think you can make the strings output to a .ini file. Then people can modify it for himself/herself.
It's not a question of how to do it. It's a question of development priorities. Furthermore it doesn't make much sense to work on things like that if the settings dialog is still not in its final form. Lots of options will still come and go. It's better to do things like this once all features are implemented and finalized.
madshi is offline   Reply With Quote
Old 15th May 2015, 11:12   #30022  |  Link
andybkma
Registered User
 
Join Date: Sep 2006
Posts: 212
Quote:
Originally Posted by madshi View Post

There are 2 possible reasons for why the D3D11 path might not be activated:

1) Either you have desktop composition disabled (only possible on Windows 7).
2) Or you have the number of video frames which shall be presented in advance set to 16. I've just found out after releasing v0.88.7 that 15 is that max I can do. Using 16 means the D3D11 device creation fails. So lower this option to 14 (15 isn't currently supported), and D3D11 should start working again.

madshi, I have a problem getting your new D3D11 path to be activated on my Win7, mVR 88.7. Following your words above, I have D3D11 enabled, I do not have desktop composition disabled and I have the number of video frames presented in advance below 16 (I have it set to your defaults). Yet in window mode in the OSD it says [old path] and in FSE it says [new path].

Toggling the D3D11 path on/off/on didn't help, it is same OSD display whether it is checked or not.

Thanks
andybkma is offline   Reply With Quote
Old 15th May 2015, 11:22   #30023  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
You don't have desktop composition disabled in the madVR options? Or both in the madVR options *and* in the OS? Basically Aero/DWM must be turned on in the OS.

And you do have the Windows 7 Platform Update installed?
madshi is offline   Reply With Quote
Old 15th May 2015, 11:33   #30024  |  Link
Siso
Soul Seeker
 
Siso's Avatar
 
Join Date: Sep 2013
Posts: 711
I noticed that in D3D11 fullscreen windowed mode the average present stats are around 0.48ms, in D3D9 they are around 0.14ms. What is the difference actually, isn't D3D11 better?
Siso is offline   Reply With Quote
Old 15th May 2015, 12:26   #30025  |  Link
XRyche
Registered User
 
Join Date: May 2008
Posts: 211
Quote:
Originally Posted by James Freeman View Post
There is a "restore default settings.bat" in the madVR folder, run it and test again.
It fixed the problem for me.
I actually saw your comment and tried that before I posted last night. Thank you though.
__________________
Intel i5 3470, EVGA GTX 1050Ti SC ACX 2.0, Windows 10 Pro 64 bit, 16 GB 1600 mhz DDR3 RAM
XRyche is offline   Reply With Quote
Old 15th May 2015, 12:41   #30026  |  Link
ibius
Registered User
 
Join Date: Jan 2005
Location: Germany
Posts: 52
Quote:
Originally Posted by Siso View Post
I noticed that in D3D11 fullscreen windowed mode the average present stats are around 0.48ms, in D3D9 they are around 0.14ms. What is the difference actually, isn't D3D11 better?
You're a bit late to the party, it's a known issue.

Quote:
Originally Posted by madshi
madVR v0.88.7 released
Code:
* fixed: D3D11 render queue didn't fill in Windows 7
Thanks for that, it also fixed my render queue and unusually high CPU usage in FS, on Win8.1.

There's still strange behavior when flushing after copy to backbuffer - half-full render queue in FS/FSE.

With 'flush and wait (sleep)' enabled for 'after copy to backbuffer', I still get render queue 3-5/8, but at least present times go down to reasonable values, although not as low as D3D9's.

'Flush' and 'Flush and wait (loop)' result in additional high CPU usage.

Last edited by ibius; 15th May 2015 at 12:43.
ibius is offline   Reply With Quote
Old 15th May 2015, 13:08   #30027  |  Link
Dogway
Registered User
 
Join Date: Nov 2009
Posts: 2,352
Quote:
Originally Posted by nevcairiel View Post
Thats absolute nonsense. Maybe if you store the intermediates in 8-bit all the time (like your test script appears to do)
That tone... (urghh). Script's pipeline is 16-bit.

Quote:
Originally Posted by madshi View Post
Only if you configure madVR that way!! In the latest build you can use the same algorithm for both luma and chroma, if you want. So problem solved.

I'm not sure where you got your ideas from (lowpass filter and all). Those ideas are clearly technically incorrect.

Maybe there's degradation when using AviSynth, I don't know. Is that where you drew your conclusions from? AviSynth is limited to 8bit, IIRC? AviSynth tests don't tell you how madVR behaves. madVR has a dramatically higher calculation bitdepth than AviSynth.
I see, so that post of you for chroma doubling was in relation to a middle build which was working things out differently. No problem then if both use NNEDI.

In avisynth every color conversion is highly avoided due to quality loss, even in 32-bit precision on 16-bit pipelines and YV24 intermediary as in my example (yes, this is possible in avisynth, so unless I missed something -color spaces?- it's an apples to apples comparison).

In that regard, every *real world* conversion leads to quantization errors which translate to blurring. Just run a colored grain test and it will show all the shortcomings of your current process, as nevcairel pointed besides the limited 16-bit it's not even using YCgCo, you also need to use proper wide gamut color spaces to hold the float32 textures otherwise some colors are going to be clipped.

But again I ask, what steps in the process forces you to go to RGB that justifies these color conversions?

Last edited by Dogway; 15th May 2015 at 13:25.
Dogway is offline   Reply With Quote
Old 15th May 2015, 13:10   #30028  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,344
Quote:
Originally Posted by Dogway View Post
In avisynth every color conversion is highly avoided due to quality loss, even in 32-bit precision on 16-bit pipelines and YV24 intermediary as in my example (yes, this is possible in avisynth, so unless I missed something -color spaces?- it's an apple to apples comparison).
YV24 is a 8-bit format (8-bit 4:4:4, thats why its called 24, 24-bits per pixel).
__________________
LAV Filters - open source ffmpeg based media splitter and decoders

Last edited by nevcairiel; 15th May 2015 at 13:13.
nevcairiel is offline   Reply With Quote
Old 15th May 2015, 13:21   #30029  |  Link
baii
Registered User
 
Join Date: Dec 2011
Posts: 180
Old profiles is buggy in the new build, definitely try reset to default if can't get in to dx11.

Sent from my 306SH
baii is offline   Reply With Quote
Old 15th May 2015, 13:23   #30030  |  Link
clsid
*****
 
Join Date: Feb 2005
Posts: 5,643
Quote:
Originally Posted by madshi View Post
Maybe you need to reapply the fix suggested by cyberbeing, which IIRC was clearing the madVR OpenCL registry storage key and then recreating the kernel with the 64bit madVR build.
If there are possible incompatibilities, wouldn't it make sense to store the 64bit kernel separately? And maybe also recreate it whenever madVR version or GPU driver changes?
__________________
MPC-HC 2.1.7.2
clsid is offline   Reply With Quote
Old 15th May 2015, 13:27   #30031  |  Link
nijiko
Hi-Fi Fans
 
Join Date: Dec 2008
Posts: 222
Quote:
Originally Posted by madshi View Post
It's not a question of how to do it. It's a question of development priorities. Furthermore it doesn't make much sense to work on things like that if the settings dialog is still not in its final form. Lots of options will still come and go. It's better to do things like this once all features are implemented and finalized.
Well, I see. Though English is no problem, mother language is more friendly and kind. This thing you pointed is also a trouble now, so English is OK, thank you very much!

BTW, I bought a new large displayer, and madVR use 8bit output setting by default, how can I check whether my displayer support 8bit or 10bit?
nijiko is offline   Reply With Quote
Old 15th May 2015, 13:31   #30032  |  Link
Dogway
Registered User
 
Join Date: Nov 2009
Posts: 2,352
Quote:
Originally Posted by nevcairiel View Post
YV24 is a 8-bit format (8-bit 4:4:4, thats why its called 24, 24-bits per pixel).
I use a 16-bit YV24 format, if you re-analyze the script you will find "lsb=true" in the same line, it's a method to work with files in 16-bit (read here).
Dogway is offline   Reply With Quote
Old 15th May 2015, 13:33   #30033  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 7,903
Quote:
Originally Posted by nijiko View Post
Well, I see. Though English is no problem, mother language is more friendly and kind. This thing you pointed is also a trouble now, so English is OK, thank you very much!

BTW, I bought a new large displayer, and madVR use 8bit output setting by default, how can I check whether my displayer support 8bit or 10bit?
this should help a lot:
http://forum.doom9.org/showthread.php?t=172128

only the totally high end displays like samsung SUHD can have a true 10 bit panel.
huhn is offline   Reply With Quote
Old 15th May 2015, 14:02   #30034  |  Link
Razoola
Registered User
 
Join Date: May 2007
Posts: 454
Quote:
Originally Posted by James Freeman View Post
In FSE mode the OSD will display the following:

In D3D11;
fullscreen exclusive mode, 8 bit
fullscreen exclusive mode, 10 bit

In D3D9;
fullscreen exclusive mode (new path)
fullscreen exclusive mode (old path)


madshi,
In d3d9 mode when I switch "present several frames in advance" OFF in "exclusive mode settings" it also effects the windoed mode, meaning windowed or FSE it is always (old path).
Yes that is the behaviour I'm seeing here so I guess its ok. Maybe if DX11 and DX9 text is added to those messages it could save potential confusion going forward.
Razoola is offline   Reply With Quote
Old 15th May 2015, 14:08   #30035  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by Dogway View Post
I see, so that post of you for chroma doubling was in relation to a middle build which was working things out differently. No problem then if both use NNEDI.
Correct.

Quote:
Originally Posted by Dogway View Post
In avisynth every color conversion is highly avoided due to quality loss, even in 32-bit precision on 16-bit pipelines and YV24 intermediary as in my example (yes, this is possible in avisynth, so unless I missed something -color spaces?- it's an apples to apples comparison).

In that regard, every *real world* conversion leads to quantization errors which translate to blurring. Just run a colored grain test and it will show all the shortcomings of your current process
I'll say it again: You cannot use AviSynth as a proof for anything related to madVR. AviSynth has historically been limited to 8bit. I know there are some hacks you can use to force higher bitdepth with some filters, if those filters have special support for that. But I wouldn't bet on that every part of the processing pipeline from start to finish really makes full use of the highest bitdepth.

Look at the numbers/math from my previous reply and comment on that. That's a much better ground for discussion than running AviSynth tests with weird bitdepth hacks.

Quote:
Originally Posted by Dogway View Post
you also need to use proper wide gamut color spaces to hold the float32 textures otherwise some colors are going to be clipped.
Well, madVR's pipeline is running in video levels and not in PC levels, so there's sufficient foot and head room for all channels to not clip anything important.

Quote:
Originally Posted by Dogway View Post
But again I ask, what steps in the process forces you to go to RGB that justifies these color conversions?
There's RGB, YCbCr, R'G'B' and Y'CbCr. For best scientific scaling you'd need to scale in RGB or YCbCr. And that's what you can do with madVR by enabling the "scale in linear light" option. However, for upscaling this has proven to not work as well a expected. E.g. ringing artifacts get *much* stronger that way. So I'm using R'G'B' scaling instead. There are several reasons for that. One is that R'G'B' is probably a more perceptually uniform colorspace than Y'CbCr, which means that linear scaling algorithms might produce slightly superior results in R'G'B' compared to Y'CbCr. Another is that madVR supports all kinds of input formats. E.g. DCI sources are encoded in R'G'B'. Or PC game recordings, or other stuff. madVR has to handle both Y'CbCr and R'G'B' sources. And it's simply easier to convert them all to the same format, so that I don't have to implement multiple parallel, but totally different processing pipelines.

Anyway, as I said before, the R'G'B' <> Y'CbCr conversions are nearly lossless, due to the high bitdepth I'm using for processing and storage, and due to having enough head room and foot room for out-of-gamut colors. So there's no worry.

Anyway, if you need proof, the FineSharp HLSL shader package contains RGB <-> YCbCr conversion routines:

http://www.mediafire.com/download/yi...oYuv_ToRGB.zip

You can use them in MPC-HC to let madVR convert between R'G'B' and Y'CbCr, and you can repeat that process e.g. 10 times in a row. Do that with any test video you like, then compare the output with the custom shaders enabled/disabled. I believe you'll not be able to see any difference. Please uncheck all the madVR "trade quality for performance" options in madVR for this test, though.
madshi is offline   Reply With Quote
Old 15th May 2015, 14:08   #30036  |  Link
Razoola
Registered User
 
Join Date: May 2007
Posts: 454
@madshi, I see your point about the OSD getting wide in relation to adding DX11 or DX9 to the OSD's 'Fullscreen exclusive mode' line. Have you considered removing 'fullscreen' from that line given that is clearly visible from the screen size anyway. In effect replace 'fullscreen exclusive mode, 8 bit' with 'DX11 exclusive mode, 8 bit'. Then do the same with the DX9 modes also?
Razoola is offline   Reply With Quote
Old 15th May 2015, 14:15   #30037  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Ya, makes sense, I guess...
madshi is offline   Reply With Quote
Old 15th May 2015, 14:17   #30038  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 7,903
Quote:
Originally Posted by Razoola View Post
@madshi, I see your point about the OSD getting wide in relation to adding DX11 or DX9 to the OSD's 'Fullscreen exclusive mode' line. Have you considered removing 'fullscreen' from that line given that is clearly visible from the screen size anyway. In effect replace 'fullscreen exclusive mode, 8 bit' with 'DX11 exclusive mode, 8 bit'. Then do the same with the DX9 modes also?
i would prefer something like FSE D3D11 10 bit.
huhn is offline   Reply With Quote
Old 15th May 2015, 14:25   #30039  |  Link
Barnahadnagy
Registered User
 
Join Date: Apr 2014
Posts: 13
Quote:
Originally Posted by madshi View Post
Anyway, if you need proof, the FineSharp HLSL shader package contains RGB <-> YCbCr conversion routines
I wanted to write a little test application for this to prove this precision is more than enough, but with this I just tested it a bit. Surprisingly, if I zoom in 2500%, I can see very faint differences, I didnt expect to see anything really. Then again, I put in about 30 conversions... Anyways, if this doesnt prove that the conversions are high-enough precision, don't know what does.

Regarding OSD: I quite like "FSE D3D11 10 bit".
Barnahadnagy is offline   Reply With Quote
Old 15th May 2015, 14:51   #30040  |  Link
Anime Viewer
Troubleshooter
 
Anime Viewer's Avatar
 
Join Date: Feb 2014
Posts: 339
extra artifacts in madVR comparison?

Quote:
Originally Posted by madshi View Post
Thanks for the feedback! Seems there'll be another Shiandow deband iteration coming. <sigh> Of course it's all good, the algorithm getting better all the time. But I hope you users/testers won't be bored at some point, retesting revised algos all the time?
I think there is something strange at play in madVR resulting in artifacts. Starting by setting both programs to defaults, then configuring both for 10-bit, using the same upscalers, DX11, Shiandow's debanding (with identical settings), SuperChromaRes, and SuperRes (with identical NEDI settings in both), and ordered dithering in both I am seeing more artifacts in madVR than MPDN in the same video scenes. I've included a screen shot below.
Anyone have theories as to what may be causing the additional artifacts in madVR?

http://s17.postimg.org/lznm6e7j1/madvr_vs_mpdn.jpg
In particular I notice the additional artifacts around the Japanese characters/letters, edge and teeth of the creature, and floating green debris. While its not a huge overall difference it is noticeable to me.
__________________
System specs: Sager NP9150 SE with i7-3630QM 2.40GHz, 16 GB RAM, 64-bit Windows 10 Pro, NVidia GTX 680M/Intel 4000 HD optimus dual GPU system. Video viewed on LG notebook screen and LG 3D passive TV.
Anime Viewer is offline   Reply With Quote
Reply

Tags
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 19:51.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.