madVR - high quality video renderer (GPU assisted)

[madshi]

Originally Posted by Damien147

Look what happens here.Notice the blue line on the bottom.I just clicked on the upscaling algo and it opened behind the window,not in front to choose.It seems that if I click on OK after clicking edit settings problem gets solved though.

That almost looks like an OS bug to me, but I'm not sure. Have never seen this effect myself yet.

Originally Posted by steakhutzeee

Nope, it's not tearing (at least i think). I disabled VSync but problem persist. I've no GSync/FreeSync.
I'm on fullscreen exclusive mode, i'm on an MSI R9 270X.

It's more like a "video interference" like when you have a phone near the monitor, don't know how to explain.

I solved this in games, (during night this was more evident) by switching monitor to 60 to 75 Hertz. I had it in the black bars in the movies too. But this solved it. But problem persists in video portion of screen.

It's something like this, i found it on youtube:

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

But it's more flebile than this.

Some thoughts on what this could be:

1) Maybe your HDMI cable is bad. Try a newer/better one.
2) Maybe your GPU's HDMI output is broken. Try a different output port.
3) Maybe all your GPU's output ports are broken, you could try a different GPU.
4) Maybe your TV is broken.

This problem does not seem to be madVR's fault, from what I can see.

Originally Posted by akim

Nice render thanks
1. When viewing the avi. (Lav - avcodec)
I would like to optimize memory consumption (reaches 500 MB) with the default settings
if possible.
2. When entering the full-screen mode and the output, the chip and memory frequency rises to a maximum (1000 Core - 1200 memory) for 10 seconds then falls to 300Mhz Core - 150Mhz Memory
Evr keeps the frequency always 300 - 150Mhz
Is it possible to correct this behavior?

Why are you worried about memory consumption or short term chip/memory frequency? These things are not really very important.

FWIW, chip/memory frequency probably rise for a short time when switching window size or entering full-screen because madVR has to re-render the internal queue, and it does so as fast as possible. I don't consider this behaviour a problem. It works as intended.

Originally Posted by Neo-XP

did you remove an anti-aliasing feature between v0.91.1 and v0.91.8 for NGU Sharp ?

Here is NGU Sharp high v0.91.1 VS v0.91.8 where this problem is very visible

Wasn't NGU Sharp "high" in v0.91.1 the same as "very high" in v0.91.8? If so, comparing this isn't very fair, considering that "very high" consumes 2.5 - 3x as much resources are "high".

Originally Posted by Neo-XP

This problem is less pronounced with NGU Sharp very high, again v0.91.1 VS v0.91.8 :



Is it possible to improve this ?

The source I used for the 4K upscaling :



It is extracted from this calibration video : http://www.mediafire.com/file/z65th6...alibration.mkv

Originally Posted by Neo-XP

v0.91.1 (NGU-med) / v0.91.7 (NGU Sharp high) / v0.91.8 (NGU Sharp high) :



Going back to v0.91.1...

Source extracted from http://www.mediafire.com/file/z65th6...alibration.mkv :



If you want to test it, you need to upscale it to 4K.

Will have to double check this, when I find some time. It's possible that the change to target middle ground between linear and gamma light produces this change. I'm not sure how much I can improve this. All the current NGU versions are in rough shape and will be further fine tuned in the future, but I don't expect dramatic improvements, just minor improvements.

Originally Posted by arrgh

3D "jumping" and MPC-BE freezing after stopping playback...

Hi, I have set up a small media PC with a Kaby Lake Intel i5 7200U and HD Graphics 620 in Win10x64...
to ensure whether the Setup works, I have basically used the madVr Defaults (like Cubic scaling), just to make sure it works in principal with MPC-BE...

after some trouble with MPC-BE due to lacking Admin rights (not able to wright its ini-file), 2D full HD works (on a FHD Screen; mkv-files);
but 3D does not. the TV is switched to 3D but the movie is constantly "jumping" back a few Frames "every second", so the Picture is very jerky; I have defined a hot-key for closing MPC-BE; if i use this, MPC-BE freezes (does not happen with 2D material); the only way to come out of this is to shut down the Computer;

here the statistics:
http://www.bilder-upload.eu/show.php...1492903440.jpg

can anyone give me a hint how to overcome this?
I think the statistics doesn't indicate that the Hardware is not able to do 3D-mkv...?

Unfortunaly 3D output requires D3D11, and for some users, using D3D11 with Intel GPUs results in this "jumping". I've not yet found a way to fix it, probably because I can't reproduce it on my old HD4000 GPU. I have a new Kaby Lake PC sitting around here, maybe I'll be able to reproduce it with that, then maybe there's hope to fix this, but I can't say for sure right now. FWIW, this problem does seem to be limited to Intel GPUs.

Originally Posted by tingtong5

Actually I am never able to make a screenshot when CTRL-J is enabled, since the screenshot will always be a black screen. But anyway, I made a picture ;-)

So the display is in 1080P50 and if I understand correctly from the CTRL-J information, madvr is still upscaling to 4K while it should not. Am I correct?

As you can see only about a quarter of the image is displayed on the display because of the unwanted upscaling from 1080P to 4K.

The media player seems to have its window sized at 3840x2160 pixels, for some reason. I don't think it's madVR's fault. Right now I'm not sure if there's anything I can do about it. You could try creating a debug log, with the Ctrl+J OSD turned on, then maybe I can say for sure which size the media player window has.

Originally Posted by DragonQ

Since I swapped out my R9 270 for an RX 480, I get loads of "presentation glitches", but no dropped or delayed frames and queues are all at maximum. Any settings not compatible with this kind of GPU that I need to check for? I'm not using GPU for decoding or anything and GPU usage is ~10% during playback according to MSI Afterburner. My monitor is set to 144 Hz, and smooth motion is enabled. I get the presentation glitches constantly when I have MPC-HC in a window (even when the video is paused) but they only seem to appear if I activate/hover over the UI when in fullscreen mode.

144 Hz with smooth motion FRC is pretty difficult for windowed mode. I'm surprised you had no presentation glitches with your R9 270. This is what fullscreen exclusive mode is made for.

Originally Posted by tingtong5

When trying to skip 30 seconds or 10 minutes while playing 4K H265 files in Kodi Dsplayer 16.1 sometimes the screen turnes completely WHITE. Is this a known issue in Madvr? Or maybe its a Kodi issue? Video is still playing cause I still hear sound.

I don't think it's a madVR issue.

[Neo-XP]

Originally Posted by madshi

Wasn't NGU Sharp "high" in v0.91.1 the same as "very high" in v0.91.8? If so, comparing this isn't very fair, considering that "very high" consumes 2.5 - 3x as much resources are "high".

I tested "NGU-med" (v0.91.1) VS "NGU Sharp high" (v0.91.8) of course, and "NGU-high" (v0.91.1) VS "NGU Sharp very high" (v0.91.8).

Originally Posted by madshi

Will have to double check this, when I find some time. It's possible that the change to target middle ground between linear and gamma light produces this change. I'm not sure how much I can improve this. All the current NGU versions are in rough shape and will be further fine tuned in the future, but I don't expect dramatic improvements, just minor improvements.

The new version adds a lot of unwanted aliasing that is visible to the naked eye (that is how I detected it in the first place).
If the new target produces this change, it should at least be possible to add an option to disable it (scale in gamma light ?).

[madshi]

madVR v0.91.9 released

http://madshi.net/madVR.zip

* added support for sending HDR metadata via Nvidia's private API
* added support for sending HDR metadata via win10 (not tested yet)
* fixed: processing (not converting) HDR was not handling gamut correctly

This is just a quick release with HDR metadata support. Nothing else has changed. For Nvidia users I recommend using the private Nvidia API to send the metadata. This API has several advantages:

1) It works in all OSs starting with Windows 7 (I think).
2) It works with both D3D9 and D3D11.
3) It's true "passthrough", the GPU driver doesn't modify the HDR pixels.

BUT: It only works for Nvidia GPUs and requires a fairly recent GPU driver version.

AMD/Intel users will have to use the new Windows 10 HDR APIs. I've implemented support for these, too, but couldn't fully test them yet, so they may work, or maybe not. Let me know. These APIs will probably behave differently compared to the Nvidia API. I'm not sure if they're true "passthrough". If they are, then probably only in fullscreen mode. These Windows 10 HDR APIs require the Creator's Update to be installed, and you need to activate "use D3D11 for presentation".

[jerryleungwh]

If I am using an external monitor, HDR passthrough only works if I have a HDMI2.0 supported port on my computer right?

[madshi]

You need a GPU which supports HDR output, in both hardware and drivers. That should be Pascal, Polaris and Kaby Lake. If you have an older GPU, you can still tell madVR to passthrough, but then you have to manually switch your TV into HDR mode.

[arrgh]

Originally Posted by madshi

Unfortunaly 3D output requires D3D11, and for some users, using D3D11 with Intel GPUs results in this "jumping". I've not yet found a way to fix it, probably because I can't reproduce it on my old HD4000 GPU. I have a new Kaby Lake PC sitting around here, maybe I'll be able to reproduce it with that, then maybe there's hope to fix this, but I can't say for sure right now. FWIW, this problem does seem to be limited to Intel GPUs.

that is very bad to hear... I actually hoped to get a small energy saving media machine which can manage the Basics (TV, BluRay, 3D-Bluray). That issue is really a Show stopper..!

I hope you can look into this soon...

[Q-the-STORM]

Originally Posted by madshi

madVR v0.91.9 released

http://madshi.net/madVR.zip

* added support for sending HDR metadata via Nvidia's private API
* added support for sending HDR metadata via win10 (not tested yet)
* fixed: processing (not converting) HDR was not handling gamut correctly

nice, this will be very useful once I upgrade my GPU.

Do both nvidia and win10 metadata transfer the entire metadata from the file (so correct levels of White Point, min/max luminance, maxfall, maxcll etc)?
Just triggering win10's HDR mode from display settings obviously couldn't set the correct metadata of the file you are playing (since win10 wouldn't be able to know it), but I assume you can set the correct values via API?

[madshi]

Both APIs support the full set. maxfall and maxcll are not in the SMPTE 2086 metadata set, though, IIRC, but somewhere in the video bitstream. I'm not setting those two, but the others are set correctly by madVR, of course.

All that said, many TVs seem to totally ignore the metadata atm (other than HDR on vs off).

[Q-the-STORM]

When the x265 encoding settings haven't been stripped, you can see maxCLL and maxFALL there, e.g. in mediainfo:

max-cll=1529,380

1529 is maxcll, 380 is maxfall

it's between master-display and min-luma

Maybe LAV could read those values and feed them to madVR?

Also, is there any way to display the HDR infoframe for a file, so people can set it in HDFury's integral or Linker (so people with old GPUs can set the correct infoframe)?

I have not found any program that can just display the infoframe for a file, you'd always have to calculate it. Since madVR is processing the values anyways, maybe you can display them somewhere?

[madshi]

madVR shows the HDR metadata in the OSD (Ctrl+J). I'm not sure if that's what you mean with "HDR infoframe"? Or do you mean the raw data? I'm not even getting that myself, it's read by ffmpeg, then transported to LAV, then transported to madVR, and probably converted several times in between.

I'm not sure if maxcll and maxfall are really needed to be sent to the display, but the APIs do support it.

@nevcairiel, what do you think? Worth implementing?

[nevcairiel]

Originally Posted by madshi

@nevcairiel, what do you think? Worth implementing?

I can add it to the data set, but I'm not sure how many samples actually set it. FFmpeg already got patches to read it recently, so not very complex to do that.

[Q-the-STORM]

We obviously don't know what exactly each display does with maxfall and maxcll.
When a frame is bright enough to trigger ABL on a display, the display will dim the image, now it would make sense that if maxFALL is high, a display that can't get that bright will use the metadata to simply be a bit dimmer at all times, so that the brightness will not suddenly have a big drop when average brightness of the frame is a lot higher than what the display can display. If the display compensates from the start, the image will be a bit darker over the whole movie, but in return, bright scenes can actually be brighter than dark scenes, because the display compensates from the beginning.

And maxCLL could be used to determine how to roll highlights, so if the display can only do 700nits highlights and maxCLL is 800. it needs to roll highlights a bit so that everything over 700nits is not "just" blown out, but blown out with a curve... if maxCLL is 1500, this curve would obviously be different, since the display can roll the highlights a bit differently, to retain some more detail there.

So maxCLL and maxFALL can be very important... "can"...

but that's just theory on my part, they might not do anything with it yet, or they do something entirely different... though I would really be surprised if "UltraHD Premium" certified TVs don't use maxCLL and maxFALL in some way...
so if it's not too hard to implement, I would definitely recommend it...

the HDR infoframe is basically all the values in hex send to the display, it's what triggers HDR mode and how the metadata is transfered.... it looks like this:

87:01:1A:A4:02:00:C2:33:C4:86:4C:1D:B8:0B:D0:84:80:3E:13:3D:42:40:E8:03:32:00:E8:03:90:01

(with the integral, the first 4 pairs are not there, since they are just some header data and CRC... they didn't use them to save some memory if I remember correctly. I assume you don't actually need the first 4 pairs, since there's no "actual" metadata. The Linker has them.)

so if you put this string in the integral/linker, it'll inject that in the HDMI stream and the display will get the metadata to process.

[madshi]

Originally Posted by nevcairiel

I can add it to the data set, but I'm not sure how many samples actually set it. FFmpeg already got patches to read it recently, so not very complex to do that.

Sounds good, so I'd say let's do it. Can we do it without breaking compatability? Maybe a new side data block? I'll leave the details to you. Thanks!

[nevcairiel]

Originally Posted by madshi

Sounds good, so I'd say let's do it. Can we do it without breaking compatability? Maybe a new side data block? I'll leave the details to you. Thanks!

I went with a new block for the same reasons:
https://github.com/Nevcairiel/LAVFil...f86d26217e12a3

Some of the test clips I have do even set it, and those claim to be UHD BD compatible encodes, so that sounds good, I guess.

[madshi]

Great - thank you!

[dioxholster]

I dont believe this is a madvr problem but its something that happened. can i know what this means? It showed up in every video, im guessing its because its reading from a bad drive but not sure:



Only audio played and display was black. My worry is that even though the source of the problem is a bad drive, it did cause madvr to behave strangely for subsequent videos. Its working now again but for a time, this is the error i had.

[Q-the-STORM]

Originally Posted by dioxholster

I dont believe this is a madvr problem but its something that happened. can i know what this means? It showed up in every video, im guessing its because its reading from a bad drive but not sure:



Only audio played and display was black. My worry is that even though the source of the problem is a bad drive, it did cause madvr to behave strangely for subsequent videos. Its working now again but for a time, this is the error i had.

someone had the same issue 2 weeks ago, reinstalling drivers fixed it (or try system restore point)

[ryrynz]

Originally Posted by Q-the-STORM

someone had the same issue 2 weeks ago, reinstalling drivers fixed it (or try system restore point)

You really don't need to quote an entire post let alone one with an image to simply reply to someone's post directly above yours.. Please don't.

Sent from my Nexus 5X using Tapatalk

[Flokke]

Does anyone know why no matter what I do my MadVR Control Panel will not show up. When i click on the filter in my filters list on a video the popup says Change Settings and Show Tray Icon. Clicking either opens another process in my process list but doesn't do anything and the tray icon will not appear. I have tried re-installing windows as well as 3 different versions of madvr / Nvidia drivers

[ryrynz]

Maybe try another player, mpc-hc for example and see if you have the same issue.

Madshi, the .ax files are quite a bit larger than in previous releases, zip is now 10MB larger.
Not that it's a big deal but, what gives?