madVR - high quality video renderer (GPU assisted)

[madshi]

I finally found something on youtube.
So from what i understand i am supposed to disable everything in internal filters and hevc-h264 in transform filters is that correct?
You need to make sure that you're using a recent LAV Video Decoder version. How you can achieve that with the media player of your choice is a question that should be addressed in the suitable media player thread, not here. But anyway, if HDR already activated for you then that part seems to be already working, so problem solved.

Hdr activates now when i launch an hdr movie but i expected more vibrant colors, not sure everything is working properly.
Did you do what I suggested, e.g. set your GPU to RGB Full (0-255)?

I asked a lot about the 576 to 1080p but not the 1080p to 1080p
It is more impotent color upscaling, on image upscaling the filters have no effect
When you watch 1080 video on a 1080 display in fullscreen, no image scaling is needed, only chroma upscaling, so just use a chroma upscaling option that looks best to you.
try NGU AA or super xbr for chroma. the depends a lot on your screen too.
^

Madshi if I use ffdshow raw I will never be able to use your hdr options? I love the denoise options of ffdshow.
The direct communication between LAV Video Decoder and madVR will be broken, which means that HDR specific information will not reach madVR because ffdshow doesn't forward them. It might still be possible to make HDR playback work somehow, I don't know. Haven't investigated that.

Hmm, for unknown reasons with ver. 0.92.1 i can get ONLY 8bit FSE - at least that's what is OSD showing (and no HDR content is automatically recognized by TV as HDR with "let madVR decide" (FYI - TV recognizes and announces HDR, HDR10, DolbyVision))...

With ver. 0.91.11 I can get 10bit FSE (but result is the same - no HDR content is automatically recognized by TV as HDR with "passthrough HDR content ... + send HDR metadata checked ...").
Oh well, yes, you're right, that's a bug in v0.92.1 in older OSs. Please retry with v0.92.2, thanks.

Thanks for confirming, unfortunately that's the behaviour to be expected from an HD7xxx GPU, which means no metadata makes it to the display.
It's not really confirmed yet, because of the bug that madVR only uses 8bit FSE mode in win8.1 atm, which means that dynamic HDR switching cannot work, regardless of which AMD GPU model is used, because AMD HDR switching only works with 10bit.

Given that it looks like I can't help with my old 7870, you might want to ask in the Linker, Integral (and 2015-2017 JVCs as many JVC users have purchased either of these) threads on AVS for MadVR users of the Linker/Integral with a recent AMD supporting HDR to provide the feedback you need. Although these older devices don't have an OSD like the Vertex, they have the same ability to capture the HDR metadata (from the Windows GUI), so they could provide the same information I did (just the raw HEX, not decoded). Off the top of my head, I think at least Javs and Zombie10K are MadVR users, but whether they use Nvidia or AMD I couldn't say. Most of them are probably on nVidia, but you could get lucky. If you find a candidate using MadVR+HDR capable AMD+Linker or Integral and if they don't know how to capture the HDR metadata, feel free to suggest they PM me at AVS and I'll tell them what to do, it's very straightforward. If you'd like me to ask on your behalf, I'm happy to do that too.
I don't know if it's worth the effort. Either it's working correctly or not. If it's not working correctly, I don't have an AMD contact to report the problem to, anyway. I've done my part. Whether or not the AMD drivers behave correctly is out of my hands.

Of course it would be nice to know, but I'm not really eager to go fishing for users to test this, only for informational purposes.

Switch HDR off in the OS, and don't use FSE unless you need to, it's not necessary anymore for HDR 10bits.
FWIW, this only works in win10. In older OSs fullscreen windowed mode is still limited to 8bit, and will always be.

About the display mode switcher, there's something wrong (to me), but it has nothing to do with new custom resolution tool, it was already here before 0.92.
Upload a debug log, then I can have a look.

[madshi]

madVR v0.92.2 released

http://madshi.net/madVR.zip

* fixed: possible crash when stopping playback or freeing the madVR instance
* fixed: DXVA2 decoding+downscaling produced wrong colors with HDR content
* fixed: D3D11 DXVA decoding: crash when moving window to another monitor
* fixed: D3D11 DXVA decoding: green screen with DX10 GPUs
* fixed: D3D11 DXVA decoding: problems if video unexpectedly changes size
* fixed: D3D11 DXVA decoding: detection for bad HDR metadata wasn't working
* fixed: custom modes tab didn't show for AVR devices
* fixed: custom modes tab didn't show when display modes was in a profile
* fixed: D3D11 FSE mode was sometimes limited to 8bit instead of 10bit
* fixed: HDR "let madVR decide" setting misbehaved for Intel GPUs
* fixed: HDR metadata sent to display wasn't always correct
* fixed: "HDR" profile bool was not set if HDR metadata was bad/unknown
* fixed: some settings windows appeared behind a "always on top" media player
* added support for sending MaxCLL/FALL HDR metadata (if available) to the TV
* added "enable nvidia 3d.reg" to enable 3D playback with newer Nvidia drivers
* if video HDR metadata is bad/missing, default HDR metadata is sent to TV now
* when custom mode is deleted, measurements are now also deleted
* Nvidia "try custom mode" timeout increased to 30 seconds
Nothing fancy, just many bug fixes and small improvements. Funny enough, DXVA2 decoding of HDR content suddenly works on my AMD RX 560, not sure why.

Next version will address some wishes asked by media player devs, and an HDR update for madTPG.

[Manni]

It's not really confirmed yet, because of the bug that madVR only uses 8bit FSE mode in win8.1 atm, which means that dynamic HDR switching cannot work, regardless of which AMD GPU model is used, because AMD HDR switching only works with 10bit.

Thanks, I wasn't aware of this bug as I haven't used 8.1 for ages. :o


I don't know if it's worth the effort. Either it's working correctly or not. If it's not working correctly, I don't have an AMD contact to report the problem to, anyway. I've done my part. Whether or not the AMD drivers behave correctly is out of my hands.

Of course it would be nice to know, but I'm not really eager to go fishing for users to test this, only for informational purposes.


Sorry, I misunderstood and was only trying to help, I thought you were keen to find out. Personally, I have absolutely zero interest in AMD now that I have my 1080 Ti, so happy to drop that one guilt-free. :)


FWIW, this only works in win10. In older OSs fullscreen windowed mode is still limited to 8bit, and will always be.


Thanks for clarifying, the part of my statement about FSE could indeed be read as if it was relevant for all OSes.

[pirlouy]

I don't understand. You said your list was "1080p30, 1080p60".
Cause I did not plan on detailing all the modes.

[mogli]

0.92.2 crashes when I open my image upscaling profiles settings. Message can be clicked away though and madVR plays just fine. Probably just need to delete and redo my settings but I'm too lazy doing that today.

[madshi]

0.92.2 crashes when I open my image upscaling profiles settings. Message can be clicked away though and madVR plays just fine. Probably just need to delete and redo my settings but I'm too lazy doing that today.
Does this one fix it?

http://madshi.net/madHcCtrl922.zip

[Skwelcha]

Does this one fix it?

http://madshi.net/madHcCtrl922.zip

I had the same issue, this fixed it for me.

[Sarlaith]

madVR v0.92.2 released

http://madshi.net/madVR.zip

* fixed: possible crash when stopping playback or freeing the madVR instance
* fixed: DXVA2 decoding+downscaling produced wrong colors with HDR content
* fixed: D3D11 DXVA decoding: crash when moving window to another monitor
* fixed: D3D11 DXVA decoding: green screen with DX10 GPUs
* fixed: D3D11 DXVA decoding: problems if video unexpectedly changes size
* fixed: D3D11 DXVA decoding: detection for bad HDR metadata wasn't working
* fixed: custom modes tab didn't show for AVR devices
* fixed: custom modes tab didn't show when display modes was in a profile
* fixed: D3D11 FSE mode was sometimes limited to 8bit instead of 10bit
* fixed: HDR "let madVR decide" setting misbehaved for Intel GPUs
* fixed: HDR metadata sent to display wasn't always correct
* fixed: "HDR" profile bool was not set if HDR metadata was bad/unknown
* fixed: some settings windows appeared behind a "always on top" media player
* added support for sending MaxCLL/FALL HDR metadata (if available) to the TV
* added "enable nvidia 3d.reg" to enable 3D playback with newer Nvidia drivers
* if video HDR metadata is bad/missing, default HDR metadata is sent to TV now
* when custom mode is deleted, measurements are now also deleted
* Nvidia "try custom mode" timeout increased to 30 seconds
Nothing fancy, just many bug fixes and small improvements. Funny enough, DXVA2 decoding of HDR content suddenly works on my AMD RX 560, not sure why.

Next version will address some wishes asked by media player devs, and an HDR update for madTPG.

Nice work!
I actually see the custom modes with my AVR set as AVR.
Quick question tho, my Samsung KS7000 has all modes as standard. (Timing details unknown)
How do I go about optimising it? I cant seem to click optimise. (Greyed out)

[madshi]

Nice work!
I actually see the custom modes with my AVR set as AVR.
Quick question tho, my Samsung KS7000 has all modes as standard. (Timing details unknown)
How do I go about optimising it? I cant seem to click optimise. (Greyed out)
You need to assign known timings first by pressing "edit".

[Sarlaith]

Ah I found it! Change pixel clock by 0.01 and then it shows up:)
Thanks! (Should have Just tested that-,-)

[aufkrawall]

I can confirm that the green screen issue for D3D11VA native on a GeForce 9600 GT is gone, and so is the problem with HEVC 10 bit + DXVA2 scaling on GTX 1070.
Somehow also my presentation glitches at playback start have disappeared completely (new driver, LAV Filters nightly and madVR version...).
All looking very stable and polished.

Can you give a raw estimate when D3D11VA scaling and deinterlacing might occur?

[madshi]

Ah I found it! Change pixel clock by 0.01 and then it shows up:)
Thanks! (Should have Just tested that-,-)
You wouldn't have to change anything at all, just apply the EDID settings. Anyway, doesn't matter...

[cyberscott]

Does this one fix it?

http://madshi.net/madHcCtrl922.zip

I had the crash as well and this one fixed it for me, too. :thanks:

[StinDaWg]

I am using the latest version of madVR and MPC-HC nightly. When using D3D11 FSE on a 23.976 video, the vsync says 41.72ms instead of 41.71. This throws the render time off and there is a dropped frame every few minutes.

If I use D3D11 windowed mode then it goes back to 41.71ms with dropped frame after hours/days.

This just happened recently. Bug? I'm using GTX 960 on latest drivers.

[Manni]

madVR v0.92.2 released

http://madshi.net/madVR.zip


* fixed: custom modes tab didn't show for AVR devices
* fixed: HDR metadata sent to display wasn't always correct
* added support for sending MaxCLL/FALL HDR metadata (if available) to the TV
* when custom mode is deleted, measurements are now also deleted
* Nvidia "try custom mode" timeout increased to 30 seconds


Nice work! I can confirm that the above in bold are fixed here. :)

All the metadata (when present) is now correct, including MaxCLL/FALL and mastering display primaries/white point (at least on my rig, details in sig).

Thanks for increasing the timeout to 30 secs, that leaves about 10 secs on my JVC once it's synced to see the results, which is plenty.

I don't think that the reg file you've added for 3D on nVidia is enough. It might help, but it won't stick. Unfortunately, it looks like we need to use the nVidia utility before each 3D playback if we want to be sure the display switched to 1080pFP when needed. At least that's the behavior here. I tried to do it at every reboot, and that wasn't enough. That's why I enable both keys in the registry and launch the nVidia utility to enable 3D before playback (at the same time I switch my display to its 3D mode). Unless you've added something to MadVR's code beyond the registry file, 3D cannot be enabled in registry, you need the utility to do so. Otherwise most of the time you end up with 1080p2D on playback as the registry key have been reset. It's not because it works once that it will work every time, especially after a reboot or a change of (non-3D related) settings in the control panel.

I'm not sure that in passthrough mode we want MadVR to change any of the metadata, so I would personally suggest to leave bad metadata as it is (untouched) in that mode so that we can actually know what's in the source file, unless you display the actual data in the OSD. Of course in "Let MADVR decide" or any other mode, it's fine, but in pass through, I'd rather have true pass through, warts and all, or at least an option for "true pass-through" :). If we want a fix, we can always select "Let MadVR decide" and have the bad metadata corrected.


Next version will address some wishes asked by media player devs, and an HDR update for madTPG.

Looking forward to HDR support in MadTPG. :)

[Sarlaith]

You wouldn't have to change anything at all, just apply the EDID settings. Anyway, doesn't matter...

Actually I had to, the EDID settings gave me the Nvidia driver Did not accept the new resolution warning.
By offsetting the pixel clock by 0.01 it accepted the resolution :)

[foozoor]

@madshi
- Is madVR using compute shaders?
- Are you going to use them to make your algorithms faster?

[zipeldiablo]

You need to make sure that you're using a recent LAV Video Decoder version. How you can achieve that with the media player of your choice is a question that should be addressed in the suitable media player thread, not here. But anyway, if HDR already activated for you then that part seems to be already working, so problem solved.

Did you do what I suggested, e.g. set your GPU to RGB Full (0-255)?



That's silly mate, we are using three different tools, if they think like this on every topic no one is getting anywhere :D
Hdr solved indeed.

Yup it was already set to rgb full, but i am quite disappointed by the colors.
I don't know if it is supposed to be like this or if i expect too much.
Since i don't have any other hardware that can send hdr content to my tv screen i am stuck.
Subtitles are quite bright though, too much if you ask me :o

Is there a documentation on the different upscaling doubling methods of madvr?
Would like to know how to find out what is the best option.

[madshi]

I am using the latest version of madVR and MPC-HC nightly. When using D3D11 FSE on a 23.976 video, the vsync says 41.72ms instead of 41.71. This throws the render time off and there is a dropped frame every few minutes.

If I use D3D11 windowed mode then it goes back to 41.71ms with dropped frame after hours/days.

This just happened recently. Bug? I'm using GTX 960 on latest drivers.
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?

All the metadata (when present) is now correct, including MaxCLL/FALL and mastering display primaries/white point (at least on my rig, details in sig).
Good to hear!

I don't think that the reg file you've added for 3D on nVidia is enough. It might help, but it won't stick. Unfortunately, it looks like we need to use the nVidia utility before each 3D playback if we want to be sure the display switched to 1080pFP when needed. At least that's the behavior here. I tried to do it at every reboot, and that wasn't enough. That's why I enable both keys in the registry and launch the nVidia utility to enable 3D before playback (at the same time I switch my display to its 3D mode). Unless you've added something to MadVR's code beyond the registry file, 3D cannot be enabled in registry, you need the utility to do so. Otherwise most of the time you end up with 1080p2D on playback as the registry key have been reset. It's not because it works once that it will work every time, especially after a reboot or a change of (non-3D related) settings in the control panel.
I haven't tried rebooting, but after executing that reg file, 3D playback works for me just fine, by enabling 3D support via the OS control panel 3D control. If I enable/disable 3D support via OS control panel, this also enables/disables 3D support in the Nvidia control panel, and vice versa. And 3D works fine if it's activated. So everything seems to work great here, after having executed that reg file.

Anyway, the reg file needs to change HKLM, and madVR normally doesn't have write access to it, so it's not something that madVR can automatically do for you. So offering the reg file is the best I can do, short of installing a service which does nothing but change these registry keys on PC boot, which sounds like overkill to me.

I'm not sure that in passthrough mode we want MadVR to change any of the metadata, so I would personally suggest to leave bad metadata as it is (untouched) in that mode so that we can actually know what's in the source file, unless you display the actual data in the OSD.
This is not as easy as it sounds. When LAV reports "bad" metadata, I don't even know if the metadata is bad or missing, and I also don't know if the GPU will output such metadata untouched or if it would try to repair it somehow. Furthermore I don't know how an UHD Blu-Ray player would handle the situation. Different players might even handle it differently. This is much too complex for my taste. I don't think we need to go to extreme lengths to try to passthrough bad information. I think sending some sort of default metadata instead is the better solution.

Actually I had to, the EDID settings gave me the Nvidia driver Did not accept the new resolution warning.
By offsetting the pixel clock by 0.01 it accepted the resolution :)
Interesting!!

- Is madVR using compute shaders?
- Are you going to use them to make your algorithms faster?
Yes, I'm using compute shaders, but currently only very very few of them, and not mainly for speed reasons. I will probably work on speed improvements at some point in the future. But my first priority is to make madVR feature complete. Making everything prettier and faster is a secondary priority atm.

[nevcairiel]

This is not as easy as it sounds. When LAV reports "bad" metadata, I don't even know if the metadata is bad or missing, and I also don't know if the GPU will output such metadata untouched or if it would try to repair it somehow. Furthermore I don't know how an UHD Blu-Ray player would handle the situation. Different players might even handle it differently. This is much too complex for my taste. I don't think we need to go to extreme lengths to try to passthrough bad information. I think sending some sort of default metadata instead is the better solution.

To add to that, the "bad" metadata isn't "maybe bad", its quite obviously bad and under no circumstances or interpretation would it be valid. There is literally no value to use that data.

More often this would likely be "missing metadata" anyway, I still don't know of any other file then the Sony HDR Camp thing which had this broken metadata.

[Manni]

@Madshi, I tried the three files I had initially tested for the HDR Metadata (Exodus, Neo Fire and RM Brightness), and for some reason the RM Brightness file doesn't play (black screen or whatever the last frame was in window) in full screen. It only plays in a window. Both the MP4 and the MKV versions do the same. It does the same in my default windowed full screen mode or in FSE.

All the others files play fine, and display the correct metadata. Do you have any idea if a recent change in the code could have caused that? I tried to install the latest LAV nightly and that doesn't make a difference. I also tried to install the two files from the test build, same results (but I had only played Exodus with these files). If you have access to the RM Calibration files you might want to test and make sure it's not only here.

[Manni]

This is not as easy as it sounds. When LAV reports "bad" metadata, I don't even know if the metadata is bad or missing, and I also don't know if the GPU will output such metadata untouched or if it would try to repair it somehow. Furthermore I don't know how an UHD Blu-Ray player would handle the situation. Different players might even handle it differently. This is much too complex for my taste. I don't think we need to go to extreme lengths to try to passthrough bad information. I think sending some sort of default metadata instead is the better solution.


To add to that, the "bad" metadata isn't "maybe bad", its quite obviously bad and under no circumstances or interpretation would it be valid. There is literally no value to use that data.

More often this would likely be "missing metadata" anyway, I still don't know of any other file then the Sony HDR Camp thing which had this broken metadata.

It depends what you call bad metadata. For example, when playing UHD Bluray, a few of them report no metadata such as Life of Pi, which has all metadata set to zero. When I want to know what's on the source, I want to know what's on the source. If some metadata says "zero", I want to know it says "zero". I don't want a software to replace these values with defaults values, and then me having no idea whether what the GPU reports are true values, or default values that do not in any way give an idea about the way content was mastered.

If you're talking about different "bad metadata", then let us know what you have in mind.

As far as I'm concerned, I want to know exactly what's reported by the source so that I can make the best decision regarding calibration and playback. If I want someone else to make these decisions for me, then I ask "Let MadVR decide".

If you don't want to have a passthrough mode, that's fine, but then don't call it pass through, or provide a proper passthrough mode, or provide the raw metadata in the OSD.

I can confirm that when the metadata is as above, or when some fields such as MaxCLL/MaxFALL are not populated while the others are, a standalone player doesn't make any attempt to "fix" it or improve it. It just passes it through as it is. This is GOOD because I know I can't rely on the metadata. Many displays are not reading metadata anyway, so until they all do their job properly, we have to know what the data is (preferably).

Again, this would be fine if there was a way to access the actual metadata, for example on the OSD, but that's not the case at the moment.

Of course, if the OS/GPU changes that metadata behind your back, then there is nothing you can do, but it doesn't seem to be the case at the moment (at least for MaxCLL/MaxFALL).

[nevcairiel]

As far as I'm concerned, I want to know exactly what's reported by the source so that I can make the best decision regarding calibration and playback. If I want someone else to make these decisions for me, then I ask "Let MadVR decide".

If you don't want to have a passthrough mode, that's fine, but then don't call it passthrough, or provide a proper passthrough mode.

It makes no sense to passthrough obviously invalid data, though, because there is no value to be gained from this. Worst case you need a special button to "disable" that on the fly so it plays properly on a picky device, which is a terrible user-experience.

If you want to know what exactly is in the file, you should get a stream analyzer, not a player.

PS:
If you just want to know if the data from the file is "valid", madVR should say "unknown properties" in the OSD if its discarding invalid data, so you can know if its sending defaults instead of actual file data, anyway.

[Manni]

It makes no sense to passthrough obviously invalid data, though, because there is no value to be gained from this. Worst case you need a special button to "disable" that on the fly so it plays properly, which is a terrible user-experience.

If you want to know what exactly is in the file, you should get a stream analyzer, not a player.

PS:
If you just want to know if the data from the file is "valid", madVR should say "unknown properties" in the OSD if its discarding invalid data, so you can know if its sending defaults instead of actual file data, anyway.

What do you call invalid data? Data that's out of range? Or data that's only zero?

Again, if all displays were interpreting and reacting to metadata properly, it would be different, but many displays don't.

The minimum would be indeed to have an indicator saying which data is changed.

You don't need a stream analyser to get this information, the Vertex or the Linker/Integral do that fine, but there is nothing they can do if the software replaces data as it sees fit.

Anyway, all this doesn't really matter as we can't yet play our UHD Blurays with LAV/MadVR, but until displays properly handle metadata (and again, many of them don't, they simply detect HDR metadata is sent and they switch to a fixed HDR mode that doesn't take into account the provided metadata), then it's not helpful to have no way to know the actual metadata of the content, especially if it's not clear that it's been manipulated.

[Sebastiii]

Thanks :)

[nevcairiel]

What do you call invalid data? Data that's out of range? Or data that's only zero?

It can't really go out of range, the values in the bitstream have a fixed size of bits they can fill, there just isn't any more room.
Mostly this is zero metadata, or invalid values very close to zero (I believe the Sony HDR thing has a value of 0.5 Nits in the metadata, on top of having zeros for the whitepoint)

madshi posted his invalid check a few pages back, it mostly just checks for zeros in some of the fields - in which case he discards all of it.


You don't need a stream analyser to get this information, the Vertex or the Linker/Integral do that fine, but there is nothing they can do if the software replaces data as it sees fit.


A stream analyzer is the only way to be sure you get the real data, though, and its (potentially free) software, not some expensive hardware thing that 99.9% of all people won't have.

[Manni]

It can't really go out of range, the values in the bitstream have a fixed size of bits they can fill, there just isn't any more room.
Mostly this is zero metadata, or invalid values very close to zero (I believe the Sony HDR thing has a value of 0.5 Nits in the metadata, on top of having zeros for the whitepoint)

madshi posted his invalid check a few pages back, it mostly just checks for zeros in some of the fields - in which case he discards all of it.



A stream analyzer is the only way to be sure you get the real data, though, and its (potentially free) software, not some expensive hardware thing that 99.9% of all people won't have.

I am talking about a tool that tells you what the metadata is in real-time, on-the-fly, when the file plays.

If MadVR was displaying this information in the OSD, we wouldn't be having this discussion.

Because it doesn't, the only way to see the metadata as it's playing - and make for example decisions regarding which calibration preset to use - is to rely on the metadata sent out by the GPU.

As it stands, there is no way to get to this information if the software manipulates it for whatever reason it sees fit.

Discarding all the information because a few fields are not correctly populated isn't ideal either (I can't find Madshi's post so don't know his method).

Anyway, I guess you don't calibrate, or don't have a display that doesn't care about the metadata (i.e. behaves the same way irrespective of what the metadata actually is), otherwise you'd see my point.

I'm only saying that with a standalone player, we can get this metadata as it is and make our own decisions, while with MadVR/LAV we can't unless a proper passthrough mode ("real passthrough" or "native passthrough") is offered or the native metadata (before manipulation) is displayed on the OSD.

I'm not going to fight about this if you feel so strongly about not providing the original information, I just hope that by the time we can play legitimate HDR content on a HTPC the displays will always react to metadata appropriately and provide an accurate/optimal picture. It is NOT the case today with HDR10, far from it. It is the case with Dolby Vision, and might be the case with HDR10+, but we're not there yet.

So I would share your position in theory, in an ideal world where everyone would know what the standard is, would implement it properly and would respect it (which is what happens with Dolby Vision), but in practice, as the market is today with many of the HDR displays in use (especially projectors) and the way content is mastered, having no way to know the actual HDR10 metadata in passthrough mode is not really helpful for those who can do better than the manufacturer's (often poor at this stage) implementation.

[FDisk80]

Nothing fancy.

Yes it is. :) Hope this fixes the refresh rate change crashes with D3D11 DXVA. Will test tomorrow.

[el Filou]

I've never heard of native 30 fps content. The only thing I know is 29.97 NTSC, which is interlaced or telecined, so either 24p or 60p. What content would be native 30p?
Interlacing is a key problem here, with at least most "30p" content being interlaced, using a 30p mode would not allow proper deinterlacing, as that would result in 60 fps.A lot of YouTube content is 30p, for example.
I admit most YouTube content isn't of very high video quality, but there is also the case where broadcast providers have gotten used to converting their 50/59 i/p material to 30p (example: IndyCar posts full races on YouTube in 30p).

[jeryll]

Oh well, yes, you're right, that's a bug in v0.92.1 in older OSs. Please retry with v0.92.2, thanks.

Thanks for the new version! Now I can get 10bit FSE with newest madVR. But the result is the same, no HDR content is automatically recognized by TV as HDR with "let madVR decide"...

[70MM]

first of disabling deinterlancing (unticking it) is generally not a good idea.
.
huhn I hope the two images work for you...
Ive ticked deinterlacing for both 480 DVD and 576 DVD, below is the results. Massive repeated frames for 480 material, 576 looks ok. 1080Ti card everything upscaled to 4K. BD is perfect, my issues are just with DVD...

480 DVD USA
https://snag.gy/IqAokC.jpg

576 DVD UK
https://snag.gy/trQBKf.jpg

[Anleck]

Tried a 59.940 fps profile?

[mogli]

@70MM
Your settings are too taxing for 480p@29i. Lower them.

Just add up the numbers for average stats (or max stats) and compare them with the frame number above. Average stats should be generally quite a bit lower than this number (max stats are fine to exceed it only in rare cases).

That's true for your PAL example but not for NTSC.

[70MM]

Im not sure which settings to lower sorry..

I removed doubling to image upscaling bilinear and chroma upscaling to bicubic60 and still in in the thousands of repeated frames for 480 DVD.
Average states dxva 2.50
rendering 7.26
present 0.25

[Asmodian]

That's sad to hear. Your TV seems to be very picky. What model is that? It should at least accept changes to the pixel clock, right? Does it dislike both horizontal and vertical back porch changes, or is just one of those problematic? What happens if you change front porch or sync width?

I was finally able to test this. It is LG's 2017 OLED TV, the 55" C7P.

I can change the pixel clock as expected as well as the horizontal sync width, the vertical front porch, sync width, and back porch. It is only the horizontal porches that cause my TV to freak out, I get bad colors or no image. The bad colors looks similar to what happens when I manage to get the TV to enable Dolby Vision mode while sending it 8-bit data (HDR video games at 60Hz).

I think this was only caused by being in 12-bit RGB, changing to 8-bit allows me to adjust everything without any issues. Oddly the custom modes do not let me set them to 12-bit in the control panel but if I am already in a 12-bit mode the GPU does output 12-bit (or at least 10-bit) when madVR switches to it. However, I am usually in an 8-bit mode before the switch in which case it stays 8-bit.

I am really enjoying the new version, HDR seems fully functional on my system (not that I have any HDR content) and the custom modes are great fun. :)

While testing DX11 native decoding I did encounter an issue with DXVA2 native decoding in general (both DX11 and DX9) when used with refresh rate changing. When madVR changes the refresh rate LAV falls back to software decoding. I use software or copyback anyway but I found it odd.

:thanks:

[david555]

Big thanks Madshi! With the customs mode, bye bye drop frame in bitstream.

You're the best!!!

Again, many thanks.

(No need exclusive mode to have 10bit with nightly lav d3d11, is it normal?)

[madshi]

@Madshi, I tried the three files I had initially tested for the HDR Metadata (Exodus, Neo Fire and RM Brightness), and for some reason the RM Brightness file doesn't play (black screen or whatever the last frame was in window) in full screen. It only plays in a window.
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.

If MadVR was displaying this information in the OSD, we wouldn't be having this discussion.
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.

Thanks for the new version! Now I can get 10bit FSE with newest madVR. But the result is the same, no HDR content is automatically recognized by TV as HDR with "let madVR decide"...
So that most probably means only Polaris (and newer) will support HDR passthrough. It was probably to be expected, but a bit sad...

I was finally able to test this. It is LG's 2017 OLED TV, the 55" C7P.

I can change the pixel clock as expected as well as the horizontal sync width, the vertical front porch, sync width, and back porch. It is only the horizontal porches that cause my TV to freak out, I get bad colors or no image. The bad colors looks similar to what happens when I manage to get the TV to enable Dolby Vision mode while sending it 8-bit data (HDR video games at 60Hz).

I think this was only caused by being in 12-bit RGB, changing to 8-bit allows me to adjust everything without any issues.
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?

Oddly the custom modes do not let me set them to 12-bit in the control panel but if I am already in a 12-bit mode the GPU does output 12-bit (or at least 10-bit) when madVR switches to it. However, I am usually in an 8-bit mode before the switch in which case it stays 8-bit.
Strange. Please feel free to report this to Nvidia customer support. There's nothing I can do about it.

While testing DX11 native decoding I did encounter an issue with DXVA2 native decoding in general (both DX11 and DX9) when used with refresh rate changing. When madVR changes the refresh rate LAV falls back to software decoding. I use software or copyback anyway but I found it odd.
Can you provide more information on how to reproduce this?

No need exclusive mode to have 10bit with nightly lav d3d11, is it normal?
Not sure what you mean.

[petran79]

For quite a while I get this issue with Madvr. The OK button seems out of window border
Does it have to do with resolution?


https://abload.de/img/madvri9ruw.jpg

[FDisk80]

For quite a while I get this issue with Madvr. The OK button seems out of window border
Does it have to do with resolution?


I don't understand why this window needed at all, why not just open "Edit Settings" directly. The "Show Tray Icon" can be enabled and disabled from there.
Or am I missing something? :confused:

Edit: Oh, to check the "Pin Info" tab? I guess that's why. Maybe all that info can be moved to "Edit Settings" for quick easy access? The same as it's done in LAV.
Clicks can be saved :D

[el Filou]

Massive repeated frames for 480 material, 576 looks ok.
480 DVD USA
https://snag.gy/IqAokC.jpg
576 DVD UK
https://snag.gy/trQBKf.jpgThose are film, right? Film on DVD - if properly encoded - is supposed to be IVTC'd, not deinterlaced as with video.
With EVR, the GPU can do that ("Use inverse telecine"/"Pulldown detection" option in video settings) but I think madVR cannot use the GPU's IVTC (at least it doesn't work on my NVIDIA).

The easiest way to make sure your film DVDs - both NTSC and PAL -
are handled properly is to manually enable film mode:
1. Make sure to use copy-back or software decoding
2. Use Ctrl+Alt+Shift+T to cycle through deinterlace modes and set it to Film: https://snag.gy/U7bW2L.jpg

Edit: I can't test this with NTSC DVDs as I don't own any, sorry.

[a8213711]

Hey madshi can you check your PM? :o

[Jasch]

madVR v0.92.2 released

Nothing fancy, just many bug fixes and small improvements. Funny enough, DXVA2 decoding of HDR content suddenly works on my AMD RX 560, not sure why.


Hi Madshi can you plz share some info on your settings running RX460 with Hdr.
I´am trying since yesterday but not TV will not switch to HDR.

Info screen shows playback is fine.

[austinminton]

Autoswitching to HDR has stopped working in FSE with the latest madvr (0.92.2). This was working fine with the previous release (0.92.1). I have tried updating to the latest LAV nightly and nvidia drivers but no change. It works fine in non FSE mode.

Windows 10 creators update
GTX 1080 (385.41)
mpc-hc x64 (1.7.13)
Lav nightly 0.72.2-66(DXVA2 copyback)
madvr (0.92.2)

Please note that deleting 0.92.2 and going back to 0.92.1 instantly fixes the problem

Edit: I have tried both passthrough HDR and let madvr decide. Both work fine for 0.92.1 and neither works for 0.92.2.

[huhn]

Those are film, right? Film on DVD - if properly encoded - is supposed to be IVTC'd, not deinterlaced as with video.
With EVR, the GPU can do that ("Use inverse telecine"/"Pulldown detection" option in video settings) but I think madVR cannot use the GPU's IVTC (at least it doesn't work on my NVIDIA).

The easiest way to make sure your film DVDs - both NTSC and PAL -
are handled properly is to manually enable film mode:
1. Make sure to use copy-back or software decoding
2. Use Ctrl+Alt+Shift+T to cycle through deinterlace modes and set it to Film: https://snag.gy/U7bW2L.jpg

Edit: I can't test this with NTSC DVDs as I don't own any, sorry.

madVR is using the same deinterlancer as EVR if the GPU IVTC option is active madVR will use it too but it is not really doing an IVTC it is just going addional field matching and still outputting 60/50 hz

I don't understand why this window needed at all, why not just open "Edit Settings" directly. The "Show Tray Icon" can be enabled and disabled from there.
Or am I missing something? :confused:

Edit: Oh, to check the "Pin Info" tab? I guess that's why. Maybe all that info can be moved to "Edit Settings" for quick easy access? The same as it's done in LAV.
Clicks can be saved :D

the setting dialog is general the pin info is not it is for the currently running madVR instance/player.

[madshi]

For quite a while I get this issue with Madvr. The OK button seems out of window border
Does it have to do with resolution?
The window itself is coming from the media player, madVR just draws the "inside". On my PC the media player shows no "Help" button which means all buttons are visible. In any case, I think it's the media player's job to make sure that all the buttons drawn by the media player fit into the window, so I don't think it's my problem to fix.

Hey madshi can you check your PM? :o
Please use this thread to report problems. You can send me links via PM if that's really necessary, but I'm not providing support via PM. So unless you report your problem in this thread, I'm not going to do anything about it.

Hi Madshi can you plz share some info on your settings running RX460 with Hdr.
I´am trying since yesterday but not TV will not switch to HDR.
What is your OS? Do you have D3D11 presentation active? And your display set to 10bit? Please post a screenshot of the OSD (Ctrl+J) in fullscreen view. If you're using FSE mode, you probably will have to use your digicam to make a screenshot. Don't attach the image to this thread, please upload it somewhere else and then just link to it here.

Autoswitching to HDR has stopped working in FSE with the latest madvr (0.92.2). This was working fine with the previous release (0.92.1). I have tried updating to the latest LAV nightly and nvidia drivers but no change. It works fine in non FSE mode.
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.

[oddball]

Auto switching to HDR on my AMD RX 480 has never ever worked. I have to manually switch to HDR mode in Windows 10 display properties for the display, make sure FSE is disabled and click on the MadVR systray icon. If I hover over the MadVR systray icon it works for 10 seconds then goes back to washed out colors/brightness. Maybe I should make a video demonstrating this. BTW the LG OLED is display 3 in a 3 monitor setup. I will try making it the main display and disabling the other two to see if it makes any difference. I'll get back to you on that.

EDIT: Nope! Made no difference. I disconnected the two non-HDR capable displays and set the LG OLED as default display 1. Same problem. HDR does not auto switch. I have to toggle it in display properties. But when playing back HDR videos they are washed out. I have discovered that this is only in full screen mode though (Note: I don't mean full screen exclusive). If I make it fullscreen it goes washed out again. But if I move the mouse cursor to the bottom of the display so the playback controls appear it pops back into correct HDR mode again. Likewise if I make the player windowed it also plays HDR correctly.

Madshi. does this clue you in at all?

[har3inger]

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.

[FDisk80]

Ok, thanks. Both crash reports are basically identical. Will see what I can do with them.


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.

This freeze only happens with D3D11 Native mode.
If I select a hardware device and use D3D11 Copy Back the 3 second freeze goes away.

Or does it just kicks out of D3D11 DXVA mode when I manually select a hardware device?

LAV does say "d3d11 cb direct" but OSD doesn't say it.
Native mode does show (DXVA11) in OSD.

[AngelGraves13]

Thanks for the quick bug fix release. Everything is working fine on my end now. No more crashes or lockups of the media player with DX11 decoding.

[mickeekung]

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