View Full Version : madVR - high quality video renderer (GPU assisted)
chros
17th April 2016, 11:43
When I watch a 24.000 fps movie with "use Direct3D 11 for presentation" enabled render queue and present queue are not full. Present time is unusually high too
With "use Direct3D 11 for presentation" disabled stats is ok.
Does it only happen to 24fps? Have you tried e.g. 23.976 and 25fps as well?
If 23.976 works fine but not 25 that probably means that your system isn't fast enough for those bigger fps and 10bit.
Can I set a profile auto select rules for 24 fps movies?
Yes, you can create a profile group with the "rendering" group entry and set something similar for rules:
if (srcFps < 24) "23fps"
else "Default"
huhn
17th April 2016, 11:48
I have a question regarding the SMPTE 170M primaries management in Madvr.
I have many japanese DVD and from my understanding, japan video industry still used SMPTE 170M primaries for DVD authoring instead of the more recent SMPTE C. If I'm not wrong, Madvr is able to manage SMPTE 170M Primaries if the filename is flagged so.
My issue is that, as I used my DVD and not rip (I have too many), I can't used the flag and so Madvr used SMPTE C primaries automatically. And using the primaries toggle option, SMPTE 170M is not listed as it should be very rare. Is a way to use SMPTE 170M primaries with my dvd without to rip them all (yes, I'm a very old fashioned man, I don't even rip my blu-ray)?
Thank in advance for your help!
when i open a DVD using "open disc" in mpc-hc madVR get's the primaries from the stream.
Matching_Mole
17th April 2016, 12:48
when i open a DVD using "open disc" in mpc-hc madVR get's the primaries from the stream.
Madvr don't get all the time this information from the stream, this is why you have "(best guess)" indicated in the statistic screen. Otherwise this is "(says upstream)" that is indicated. Each time I watch my DVD, I look the statistic screen to monitor the parameters used by Madvr.
Madvr guesses based on the resolution of the video and the framerate. In this case, this is NTSC video so it uses the best primaries for it so SMPTE C. But, in this specific cases, it seems to be wrong. This is why I want to change the primaries.
cvrkuth
17th April 2016, 13:07
Does it only happen to 24fps? Have you tried e.g. 23.976 and 25fps as well?
23.976 (and all others fps) works fine. Only 24fps is a problem with 10bit display bitdepth
Thanks for your help!
Clammerz
17th April 2016, 16:05
Is a way to use SMPTE 170M primaries with my dvd without to rip them all?
If you want to get turbo ghetto, you could mount your optical drive to a folder that has "primaries=XXXYYY" tag in it.
See here for more information about mount points:
https://technet.microsoft.com/en-us/library/cc753321.aspx
For some info about filename tags see here:
http://forum.doom9.org/showthread.php?p=1709584
(Search [CTRL+F] for "File name tags")
Create an empty folder path like:
S:\Movies\DVDDrive\Japan[primaries=170M]\
Then create the mount point as in the above microsoft article.
You could create multiple folders with different "dvd drive tags" I imagine.
Note: haven't tested any of this, so good luck.
chros
17th April 2016, 18:09
23.976 (and all others fps) works fine. Only 24fps is a problem with 10bit display bitdepth
That's pretty interesting! I don't have problem with 23/24/25fps but all the others! I thought it's because of increased bandwidth. I'll try to make some more tests with different materials.
(I have to mention that the GT650m is underclocked :) )
Matching_Mole
17th April 2016, 19:09
If you want to get turbo ghetto, you could mount your optical drive to a folder that has "primaries=XXXYYY" tag in it.
Thanks for the tips but unfortunately it doesn't work for DVD (and I think Blu-ray too), I just tried. I mean, it works if I choose the VOB files directly. But if I used the open DVD feature of MPC, this is the IFO that is selected and, due to the DVD navigator filter I assume, the solution failed.
wolfman2791
17th April 2016, 23:07
reproduced.
lanczos is used or at least shown in the OSD when the image is only scaled in X or Y direction.
jinc is correctly used with a 1440x1080p 16/9 AR source displayed at 1920x1080p.
there is an additional "image y = jinc" line.
you have set your player to stretch. set it to "touch window from the inside" (name can depend on the player) if you don't want that.
Thanks my man.
huhn
17th April 2016, 23:38
Thanks for the tips but unfortunately it doesn't work for DVD (and I think Blu-ray too), I just tried. I mean, it works if I choose the VOB files directly. But if I used the open DVD feature of MPC, this is the IFO that is selected and, due to the DVD navigator filter I assume, the solution failed.
which windows version are you using?
if you are not using windows 10 i could try a sample that doesn't work for you to see if it could at least work with a newer version of DVD navigator.
baii
18th April 2016, 13:18
Madvr don't get all the time this information from the stream, this is why you have "(best guess)" indicated in the statistic screen. Otherwise this is "(says upstream)" that is indicated. Each time I watch my DVD, I look the statistic screen to monitor the parameters used by Madvr.
Madvr guesses based on the resolution of the video and the framerate. In this case, this is NTSC video so it uses the best primaries for it so SMPTE C. But, in this specific cases, it seems to be wrong. This is why I want to change the primaries.
Google seems to say smpte c and smpte 170m have the same color space, what exactly is the difference?
OK, Google actually able to pull up madshi response on this
http://forum.doom9.org/showthread.php?p=1722345#post1722345
They are the "same".
Sent from my 306SH using Tapatalk
James Freeman
18th April 2016, 17:29
@madshi about HDR to SDR algorithm.
I noticed that the HDR to SDR algorithm in madVR saturates the color way beyond normal, I'll explain.
A standard 709 image converted to BT.2020 ST.2084 (ICC profile made by ArgyllCMS) exported as AVI and encoded with HEVC (primaries and matrix 2020, ST.2084 EOTF, P3 master display, 10,000 peak).
When playing back this video in madVR the image should look identical to the original 709 image right?
The resulting image in madVR is dark and more saturated compared to simply reversing the 2020 st.2084 icc profile (back to linear).
That lets me believe that something is wrong.
In this ZIP file you'll find all the steps from the 709 image to the HEVC HDR video file and explanation in Read.txt file.
http://www.mediafire.com/download/jpkvqnbqcj1682z/HEVC_HDR_test_to_madshi.7z
Martian SDR.jpg
Martian 2020 2084 (converted and profiled).jpg
Before HEVC.avi
HEVC 10,000.mp4
Rec2020 ST.2084.icc
Read.txt
Please have a look at this because no matter what I can't make the image look like the original after madVR HDR to SDR algorithm.
By the look of it there is another not needed gamma curve after the video is converted back to linear.
Madshi if you will please include a 2084 curve in the "this display is calibrated to the following EOTF" dropdown box for easy testing.
nevcairiel
18th April 2016, 17:47
When playing back this video in madVR the image should look identical to the original 709 image right?
The resulting image in madVR is dark and more saturated compared to simply reversing the 2020 st.2084 icc profile.
I think you are greatly oversimplifying this process.
Compressing HDR to SDR is not a lossless process, since the gamut and brightness range needs to be greatly compressed. The only problem here is that you can't just compress the range linear since that would make everything extremely dark. HDR doesn't use the full range for the full image, the majority of the image is still in "normal" brightness areas, only using the higher brightness for highlights etc.
So depending on which display nits you selected, you get a different image. Try adjusting the nits setting in madVR, and you should probably manage to get closer to the "original".
My guess is that your conversion over-satured the colors. It may not be this obvious on a HDR screen though, but its not how any real HDR footage would look.
Anyway, I still maintain that such a test is flawed. Your original images are not HDR, so using them for any kind of HDR tests seems not very productive.
Edit:
On a second look, it seems like your files are not actually BT.2020, but just normal BT.709 flagged as BT.2020. Disable primaries/gamut conversion in madVR by setting it to "disaplay is calibrated to BT.2020", and it suddenly looks perfect on a BT.709 screen.
Did you just convert the gamma curve before encoding, but not the gamut?
James Freeman
18th April 2016, 17:58
I well aware of the process by now and would not bother madshi in vain.
The HEVC video is encoded with 10,000nit (peak white 1024 10bit) so madVR I assume should not do any range conversion when 10,000 is selected, just reverse the ST.2084 EOTF back to linear.
Actually after a simple photoshop check, madVR runs another un-needed Gamma curve after linearization from 2084 to linear.
EDIT answer your edit:
The SDR image file is converted to 2020 ST.2084, so it IS in rec.2020 and ST.2084 eotf, so Gamma and Gamut.
No, the "disaplay is calibrated to BT.2020" does not correct the colors, it's the (un-needed IMO) gamma curve that makes the image more saturated and dark.
You have all the files to play with and compare.
Maybe that is part of madshi's algorithm, it applies a slight gamma curve and saturates the colors slightly more.
That is why I request (yes I know) for an ST.2084 EOTF curve for the display so that madVR does not do another process besides the linearization with st,2084 videos.
When vieweing the 2020 st.2084 profiled image in MPC-HC+madVR it uses the embedded profile and it looks just like the unprocessed image as it should.
Madhsi, what is going on in there with you HDR to SDR algorithm, can you enlighten us please?
Anyway, I still maintain that such a test is flawed. Your original images are not HDR, so using them for any kind of HDR tests seems not very productive.
Even when I use a real HDR screenshot (HERE) (http://www.blu-ray.com/movies/screenshot.php?movieid=147430&position=6) from blu-ray.com where I don't need to convert to 2020 st.2084 with an ICC because it is already in 2020 st2084, madVR makes it look more saturated with a slight power curve applied to it.
Maybe madshi tried to emulate the HDR look on SDR screen by raising the gamma slightly that I understand, but why the more saturated colors?
709 colors should look like 709 if they are in P3 or 2020 container.
XMonarchY
18th April 2016, 18:20
Are saying that Plasma TV's can produce HDR effect fully???
Bump!
Patrik G
18th April 2016, 18:47
Bump!
only the Pioneer 9G Kuros have a wider gamut that covers 89% of DCI P3 (calculated with dispcal 3d lut program after profiling)
the Panasonics are just slight over srgb gamut.
HDR is not all about brightness
it also needs those extra colors to get the image right.
This 500M has also less agressive ABL dimming than the rest of the plasmas.
it can maintain a higher brightness level even on high apl scenes.
thats also a key point to get the image and gamma right.
HDR Photo with 22 stops of dynamic range from the Exodus HDR clip with madvr on my 500M
i have compared it to the regular blu ray verison and the HDR version has higher depth and greater colors.
you can see more details near black and near white.
lets hope there will be more HDR material because this tv/monitor is made for it.
its hard to believe that an 8 year old monitor can handle todays standards i know lol
thanks to madvrs HDR support that made it possible to squeeze out the last % of picture quality on this haunted tv ;)
http://privat.bahnhof.se/wb192876/KRP%20500M%20Exodus%20HDR_lowres.jpg
Full size
http://privat.bahnhof.se/wb192876/KRP%20500M%20Exodus%20HDR.jpg
nevcairiel
18th April 2016, 19:06
The SDR image file is converted to 2020 ST.2084, so it IS in rec.2020 and ST.2084 eotf, so Gamma and Gamut.
No, the "disaplay is calibrated to BT.2020" does not correct the colors, it's the (un-needed IMO) gamma curve that makes the image more saturated and dark.
Then why does it look fine when I force madVR to assume the file is BT.709 input (via shortcuts, ctrl-alt-shift-P i believe), and set HDR nits to ~3000 or so (to get the brightness down)?
Neither one of those settings individually fixes it, but only the combination. Which makes me strongly believe that at least one of those aspects is not correct in your file.
Looks to me like something is fishy with your conversion. Your conversion has way too many manual steps to really trust it. How did you export it to AVI? Maybe your export converted it again.
James Freeman
18th April 2016, 19:14
Then why does it look fine when I force madVR to assume the file is BT.709 input (via shortcuts, ctrl-alt-shift-P i believe), and set HDR nits to ~3000 or so (to get the brightness down)?
Neither one of those settings individually fixes it, but only the combination. Which makes me strongly believe that at least one of those aspects is not correct in your file.
Looks to me like something is fishy with your conversion. Your conversion has way too many manual steps to really trust it. How did you export it to AVI? Maybe your export converted it again.
VirtualDub exports a set of images to lossless avi in 4:2:0, it looks absolutely identical to the 2020 st.2084 image.
I assure you it is not in the 2020 conversion or the avi.
It may be the HEVC encoding, here are the lines:
avs4x26x.exe -L "x265.exe" --seek-mode safe --input-depth 8 --preset slow --subme 7 --crf 0 --profile main10 --level-idc 5.1 --no-high-tier --b-adapt 0 --bframes 0 --keyint 1 --min-keyint 1 --no-open-gop --colorprim bt2020 --transfer smpte-st-2084 --colormatrix bt2020nc --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)" --max-cll "0,0" --output "E:\x265\output.hevc" "E:\x265\Script.avs"
muxer -i output.hevc?[fps=1/4] -o output.mp4
del output.hevc
It's not the HEVC encoding, look EDIT.
It's the HDR to SDR algorithm in madVR that raises the gamma, and saturation ever so slightly.
It is not equal to just looking at the 2020 st.2084 image in mpc-HC+madVR, which just applies the profile inside the image.
I can understand the raised gamma to recreate an HDR look on SDR screen, but why more saturated? 709 should look like 709.
EDIT:
You can see that applying a gamma curve to the SDR image is look like the HEVC 10,000 video.
So it's a simple RGB curves manipulation to simulate HDR on SDR after linearization, which obviously affect saturation.
Yet the right image is ever so slightly more saturated.
http://www.mediafire.com/convkey/981a/2l023nzubbtlksqzg.jpg
chros
18th April 2016, 20:17
23.976 (and all others fps) works fine. Only 24fps is a problem with 10bit display bitdepth
That's pretty interesting! I don't have problem with 23/24/25fps but all the others! I thought it's because of increased bandwidth. I'll try to make some more tests with different materials.
(I have to mention that the GT650m is underclocked :) )
It's definitely a performance problem in my case (no wonder why :)). Can it be that the refresh rate of your display is under 24fps? Is this true for the other modes as well?
James Freeman
18th April 2016, 21:50
I have run several tests with a simple color steps pattern converted to HDR 1000 and 10,000 in full 2020 gamut, and 709 inside 2020.
Apparently madVR algorithm is much more complex with range conversions much smarter than I am.
It looks like it is not a simple curve as I assumed, it is dynamic gamut and average picture level dependent.
Madshi, can you just explain how it works, I will be grateful.
I think you are greatly oversimplifying this process.
You were right from the start, shame on me. :o
Sp00kyFox
19th April 2016, 01:33
I was wondering, is the ssim downscaling algorithm also available as an avisynth filter? madVR is the only place I came across it.
cvrkuth
19th April 2016, 11:40
It's definitely a performance problem in my case (no wonder why :)). Can it be that the refresh rate of your display is under 24fps? Is this true for the other modes as well?
Refresh rate is ok, probably a performance problem. I have AMD 5670 (passive cooled).
Thanks for your help with profiles, that was solve my problem with 24fps
Regards
Ver Greeneyes
19th April 2016, 12:13
I was wondering, is the ssim downscaling algorithm also available as an avisynth filter? madVR is the only place I came across it.I don't think so, though it might be possible using AviSynthShader (http://forum.doom9.org/showthread.php?t=172698) and the SSIM downscaler (https://github.com/zachsaw/MPDN_Extensions/tree/master/Extensions/RenderScripts/SSimDownscaler) code for Media Player .NET (though the code madVR uses might be slightly different, and it won't contain the anti-ringing filter).
As a personal note, I'd love to just be able to insert madVR into an Avisynth script :P madVR's DLL interface is too limited for that though, as far as I can tell.
DragonQ
19th April 2016, 19:26
Anyone know if AMD's Crimson 16.15 drivers fix deinterlacing? Still on Catalyst 15.30 since they broke it.
BluesFanUK
19th April 2016, 20:31
Is it essential to have LAV filters when installing MadVR?
sneaker_ger
19th April 2016, 20:33
Not in general but madVR's 3D mode with MVC decoding only works with LAV Video, I think.
RenderGuy2
19th April 2016, 20:58
Would it be possible for MadVR to support:
MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
MEDIASUBTYPE_XYZC {435A5958-0000-0010-8000-00AA00389B71}
FORMAT_VIDEOINFO2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
This is a 12-bit XYZ format. There are a couple of relatively inexpensive DirectShow filters that can decode jpeg2000 pretty quickly and can output 12bit xyz (without forcing a conversion to rec709). The conversion to display color can easily be done by the user with either a 3DLUT or pixel shaders (linearize, 3x3 matrix, gamma), or a combination of both.
I have no idea if it is simple or difficult to add support for another pixel type. Thank you.
huhn
20th April 2016, 05:00
Anyone know if AMD's Crimson 16.15 drivers fix deinterlacing? Still on Catalyst 15.30 since they broke it.
i will test this later.
in one of the driver was a line like " fixed deinterlacing" or something like this.
RenderGuy2
20th April 2016, 17:23
Would it be possible for MadVR to support:
MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
MEDIASUBTYPE_XYZC {435A5958-0000-0010-8000-00AA00389B71}
FORMAT_VIDEOINFO2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
Regarding this format, the filter outputs 48 bits which are assigned as:
Bits 0-7 = "Red" LSB's
Bits 8-11 = Nothing
Bits 12-15= "Red" MSB's
Bits 16-23= "Green" LSB's
Bits 24-27= Nothing
Bits 28-31= "Green" MSB's
Bits 32-39= "Blue" LSB's
Bits 40-43= Nothing
Bits 44-47= "Blue" MSB's
Hopefully this is useful.
Thanks!
huhn
20th April 2016, 17:23
i don't saw an issue on an short test.
nevcairiel
20th April 2016, 17:39
Regarding this format, the filter outputs 48 bits which are assigned as:
Bits 0-7 = "Red" LSB's
Bits 8-11 = Nothing
Bits 12-15= "Red" MSB's
Bits 16-23= "Green" LSB's
Bits 24-27= Nothing
Bits 28-31= "Green" MSB's
Bits 32-39= "Blue" LSB's
Bits 40-43= Nothing
Bits 44-47= "Blue" MSB's
So, ordinary Little-Endian format? =p
RenderGuy2
20th April 2016, 18:56
So, ordinary Little-Endian format? =p
Yeah, the only thing that confuses me is that I sometimes see Little-Endian as (first 16 of 48 bits):
Bits 0-3 = "Red" LSB's
Bits 4-7 = Nothing
Bits 8-15 = "Red" MSB's
So the empty bits are in a different location, though this might not matter as the least significant bits/most significant bits are still in the same bytes overall?
nevcairiel
20th April 2016, 19:39
So the empty bits are in a different location, though this might not matter as the least significant bits/most significant bits are still in the same bytes overall?
Some formats have the zero bits in the MSBs, some in the LSBs, its always just a matter of how the format is defined.
RyuzakiL
21st April 2016, 01:33
So the latest AMD Crimson (April 2016) still runs like crap on MadVR? I'm still using the last AMD Catalyst, is there an improvement 4 months after or I better wait again, or switch to NVIDIA now since it seems MadVR runs properly with NVIDIA cards.
Warlock
21st April 2016, 02:17
Guys, I'm having problems with excessive presentation glitches and dropped frames. In Windows 8.1 and Windows 10 does not appear this problem of presentation glitches or dropped frames, but in windows 7 ultimate x64 sp1 is happening. A picture of the problem:
http://i.imgur.com/Bcsuj8Y.png
My pc configuration is this:
4770k
Z87-GD65 gaming
8gb 1600
hd 1tb SATA3
I am using the onboard video 4770k, the Intel HD 4600.
What changes should I do to stop this problem of excessive presentation glitches and dropped frames? In Windows 8.1 works perfectly, but in Windows 7 is taking place this problem. I appreciate if you guys can help me guys.
huhn
21st April 2016, 07:41
the screen is most likely taken while playback is paused.
and i don't see any issue on the screen there are 12 dropped frames and 8 glitches and that's totally ok after going into fullscreen.
do these numbers change?
how many displays are connected to the PC?
SweetLow
21st April 2016, 09:14
What changes should I do to stop this problem of excessive presentation glitches and dropped frames? In Windows 8.1 works perfectly, but in Windows 7 is taking place this problem. I appreciate if you guys can help me guys.
As you use Intel and DX9 render - try using overlay.
Warlock
21st April 2016, 12:44
the screen is most likely taken while playback is paused.
and i don't see any issue on the screen there are 12 dropped frames and 8 glitches and that's totally ok after going into fullscreen.
do these numbers change?
how many displays are connected to the PC?
Actually, this image was when the video is paused, but even running, the flow of presentation glitches increases considerably. Increased presentation glitches, dropped frames, delayed frames rely heavily on the video type that I am running. Some have far fewer glitches than others, as well as delayed and dropped frames. It no has a specific time limit to happen, sometimes happens 5 for 5sec, 15 for 15sec, 30 for 30sec, and so on. These numbers change much, the glitches come easy 60 ~ 70 and droped frames increase much more, coming to pass 90 in most cases. I have only one display connected to my computer.
As you use Intel and DX9 render - try using overlay.
I did what you recommended, information on the presentation glitches disappeared, in contrast, the number of delayed frames greatly increased, it increases every second continuously.
I do not know why this is happening. In Windows 8.1 worked perfect, had no problems with presentation glitches, much less dropped frames and problems with delayed frames was very rare. The settings that use the madVR are those that come standard, only changed the trade of quality for performance, where deselect all selected options. In the devices, I selected my monitor, in case a benq XL2420T. In properties, let the default options, with the exception of bitdepth display option, where selected 7 bit. How do you think I set the madVR? It has some special sets for those using Intel video card?
huhn
21st April 2016, 12:56
your settings are default so you are using full screen exclusive mode?
Warlock
21st April 2016, 13:13
your settings are default so you are using full screen exclusive mode?
No, I use the windowed mode. I forgot to warn that deactivated the full screen exclusive mode option.
huhn
21st April 2016, 13:17
can you give FSE mode a try?
what type of decoding is used?
how do the queues look like are some acting "strange"?
Warlock
21st April 2016, 13:45
can you give FSE mode a try?
what type of decoding is used?
how do the queues look like are some acting "strange"?
Open Video in fullscreen exclusive mode, still having presentation glitches and dropped frames, but are much less than in windowed mode. In fact, it seems to be much more stable in exclusive mode in full screen. The decoding you refer to are the options lav filters? If so, use the dxva-cb mode. The queues are normal. They are functioning normally. I'll add an image running in fullscreen exclusive mode.
http://i.imgur.com/jdUiQYd.jpg
http://i.imgur.com/VPP4nDW.jpg
SweetLow
21st April 2016, 15:03
Try lower GPU queue to 6 and present frame in advance to 4
James Freeman
21st April 2016, 15:21
Fellows would you care to test these, both are video this time: :)
Both peak at 1000nit with the average picture levels like all current HDR 4K blu-ray releases.
Martian SDR to HDR Trailer.mp4 (http://www.mediafire.com/download/oeawrppgi3hzfv3/Martian+SDR+to+HDR+Trailer.mp4) (35MB)
4K Sun HDR Test.mp4 (http://www.mediafire.com/download/qp12w5fm5ng3tcm/4K+sun+HDR+test.mp4) (130 MB)
The second one is an actual 12bit HDR RAW footage before encoding, from a digital camera with all the F-Stops HDR needs.
surami shared this footage so I can experiment on it, on this thread: http://forum.doom9.org/showthread.php?t=172724&page=4
EDIT:
Martian trailer updated from 40s to full 2m:40s time.
QBhd
21st April 2016, 17:09
No, I use the windowed mode. I forgot to warn that deactivated the full screen exclusive mode option.
As you are using Windows 7... Have you tried disabling desktop composition. It never worked properly for me on Windows 7. FYI... Windows 8.1 and Windows 10 have no such issues
QB
Warner306
21st April 2016, 18:24
Open Video in fullscreen exclusive mode, still having presentation glitches and dropped frames, but are much less than in windowed mode. In fact, it seems to be much more stable in exclusive mode in full screen. The decoding you refer to are the options lav filters? If so, use the dxva-cb mode. The queues are normal. They are functioning normally. I'll add an image running in fullscreen exclusive mode.
http://i.imgur.com/jdUiQYd.jpg
http://i.imgur.com/VPP4nDW.jpg
Have you tried the D3D11 presentation path? Also, it might we wise to reset everything to its default from the madVR installation folder and start from scratch.
omarank
21st April 2016, 20:07
I was doing some testing on GPU LUTs and found that the “disable GPU gamma ramps” setting in madVR doesn’t perfectly make the ramps linear. I used this (https://www.xrite.com/i1display-2/support/d546) tester from X-Rite website and tested on three different systems with AMD, Nvidia and Intel GPUs respectively. All three systems didn’t have any ICC profile loaded or any other application loading the GPU LUTs. So they already had linear ramps. The tester software correctly reported that the LUTs were unmodified. When madVR was used with “disable GPU gamma ramps’ selected, it reported that the LUTs were modified. The tester software also shows some RGB values to describe the modification done to the LUTs. The RGB values shown in case of madVR were just slightly different from the values which it shows when the LUTs are linear. Apparently, this is a bug in madVR. This bug may not have any visual consequences because madVR makes the LUTs almost linear, but still it's a thing of concern as this will engage the GPU processing of LUTs adding an extra dithering noise to the video.
Stereodude
22nd April 2016, 01:24
I'm running a Nvidia GTX 650 under Windows 10 x64 with the 364.51 drivers driving a 2560x1440 display. With madVR 90.17 my chroma is always DXVA no matter what I set it to in madVR's settings. I tried MPEG-2, H.264, interlaced & progressive content. I've used madVR for years with AMD HW in my HTPC so I'm not a total n00b. It doesn't appear to be a OSD bug since the rendering time doesn't change when I change the chroma scaling mode. Am I missing something or is this a known bug?
Edit: I had LAV set to DXVA native... Changing it to something else mostly fixes that. However, if deinterlacing is enabled you automatically get DXVA chroma regardless of the decoder mode. Is that a Nvidia or Windows 10 thing? My AMD setup in my HTPC doesn't do that...
huhn
22nd April 2016, 01:37
I'm running a Nvidia GTX 650 under Windows 10 x64 with the 364.51 drivers driving a 2560x1440 display. With madVR 90.17 my chroma is always DXVA no matter what I set it to in madVR's settings. I tried MPEG-2, H.264, interlaced & progressive content. I've used madVR for years with AMD HW in my HTPC so I'm not a total n00b. It doesn't appear to be a OSD bug since the rendering time doesn't change when I change the chroma scaling mode. Am I missing something or is this a known bug?
Edit: I had LAV set to DXVA native... Changing it to something else mostly fixes that. However, if deinterlacing is enabled you automatically get DXVA chroma regardless of the decoder mode. Is that a Nvidia or Windows 10 thing? My AMD setup in my HTPC doesn't do that...
look at the trade quality for performance options.
your AMD setup would do the some. (2 and 3)
and don't forget nvidia DXVA native lowers PQ by a lot even without DXVA chroma scaling.
Sunspark
22nd April 2016, 04:32
Guys, I'm having problems with excessive presentation glitches and dropped frames. In Windows 8.1 and Windows 10 does not appear this problem of presentation glitches or dropped frames, but in windows 7 ultimate x64 sp1 is happening. A picture of the problem:
My pc configuration is this:
4770k
Z87-GD65 gaming
8gb 1600
hd 1tb SATA3
I am using the onboard video 4770k, the Intel HD 4600.
What changes should I do to stop this problem of excessive presentation glitches and dropped frames? In Windows 8.1 works perfectly, but in Windows 7 is taking place this problem. I appreciate if you guys can help me guys.
Hi, you will get dropped frames when you're switching in and out of modes. What you should do instead is monitor playback after resetting the counter. Ctrl-R resets counter values to 0. If you're not experiencing the issue after reset, then it is fine.
I have a Broadwell using the HD 6000 on Windows 7 running under the classic theme.
I use Intel Quicksync in LAV 0.68 though I used to use copyback.
Maybe check the video driver version you have.. I'm using 4279.
Stereodude
22nd April 2016, 13:18
look at the trade quality for performance options.
your AMD setup would do the some. (2 and 3)
and don't forget nvidia DXVA native lowers PQ by a lot even without DXVA chroma scaling.
Thanks for pointing me in the right direction. I don't remember those on my HTPC, but it's a few revisions behind and it's been a while since I set it up.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.