madVR - high quality video renderer (GPU assisted)

[aufkrawall]

I can confirm that madVR always crashes when using NNEDI3 chroma scaling + D3D11VA decoding at the same time on GTX 1070.

madshi, did you see my question regarding D3D11VA scaling/deinterlacing ETA? I know that you usually don't comment about ETAs, but I'd be also happy about a simple "when it's done". ;)

[Asmodian]

Interesting! Did you also try editing the horizontal porches in such a way that they're dividable by 2, 4 or even 8? Maybe it works that way?


Yes! Even simply keeping the porches even causes TV to be fine with custom settings even in 12-bit. I can use one of the "80" compatibility modes that, in my case, adds 36 to the front porch and modifies the pixel clock for no expected frame drops/repeats ever. :)

I had modified each setting by one and it went crazy on the horizontal porches but simply using 2 instead would have been fine. :o

(minor spelling error in the optimize timing parameters window: compatability should be compatibility)


Can you provide more information on how to reproduce this?


If I set my display to any other refresh rate (e.g. 30 or 60 Hz), and then play a 23Hz video with auto refresh rate switching enabled in madVR, playback takes an oddly long time to start (longer then just the refresh rate switch) and LAV has fallen back to avcodec for decoding when it does start (and there is no DXVA2 in madVR's OSD). 8-bit or 12-bit doesn't change this behavior and DXVA2 copyback is fine.

[Gee]

Is it possible to render video Files with madVR, also? Or only live viewing rendering?

[Asmodian]

Only live viewing, there is no mechanism that will copy the rendered video back off the GPU. madshi has mentioned that this may come some day. :)

[Gee]

ok :)

[egandt]

I'm seeing a possible issue with HDR playback in 0.92.2, I see HDR for a second then nothing SDR, however if I then uncheck click ok, then select and click ok "send HDR metadata to the display" HDR play works, so I have to manually cycle this radio button to get HDR playback.


Running 0.92.1 I do not see this issue, however with 0.92.1 I have no sound using HDR. for now I will manually select/deselect "send HDR metadata to the display", in 0.92.2 as sound is always better.

Thanks,
ERIC

[austinminton]

Oh well, my workaround for FSE mode with the latest Nvidia drivers has stopped working. I'll make it work again in the next build.

Just to point out that previous madvr 0.92.1 still correctly switches to HDR in FSE using latest nvidia drivers (385.41). Guess something has changed in 0.92.2 as well.

[oldpainlesskodi]

1080 on Win 10 (non-creators) using madvr (0.92.2) with driver 385.28 HDR FSE working fine.

K

[70MM]

Those are film, right? Film on DVD - if properly encoded - is supposed to be IVTC'd, not deinterlaced as with video.
.
Thank you elFilou I think its now fixed.
I have auto deinterlacing ticked plus manual film mode ticked.
NTSC DVDs are not dropping/repeating frames and are displaing ivtc'd and Pal DVDs are not dropping/repeating frames and are also displaying ivtc'd.

So for now I think its all working and switching automatically now for NTSC/Pal DVDs.

[Asmodian]

I don't usually use exclusive mode so I hadn't noticed but with madVR 0.92.2, Win 10 1703, and a Titan XP with driver 385.41 my TV does switch out of HDR when exclusive mode activates.

[Xterminator]

I'm facing some weird bug where custom modes for my TV is showing the resolutions for my primary monitor instead of the TV. In the previous version, it would show the correct resolutions, but I had to set my receiver as a TV instead of the receiver option because the custom modes tab would disappear instantly.

I also didn't see this in the Custom Mode Tutorial, but I feel this should be noted there. Apparently you can't have DSR enabled on NVIDIA cards if you want custom resolutions to work. I was really confused when my timings weren't being saved at all, until I checked the NVIDIA Control Panel for custom resolutions and it said DSR had to be disabled for me to use custom resolutions. :p

[Jasch]

Hi madshi, thx for you response, here are the Infos.

Sony ZD9
Denon X6300H

Windows 10 En 2016 LTSB (1607)
Sap Nitro 4GB Rx460@560Bios
AMD Cat 17.8.2
Lavfilter Nightly 70.2.66
MadVR 92.2

testet with MPC-hc and Dvbviewer all 32bit

https://picload.org/view/rwipgpal/lav.jpg.html
https://picload.org/view/rwipgpai/madvr.jpg.html
https://picload.org/view/rwipgpaw/osd.jpg.html

I testet also a lot of settings RGB 4:4:4 full and reduced, YCbCr 4:4:4,4:2:2 in driver, 10 and 12 bit in driver(madvr set to 10bit and higher), in LAV all 3 settings
I try´d windowed and exclusive....

HDR from shield with amazon or netflix is working.

If you need more info, just let me know.

[madshi]

Hmm. As of latest update, 10 bit videos on the laptop now have very large spikes in render time every 2-5 seconds. Reverting to the one a couple weeks ago fixes this. This is the one with an HD 8870 slaved onto an intel hd4000.

Oddly enough, the desktop playing the same file is fine. This one has an RX480, with no intel CPU enabled.
Not sure what do say about this. I simply don't have enough information to suggest anything specific.

D3D11 DXVA doesn't crash anymore with v0.92.2
But now the video freezes for about 3 seconds each time there is a switch between full screen and windowed mode with refresh rate change. Than the video continues normally.
Can you create a debug log, zip it and upload it somewhere (don't attach it here) for me to look at?

Can't play video when chroma upscaling NNEDI3 activated. Error detected also when try to change to NNEDI3.

https://www.youtube.com/watch?v=hILLamChO8I
Can't seem to play/access this video, it seems to be blocked?

Is this with the new native D3D11 decoder, only? Or does this also happen with other decoders?

I can confirm that madVR always crashes when using NNEDI3 chroma scaling + D3D11VA decoding at the same time on GTX 1070.
Ah, ok, will have to check that.

did you see my question regarding D3D11VA scaling/deinterlacing ETA
Yes, and I replied to it.

Yes! Even simply keeping the porches even causes TV to be fine with custom settings even in 12-bit. I can use one of the "80" compatibility modes that, in my case, adds 36 to the front porch and modifies the pixel clock for no expected frame drops/repeats ever. :)
Good to hear! Seems I should apply a bigger "compatability hit" for modes with odd horizontal porch.

If I set my display to any other refresh rate (e.g. 30 or 60 Hz), and then play a 23Hz video with auto refresh rate switching enabled in madVR, playback takes an oddly long time to start (longer then just the refresh rate switch) and LAV has fallen back to avcodec for decoding when it does start (and there is no DXVA2 in madVR's OSD). 8-bit or 12-bit doesn't change this behavior and DXVA2 copyback is fine.
Can you create a debug log for this?

I'm seeing a possible issue with HDR playback in 0.92.2, I see HDR for a second then nothing SDR, however if I then uncheck click ok, then select and click ok "send HDR metadata to the display" HDR play works, so I have to manually cycle this radio button to get HDR playback.
Should be fixed in the next build.

I'm facing some weird bug where custom modes for my TV is showing the resolutions for my primary monitor instead of the TV. In the previous version, it would show the correct resolutions, but I had to set my receiver as a TV instead of the receiver option because the custom modes tab would disappear instantly.
I can reproduce it, thanks for letting me know. Should be fixed in the next build.

Hi madshi, thx for you response, here are the Infos.

Sony ZD9
Denon X6300H

Windows 10 En 2016 LTSB (1607)
Sap Nitro 4GB Rx460@560Bios
AMD Cat 17.8.2
Lavfilter Nightly 70.2.66
MadVR 92.2

testet with MPC-hc and Dvbviewer all 32bit

I testet also a lot of settings RGB 4:4:4 full and reduced, YCbCr 4:4:4,4:2:2 in driver, 10 and 12 bit in driver(madvr set to 10bit and higher), in LAV all 3 settings
I try´d windowed and exclusive....
Please always use RGB full. Your settings has Overlay active which AMD not supports. It shouldn't matter, but I'd suggest you uncheck that, just to be safe.

What does the EDID report say in the madVR settings dialog? Does it report HDR to be supported for your display?

[madshi]

P.S: @FDisk80 and @Asmodian, can you please update to the very latest LAV nightly build? Older LAV nightlies had a bug which could result in D3D11 copyback to become active instead of D3D11 native. So the latest LAV nightly might already fix the problem you've reported.

[DragonQ]

When using DX11 decoding in LAV Filters, rendering time dropped from ~30 ms to ~10 ms for 1080p videos on my 1080p laptop when I switched from DX9 to DX11 render path. I'm sure I had issues in the past with the DX11 render path though, probably related to interlaced files, but for now I'll leave it like that and see how it goes. If deinterlacing gets implemented and works correctly I think I'll be sticking with it going forward!

[Manni]

Is this behaviour different depending on which decoder you're using (native DXVA2 vs native D3D11 DXVA vs software or DXVA copyback)? Did this ever work correctly?

I don't have the RM Brightness file.


Behaviour is the same irrespective of the decoder. It's very weird. If you let the file run, it causes an out of memory error (I have 16Gb installed!).

I reverted to my system image from the 23rd (when I did the HDR Metadata tests on the 3 files with MadVR 0.92.1). Behaviour is the same, so not caused by a change in the code.

I was focusing on the HDR data when I tested the file and as it is displayed I might have missed the issue then (it's a brightness pattern so mostly dark).

You can download the demo patterns from RM here: http://www.avsforum.com/forum/139-display-calibration/2463698-r-masciola-s-hdr-10-uhd-test-patterns.html

They all seem to cause the same issue. I calibrate HDR with the UB900 (my primary source for HDR content) so I haven't noticed this before on the HTPC.

Beware, I know that you won't believe that it could be the cause, but testing the pattern yesterday and letting it run a few times longer than I had when I was simply reading the metadata (I was trying to test the various decoders as requested) completely warped my OS partition, possibly due to the RAM overflow condition, hence why I had to reinstall from system image. I therefore highly suggest someone testing this has an up-to-date backup before running this patterns for more than a little while.

I am aware it sounds impossible, I am just reporting what happened here. Better safe than sorry :)


madVR shows the important parts of the metadata in the OSD, if they're "good", most importantly the video's max luminance and the gamut (usually DCI-P3). madVR *also* tells you if the metadata is bad or missing (I don't know how to detect the difference). In that case madVR shows "HDR, unknown properties", as nevcairiel already mentioned. So from what I can see, all important information is already available in the OSD right now.


I'm not going to fight for this, I'm only providing feedback and trying to explain why what you're doing is good in theory but is a bad idea given how many HDR displays (Able to detect HDR metadata and switch to HDR mode) behave at the moment. Many of them (including all the JVC projectors) completely discard the HDR metadata. They do not try to read it in any way. They detect it, switch to their fixed mode (the same for 1000nits and 4000nits content) and that's it. So you "correcting" the metadata serves no purpose, except preventing the user from knowing what the actual metadata is, when they have the capability to do so and can act accordingly.

I also believe that the way you describe Passthrough mode, "the display receives the original HDR content untouched" is misleading if you are manipulating HDR metadata for whatever reason you see fit.

In addition, changing the metadata prevents finding issues in the way you handle it, as we have found in the last few days. Again, in my opinion, pass-through should be pass-through if called that way and described that way.

I would therefore suggest one of the following options:

1) If you don't care about the possible issues I'm reporting, you keep things the same but stop calling Passthrough mode that way and stop describing it as passing the HDR content untouched, because this is not what MadVR is doing if it changes the metadata for arbitrary reasons. It's an optimized mode that might be better for some displays (those that actually act on the static HDR10 metadata), but not for all. At the very least there should be an indicator in the OSD to warn that the metadata was molested and doesn't reflect the data present in the original content.

2) You offer a "native metadata" mode that does what passthrough should be doing (passthrough the HDR content untouched, including the metadata). Of course that doesn't include things we might want MadVR to do and can select manually, for example, I'm very happy to ask MadVR to do the chroma upscaling in that mode (it's doing a great job with NGU anti-alias). But if I ask MadVR to do nothing, it should do nothing in that mode and certainly not change the original metadata, especially when not displaying it in the OSD.

3) Display all the native metadata in the OSD so that we know what was in the source before you send the "corrected" data to the display.

It's your opinion which parameters matter and which do not. When calibrating, the reported mastering black level can matter as much as what the max brightness is, depending on the curve/settings we want to use and the options we want to have. HDR10 is a big mess, it doesn't work in "auto" mode with most displays, and behaving as if it did is not really helpful.

Again, I'm not talking about my own needs. I can get all this unmolested data from the UB900. I currently play all my HDR content from my UB900. I simply hope that at some point, I'll be able to use MadVR to play my UHD Blurays and it would be a shame to have to keep the UB900 just to be able to know what the actual metadata is so that we can select the appropriate calibration, should we wish to optimize it depending on the content.

Finally, this is purely theoretical because MadVR in the current build doesn't seem to be replacing the metadata even when it's set to zero. For example, the Exodus trailer reports 0,0 for MaxCLL/FALL, and MadVR correctly reports this.

In any case, it's your and Nevcairiel's decision what you want to do with metadata you deem unfit to use. I think it would be good to have an option to get the native metadata, unmolested, if we wish to. If you decide against it, it's not the end of the word, we'll still enjoy the product of your amazing collaboration :)

I wish we were in a world where all displays would act on metadata and not simply switch to a fixed mode whenever they detect it, in which case your decision would make complete sense, but in the real world as it is today, where many if not most displays simply discard the metadata, MadVR/LAV would behave in a worse way than a standalone player (from a calibration optimization point of view), at least for most current HDR projectors, and that's not something I'm used to with this great combo :)

[Manni]

Forgot to say that the latest nVidia drivers (385.41) prevent from selecting 12bits in a custom mode in the nVidia control panel. Only 8bits is available. I reverted to 385.28 for this reason.

[mickeekung]

https://www.youtube.com/watch?v=hILLamChO8I

OK unchecked private video now. I hope you will look into it.

Thanks

:)

[aufkrawall]

Is bilinear downscaling working correctly currently? It gives me quite higher GPU usage and rendertimes than DXVA2 downscaling.
I have the same rendertimes, GPU clock and GPU usage with bilinear for chroma and luma like with bicubic when downscaling 4k 60fps to ~1440p.
I've already resetted the madVR settings to check if it makes a difference (doesn't).


Yes, and I replied to it.

I really don't find it.

[austinminton]

Beware, I know that you won't believe that it could be the cause, but testing the pattern yesterday and letting it run a few times longer than I had when I was simply reading the metadata (I was trying to test the various decoders as requested) completely warped my OS partition, possibly due to the RAM overflow condition, hence why I had to reinstall from system image. I therefore highly suggest someone testing this has an up-to-date backup before running this patterns for more than a little while.

I am aware it sounds impossible, I am just reporting what happened here. Better safe than sorry :)


About a week back I was watching a bunch of HDR clips on my HTPC and testing the quality vs the internal player of the TV. I don't quite remember why, but I was forced to do a reboot and the OS partition was corrupted and completely unreadable. Took the opportunity to do a clean install of the OS. Did not even consider watching HDR clips could cause that problem. But now that you have mentioned it, you might be onto something there. Again, I agree, sounds impossible.

[nlnl]

A long time ago I stopped updating AMD video driver. The reason was the problem with forcing vector adaptive hardware deinterlacing (Windows 7).
Should I update now?
Can I force it using actual driver?

[Jasch]

Please always use RGB full. Your settings has Overlay active which AMD not supports. It shouldn't matter, but I'd suggest you uncheck that, just to be safe.

What does the EDID report say in the madVR settings dialog? Does it report HDR to be supported for your display?

I try´d with overlay or without, makes no diff..

HDR is supported.

https://picload.org/view/rwipwcwa/edid.jpg.html

[oddball]

I give up on getting AMD HDR to work from PC for now. If I need HDR from the PC I will just use the TV's inbuilt decoder and stream off my network.

[madshi]

Behaviour is the same irrespective of the decoder. It's very weird. If you let the file run, it causes an out of memory error (I have 16Gb installed!).
Hmmm... These files seem to work just fine on my PC? Tested the MP4 versions.

At the very least there should be an indicator in the OSD to warn that the metadata was molested and doesn't reflect the data present in the original content.
nevcairiel and I have both already told you: This indicator already exists. If madVR writes "HDR, unknown properties", it will output default metadata instead.

It's your opinion which parameters matter and which do not. When calibrating, the reported mastering black level can matter as much as what the max brightness is, depending on the curve/settings we want to use and the options we want to have.
If you believe that the black level metadata is important, then let's discuss what madVR can do to *automatically* adjust to this metadata in some way. I tend to not be interested in any features that require users to dial in manual tweaks for every different movie file somewhere. That's bad usability, IMHO, and I don't want to support such concepts, if I can avoid it.

Finally, this is purely theoretical because MadVR in the current build doesn't seem to be replacing the metadata even when it's set to zero. For example, the Exodus trailer reports 0,0 for MaxCLL/FALL, and MadVR correctly reports this.
MaxCLL/FALL are a special case.

OK unchecked private video now. I hope you will look into it.
This should be fixed in the next build. I'd recommend to use NGU-AA instead of NNEDI3 for chroma upscaling, though. You'll probably get a better quality vs speed ratio from NGU-AA.

Is bilinear downscaling working correctly currently? It gives me quite higher GPU usage and rendertimes than DXVA2 downscaling.
I have the same rendertimes, GPU clock and GPU usage with bilinear for chroma and luma like with bicubic when downscaling 4k 60fps to ~1440p.
I've already resetted the madVR settings to check if it makes a difference (doesn't).
Are you looking at the overall rendering times, or at the step-by-step times? Depending on various settings, madVR might upscale chroma to luma res, even if you use bilinear image downscaling. So looking at overall rendering times may not give you a complete picture of where the rendering time is spent.

I really don't find it.
Oh, I think I know why. I wanted to answer your question of whether I can give an ETA with "No.", but doom9 refused to post a 3 character reply, so it got lost.

I try´d with overlay or without, makes no diff..

HDR is supported.

https://picload.org/view/rwipwcwa/edid.jpg.html
Oh, I found the reason. It should be fixed in the next build.

[Manni]

Hmmm... These files seem to work just fine on my PC? Tested the MP4 versions.


Yes, I used the MP4 version, and the MKV version I made from the MP4 behaved the same, i.e. badly. I don't know what to say, unless there is a difference between the demo files and the paid-for version (which are the ones I'm using). It's the only files causing problem, and only on the HTPC. They play fine in the UB900, and every other file plays fine too.


nevcairiel and I have both already told you: This indicator already exists. If madVR writes "HDR, unknown properties", it will output default metadata instead.


Thanks, I missed that.


If you believe that the black level metadata is important, then let's discuss what madVR can do to *automatically* adjust to this metadata in some way. I tend to not be interested in any features that require users to dial in manual tweaks for every different movie file somewhere. That's bad usability, IMHO, and I don't want to support such concepts, if I can avoid it.


I was using this as an example. I personally prefer to use a calibration that set black to level 77 for all titles as it doesn't seem to cause any black crush even for those mastered with black at zero, while doing the opposite, calibrating for black=64, causes a raised black floor for titles mastered to 0.005nits. However, some prefer to use a different curve depending on the black level reported. Similarly, I'm happy most of the time with a single curve for all titles which hard clips at 4000nits, some prefer to use a different curve to eek the last percentage of brightness/contrast depending on the max brightness of each title. All this is because the displays, most of the time, do not take this information into account.

Point is, you can do whatever you want to provide the best user experience in any of the HDR modes controlled by MadVR, but IMHO you should also provide a proper passthrough mode (possibly different from the current passthrough mode, or offering an option within this mode) where the data is unmolested.

It is not up to MadVR to decide which calibration I want to use. For example, when playing bluray, where there is no standard for gamma, you're not forcing which gamma curve you prefer. We are free to use BT1886 or power gamma 2.2 or 2.4 depending on our taste, setup, and what we believe is most correct for each title. There is no metadata indicated which gamma curve was used for bluray, but if there was one and displays were not able to act on it automatically I wouldn't want MadVR to decide what to do if it was incorrect. I'd want to know it is incorrect so I can make the best decision.

At the moment, we are in a similar situation with HDR10. There is no standard for the consumer playback side, it's not implemented the same way by each manufacturer, so it's important to have all the info in order to make the right decision.

I am not talking about tweaking anything in MadVR. I'm talking about having a mode that passes through the metadata unmolested, a manual mode if you wish. Think of it as a "source direct" mode in an AVR, where we have the option to ask the AVR to not touch the content so that an external VP or the display can upscale/process it instead.

If you're dumbing down MadVR so that it can be used by people who don't know what they are doing, great, I'm sure they'll appreciate the simplicity, but that doesn't take away that some of us will prefer to get the data unmolested and make the decision ourselves about which calibration to apply.

Again I think this is because of the discrepancy between your claim for HDR Passthrough, "the HDR content is untouched", and the actual process which can result in some data being changed without us knowing which part of the data or in which way it was changed.

I think your aim to automatize/optimize things and try to make the metadata as correct as possible for displays that interpret it is great. It doesn't take away that in other situations, especially for displays that don't give a monkey about metadata such as most HDR projectors on the market now, knowing what the metadata is exactly is far more useful than getting default metadata without knowing which part is original and which part is processed or fixed.

I agree that projectors are a special case due to their limited max brightness, but that only makes it more important to get all the metadata so we can make the best decision according to the content.


MaxCLL/FALL are a special case.


In which way? Does it mean that you will always report them as they are even if they are set to zero, or does it mean that for now we get the original data but in the future you will replace the zero values with default ones?

[aufkrawall]

Are you looking at the overall rendering times, or at the step-by-step times? Depending on various settings, madVR might upscale chroma to luma res, even if you use bilinear image downscaling. So looking at overall rendering times may not give you a complete picture of where the rendering time is spent.

Overall, but I tested bilinear chroma upscaling + bilinear downscaling vs. bicubic60 chroma upscaling + bicubic60 downscaling. The option to scale chroma seperately was disabled (like any other additional option which could influence performance).

I tested again a few times, and there is a difference, but a very small one. DXVA2 scaling is definitely way faster than bilinear. Is that supposed to be?

DXVA2 scaling: 2.1ms
bilinear: 5ms
bicubic: 5.5ms
(GPU set to maximum performance power profile, which results in ~1.6GHz for all three scalers)



Oh, I think I know why. I wanted to answer your question of whether I can give an ETA with "No.", but doom9 refused to post a 3 character reply, so it got lost.

Meh. Well, still better than no answer at least.

[Siso]

In identification tab, madvr shows wrong native resolution of the monitor, it show 1920x1080p, my monitor is 2560x1080p, is this a bug?

[oddball]

OK just in case you (Madshi) can get HDR working properly on my LG OLED perhaps this might help?

00 FF FF FF FF FF FF 00 1E 6D 01 00 01 01 01 01
01 1A 01 03 80 A0 5A 78 0A EE 91 A3 54 4C 99 26
0F 50 54 A1 08 00 31 40 45 40 61 40 71 40 81 80
01 01 01 01 01 01 08 E8 00 30 F2 70 5A 80 B0 58
8A 00 40 84 63 00 00 1E 02 3A 80 18 71 38 2D 40
58 2C 45 00 40 84 63 00 00 1E 00 00 00 FD 00 3A
3E 1E 88 3C 00 0A 20 20 20 20 20 20 00 00 00 FC
00 4C 47 20 54 56 0A 20 20 20 20 20 20 20 01 9F

02 03 5D F1 58 61 60 10 1F 04 13 05 14 03 02 12
20 21 22 15 01 5D 5E 5F 65 66 62 63 64 29 3D 06
C0 15 07 50 09 57 07 6E 03 0C 00 30 00 B8 3C 20
00 80 01 02 03 04 67 D8 5D C4 01 78 80 03 E2 00
CF E3 05 C0 00 E3 06 05 01 E4 0F 03 00 18 EE 01
46 D0 00 24 18 09 00 AD 52 44 A9 23 0C 66 21 50
B0 51 00 1B 30 40 70 36 00 40 84 63 00 00 1E 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 E8

[Asmodian]

but that doesn't take away that some of us will prefer to get the data unmolested and make the decision ourselves about which calibration to apply.

Again I think this is because of the discrepancy between your claim for HDR Passthrough, "the HDR content is untouched", and the actual process which can result in some data being changed without us knowing which part of the data or in which way it was changed.


This only happens with obviously broken metadata though, and you are told when the metadata is obviously broken. Isn't that all you need? I can see being curious as to what the broken metadata actually was (I am curious about a lot of things) but you do not want to use any of it to base a calibration choice on. It is obviously broken; it shouldn't be used for display decisions, isn't that what we mean by broken?

Instead of picking display calibrations based on the metadata in dodgy HDR files just use your eyes, it sounds like you have a very good grasp of how you want HDR to look and your eyes are MUCH more reliable than known bad metadata.

Don't get me wrong, I would love a super verbose mode for the OSD with multiple columns of everything I can think of (original HDR metadata included). A little graph of the rendering times for the last 500 or so frames would also be great, it could even have a horizontal line at the video's frame time. :D

There are a lot of interesting things to know but they aren't critical for display decisions.

[Jasch]

Oh, I found the reason. It should be fixed in the next build.

I guess, my TV reports HLG and st-2084, and not direct HDR10
Sony promised an update to even support DolbyVision on ZD9.

Thx, if you need me something to test, just let me know.

[Asmodian]

Can you create a debug log for this?

I cannot reproduce it with the newest LAV nightly (0.70.2.66-git). :)

[Manni]

This only happens with obviously broken metadata though, and you are told when the metadata is obviously broken. Isn't that all you need? I can see being curious as to what the broken metadata actually was (I am curious about a lot of things) but you do not want to use any of it to base a calibration choice on. It is obviously broken; it shouldn't be used for display decisions, isn't that what we mean by broken?

Instead of picking display calibrations based on the metadata in dodgy HDR files just use your eyes, it sounds like you have a very good grasp of how you want HDR to look and your eyes are MUCH more reliable than known bad metadata.

Don't get me wrong, I would love a super verbose mode for the OSD with multiple columns of everything I can think of (original HDR metadata included). A little graph of the rendering times for the last 500 or so frames would also be great, it could even have a horizontal line at the video's frame time. :D

There are a lot of interesting things to know but they aren't critical for display decisions.

Zero values for some fields doesn't mean obviously broken metadata. Having no idea what MadVR does, knowing that it can discard all the metadata if some fields are invalid or zeroed isn't helpful.

I'm not asking for MadrVR to provide a super verbose OSD, I'm only asking for it to give us a way (option, mode) that does what a standalone player does, which is to pass-through the untouched HDR content, as the pass-through mode is currently described. No more, no less.

If Madshi doesn't want to provide a pass-through mode that allows us to get the untouched content, that's his right of course and it's very easy to do, he only has to correct the description. As its stands, it's misleading/incorrect because the content IS touched/molested. In any case, he is the boss, he does what he wants with his toy :)

I don't need any advice regarding HDR calibration, thank you very much :)

[Grimsdyke]

Hi Madshi, I have finally managed to get the 'perfectly optimized' message on the custom mode tab for 48p. Very cool indeed.

But I noticed that there is now a 'weird' glitch on the screen every 4 minutes or so. It's hard to describe but it looks like as if the screen is going to 'fail' but comes back after a fraction of a second.

Only 48p is affected and, I believe, it started with reaching the perfect settings. It certainly was not there with older versions of madvr !
Before I play around and maybe lose this setting I would like to ask if you maybe have an idea what I can do.

Thanks

[Manni]

Hmmm... These files seem to work just fine on my PC? Tested the MP4 versions.

Dang, I tested the demo files and they don't seem to be mastered the same way as the paid-for version. Sorry I wasted your time with these demo files, I thought they were a subset of the full version.

I'll email/PM you a link to a sample of one of the problematic files (the RM Brightness), as I can't post a public link to the whole file. [EDIT: email sent]

[JarrettH]

What are the differences between CVT reduced blanking v1 and v2? Is one preferred over the other? Just curious. Thanks

[Manni]

Unfortunately it looks like FSE is still needed for 3D here. Without it, the display switches to 1080p23FP, MadVR reports 3D, but the picture is 2D (even the OSD is "flat"). If I enable FSE (even on the fly), I get 3D right away. I tried reverting to the last LAV that had FSE-Less 3D working (nightly 49), as I initially thought it might have been a change in LAV that got it to work, but the results are the same.

So just as I don't know what made FSE-less 3D work, I don't know what broke it. Reverting to FSE for 3D, as it seems to be the only reliable way to get 3D here.

[nevcairiel]

What are the differences between CVT reduced blanking v1 and v2? Is one preferred over the other? Just curious. Thanks

Its different timing standards (or more accurately, v2 is a "newer" version of the CVT RB standard).

CVT RB2 is technically one of the best modes to use since it reduces the blanking overhead and increases the pixel clock precision, but not all displays support it (and unless you're bandwidth constrained, it probably won't make any difference - although some screens actually only support some of their modes in a reduced-blanking configuration)

The blanking interval is a hold-over from CRTs, which was a small "pause" in image data so the CRT could re-position the electron beam appropriately - but LCDs don't need it, so you can save bandwidth if you use a "reduced blanking" mode.

[arrgh]

@madshi
unfortunately also the new Version hangs with MPC-BE if exiting 3D in Win10 AND Win81;

and in Win81, both 2D and 3D judder heavely in playback on a Intel Kaby Lake graphics

still hope there might be a solution...

[cyber201]

hi madshi, thanks for your work.
I try to optimize my custom modes, but I have all the HZ (23p,24p,25p,ecc,60p) in standard mode, unknown timing details.
How i can Optimize those mode?
The optimize button don't appear.
Thanks

[JarrettH]

Its different timing standards (or more accurately, v2 is a "newer" version of the CVT RB standard).

CVT RB2 is technically one of the best modes to use since it reduces the blanking overhead and increases the pixel clock precision, but not all displays support it (and unless you're bandwidth constrained, it probably won't make any difference - although some screens actually only support some of their modes in a reduced-blanking configuration)

The blanking interval is a hold-over from CRTs, which was a small "pause" in image data so the CRT could re-position the electron beam appropriately - but LCDs don't need it, so you can save bandwidth if you use a "reduced blanking" mode.

Thanks, nev! I noticed the tighter timings, but wanted to know the technicals which you explained :D

@madshi I got 71.928 hz running! I added 71 hz, ran a test video for 35 minutes, applied optimized pixel clock #1 (compatibility 75), repeated for 35 minutes, and went with optimized pixel clock #1 again, which was now finer tuned (compatibility 80).

[SamuriHL]

I'm finally back in the game with a new video card upgrade. I got a 1060 a few weeks ago and started upping my quality settings in madvr and I have to say the last year or so of development has been tremendous. Well done to madshi and Nev. I like this dx11 decoding, too. SWEET! For me with the latest nVidia drivers, I can use 3D in windowed mode (FINALLY...my 680 never allowed it) no problem. NGU is really awesome. i see the scaling has improved a lot. I'm doing DVD to 1080p (still rocking my Panasonic plasma 1080p for now) and it looks as good as a blu-ray. Very pleased!

[Asmodian]

Can you create a debug log for this?

I spoke too soon, I was able to reproduce it after all. It might be something to do with a "fresh" custom resolution, it seems to only happen the first time I use new timings with a custom resolution. :confused:
madVR - log.txt (https://www.mediafire.com/file/bdy61e0la9gf0ew/madVR%20-%20log.7z)

[Jasch]

Unfortunately it looks like FSE is still needed for 3D here. Without it, the display switches to 1080p23FP, MadVR reports 3D, but the picture is 2D (even the OSD is "flat"). If I enable FSE (even on the fly), I get 3D right away. I tried reverting to the last LAV that had FSE-Less 3D working (nightly 49), as I initially thought it might have been a change in LAV that got it to work, but the results are the same.

So just as I don't know what made FSE-less 3D work, I don't know what broke it. Reverting to FSE for 3D, as it seems to be the only reliable way to get 3D here.

I had a similar Problem a while back,
for me it was the subtitle rendering, with subtitle 3D was flat, disabled subtitle (no XV-VSFilter in chain) and 3D was back to normal.
Mabe u can check it.

[StinDaWg]

Are you using the new custom mode feature? In any case, there's not too much I can do about this. You may need to try to find out what changed to cause this issue. I don't think it's madVR, unless activating the "hack Direct3D to make 24.000Hz and 60.000Hz work" option helps?
Not sure what happened but I rebooted my pc and now the vsync is correct. Everything seems fine. Back to 6-12 hours for a frame drop.

[FDisk80]

Can you create a debug log, zip it and upload it somewhere (don't attach it here) for me to look at?


Sure, but how do I generate a debug log?

[Razoola]

@madshi,

The new .2 update adds the custom resolutions to my TV's connected via AVR. It also now shows the custom resolution tab for the monitor we talked about before where it was missing (we discovered BAD_EDID in registry). However I think its incorrect and actually showing custom resolution settings for one of my TV's connected via AVR and not the monitor. I say this because the monitor only supports 1680x1050 max resolution but I see custom resolution default settings for 2160p in the custom resolution tab.

I hope this makes sence what Im trying to explain.

[Matching_Mole]

I don't know exactly why but I failed to have measurement with my htpc though I succeed on my desktop PC. I tried several time and in several way (play a video file loaded before to click on optimize, load a new video file after and play it,...). Each time, no measurements found in the custom rate screen. So far, I tried to have measurement for 1080/23p on my htpc and get the ones for 1200/59p on my desktop PC.

I use the pretty same software config between my two PC (last official MPC-HC version - i tried in 32 or 64 bit version - , last offcial lavfilter version, internal audio renderer and nothing else). The only differences are hardware/drivers and especially GPU (Nano Fury with 17.7.2 on my htpc and a quite old Radeon 7900 with 16.40 drivers - yeah, I should update - on my desktop pc)

I should do something wrong but I don't find what. Anyone have an idea?

[madshi]

In which way? Does it mean that you will always report them as they are even if they are set to zero, or does it mean that for now we get the original data but in the future you will replace the zero values with default ones?
Unlike the other metadata, MaxCLL/FALL are easy to detect as 0, and I accept that as is and don't touch it. Also, unlike the other metadata, many of the HDR demos have MaxCLL/FALL set to 0.

Overall, but I tested bilinear chroma upscaling + bilinear downscaling vs. bicubic60 chroma upscaling + bicubic60 downscaling. The option to scale chroma seperately was disabled (like any other additional option which could influence performance).

I tested again a few times, and there is a difference, but a very small one. DXVA2 scaling is definitely way faster than bilinear. Is that supposed to be?
As I already explained in my previous comment, looking at just the overall rendering times is not a good idea to judge the speed of image scaling algorithms.

In identification tab, madvr shows wrong native resolution of the monitor, it show 1920x1080p, my monitor is 2560x1080p, is this a bug?
Do you have 2 monitors or just one? There's a bug in v0.92.2 which always uses the EDID of the first monitor.

Hi Madshi, I have finally managed to get the 'perfectly optimized' message on the custom mode tab for 48p. Very cool indeed.

But I noticed that there is now a 'weird' glitch on the screen every 4 minutes or so. It's hard to describe but it looks like as if the screen is going to 'fail' but comes back after a fraction of a second.

Only 48p is affected and, I believe, it started with reaching the perfect settings. It certainly was not there with older versions of madvr !
Before I play around and maybe lose this setting I would like to ask if you maybe have an idea what I can do.
My best guess would be that your TV simply doesn't like this optimized mode very well, for some reason. You may have to delete the custom mode and redo it, hoping that this time it might work out better. The measured data is not absolutely exact, so there's a good chance that if you try again, you'll end up with a somewhat different "perfectly optimized" mode. So maybe you'll have better luck next time. Of course you don't necessarily have to have a "perfectly optimized" mode. Having a frame drop/repeat only every 4 hours or so should already be sufficient. So I guess if you achieve a 4 hour drop/repeat and it works without glitches, you could write the timings details down before you continue to optimize, as a safe fallback.

I'll email/PM you a link to a sample of one of the problematic files (the RM Brightness), as I can't post a public link to the whole file. [EDIT: email sent]
Seems to work fine on my PC, at least on my 4K HDR TV, in both windowed and 10bit FSE mode. On my non-HDR PC monitor the flashing doesn't work, for some weird reason, not sure why, but other than that it seems to work fine, too.

unfortunately also the new Version hangs with MPC-BE if exiting 3D in Win10 AND Win81;

and in Win81, both 2D and 3D judder heavely in playback on a Intel Kaby Lake graphics
"Also"? So this is not a new problem?

Can you create a freeze report by pressing Ctrl+Alt+Shift+Break/Pause in the situation where the hang occurs? After having pressed the keys, a few seconds later hopefully a freeze report will appear on your desktop. If that doesn't work, let me know.

About judder: Please show a screenshot of the Ctrl+J OSD while the judder occurs.

I try to optimize my custom modes, but I have all the HZ (23p,24p,25p,ecc,60p) in standard mode, unknown timing details.
How i can Optimize those mode?
The optimize button don't appear.
You need to "edit" each mode first to assign known timings.

I got 71.928 hz running! I added 71 hz, ran a test video for 35 minutes, applied optimized pixel clock #1 (compatibility 75), repeated for 35 minutes, and went with optimized pixel clock #1 again, which was now finer tuned (compatibility 80).
Nice! Please also test for smoothness. Some displays accept 71Hz, but internally still draw at 60Hz, which will produce visible judder.

I'm finally back in the game with a new video card upgrade. I got a 1060 a few weeks ago and started upping my quality settings in madvr and I have to say the last year or so of development has been tremendous. Well done to madshi and Nev. I like this dx11 decoding, too. SWEET! For me with the latest nVidia drivers, I can use 3D in windowed mode (FINALLY...my 680 never allowed it) no problem. NGU is really awesome. i see the scaling has improved a lot. I'm doing DVD to 1080p (still rocking my Panasonic plasma 1080p for now) and it looks as good as a blu-ray. Very pleased!
:)

I spoke too soon, I was able to reproduce it after all. It might be something to do with a "fresh" custom resolution, it seems to only happen the first time I use new timings with a custom resolution. :confused:
madVR - log.txt (https://www.mediafire.com/file/bdy61e0la9gf0ew/madVR%20-%20log.7z)
What is this log for exactly? I can't see the decoder even trying to activate D3D11 DXVA decoding?

Sure, but how do I generate a debug log?
Double click "activate debug mode.bat", then reproduce the problem, then stop the media player, then zip the "madVR - log.txt" file on your desktop and upload it somewhere and link to it here. Then double click "activate release mode.bat".

The new .2 update adds the custom resolutions to my TV's connected via AVR. It also now shows the custom resolution tab for the monitor we talked about before where it was missing (we discovered BAD_EDID in registry). However I think its incorrect and actually showing custom resolution settings for one of my TV's connected via AVR and not the monitor.
Known bug in v0.92.2, will be fixed in the next build.

I don't know exactly why but I failed to have measurement with my htpc though I succeed on my desktop PC. I tried several time and in several way (play a video file loaded before to click on optimize, load a new video file after and play it,...). Each time, no measurements found in the custom rate screen. So far, I tried to have measurement for 1080/23p on my htpc and get the ones for 1200/59p on my desktop PC.

I use the pretty same software config between my two PC (last official MPC-HC version - i tried in 32 or 64 bit version - , last offcial lavfilter version, internal audio renderer and nothing else). The only differences are hardware/drivers and especially GPU (Nano Fury with 17.7.2 on my htpc and a quite old Radeon 7900 with 16.40 drivers - yeah, I should update - on my desktop pc)

I should do something wrong but I don't find what. Anyone have an idea?
Does your HTPC have a single or dual monitor setup?

[Siso]

Do you have 2 monitors or just one? There's a bug in v0.92.2 which always uses the EDID of the first monitor.

Only one monitor, madshi.

[madshi]

You can paste the raw EDID data from the madVR settings dialog here to check if madVR has interpreted the native resolution of your display correctly:

http://www.edidreader.com/