madVR - high quality video renderer (GPU assisted)

[MSL_DK]

Originally Posted by madshi

Is it 1080p59 or 1080p60? And what kind of render times do you have? 1080p60 does require slightly more resources than 1080p23, even if the movie is only 23p. The difference is small, but there is a difference. Maybe you need to lower your settings a tiny bit?

I'll try to explain my self.
If running my display in 1920x1080@60 and madVR 10bit (or higher) present queue never gets filled (1-8 / 8) the same with render queue (1-8 / 8) Upload queue is fine (7-8 / 8

If running my display in 1920x1080@23 and madVR 10bit (or higher), then no problems.

and

If running my display in 1920x1080@60 and madVR 8bit, then no problems.

EDIT: Render times: around 5ms, present going crazy 13ms at 1920x1080@60 10bit and 0.10 at 1920x1080@60 8bit and 1920x1080@23 10bit

[creativeopinion]

Originally Posted by panetesan2k6

Hi everyone.

I wonder if someone could elaborate on why this happens:

I use my laptop to play media on my FullHD tv through HDMI, with MPC-HC and MadVR. The laptop being 1366x768, I don't clone or extend desktops, I rather make the TV the only screen when HDMI is connected. Usually I do one of these two things: Start up the laptop with the HDMI already connected, having to log in to Windows through my tv, or having the laptop on, connect the HDMI cable so the desktop moves to the tv.

Yesterday I watched smoothly several tv shows and today they played horrible, unwatchable, with heavy frame skipping. I didn't use the laptop for anything else, I didn't change anything... so I soon realized the what happened: Yesterday, I booted up the computer with the HDMI already connected, and today I hooked it up after the computer started up. So, I shut it down, started up again with HDMI already connected and it played all files as smoothly as yesterday.

Is this a driver related thing? MadVR showed the same info on both scenearios, apart from the frame skipping. I could make some screenshots.

Thank you.

I think we're talking here about two graphic cards. As you know madVR is using GPU for processing so your GPU is more powerful than integrated one. When you boot up your PC without HDMI your laptop is using a less powerful card hence frame skipping. Even if you plug your HDMI after boot up it still can have problems to switch so you need to do a restart with HDMI plugged in.

I have a friend with exact the same problem where his PC is using less powerful card for madVR even though he wants to use a better one. I'm not sure about possible solutions. You can google how to activate your cards as the default one or how to quickly switch between the two. I'm pretty sure it's a common issue. I might be wrong. Just shot in the dark but it makes sense to me.

[Magik Mark]

Originally Posted by Qaq

Perhaps, video is 4:4:4 already? OSD screenshot would help a lot.

Here you go:

[huhn]

Originally Posted by Magik Mark

Here you go:

http://i.imgur.com/kaTtGT4.png

the decoder is outputting 8 bit RGB so yes no chroma scaling.

what decoder/extra filter are you using and have you changed anything in them.

[Qaq]

Originally Posted by Magik Mark

Here you go:

RGB is always 4:4:4. You said you're using LAV copy-back and OSD indicates ffdshow. Perhaps, its ffdshow converts decoded video stream to RGB. Why ffdshow and not LAV? I guess you have to decode with LAV, with all colour options checked.

[Magik Mark]

Originally Posted by Qaq

RGB is always 4:4:4. You said you're using LAV copy-back and OSD indicates ffdshow. Perhaps, its ffdshow converts decoded video stream to RGB. Why ffdshow and not LAV? I guess you have to decode with LAV, with all colour options checked.

I have lav. I also using SVP. SVP uses ffdshow raw

Disable ffdshow & SVP. Evrything is doing fine. Does anybody know why this is happening?

[Qaq]

SVP works in YV12. Check ffdshow video settings - Output, make sure YV12 NV12 are checked, uncheck High Quality YV12 to RGB conversion.

[James Freeman]

@SweetLow, creativeopinion.

This is not madVR related but I have to ask this.
Can you please explain the reason of registering to a forum without posting a single message for MONTHS/YEARS then suddenly popping out with a first post?
How did you remember your UN and PW?
This is something I have witnessed several times on internet boards, but I truly wonder why?
All in good spirit.

PS.
Welcome!

[creativeopinion]

Originally Posted by James Freeman

This is not madVR related but I have to ask this.
Can you please explain the reason of registering to a forum without posting a single message for MONTHS/YEARS then suddenly popping out with a first post?
How did you remember your UN and PW?
This is something I have witnessed several times on internet boards, but I truly wonder why?
All in good spirit. PS.
Welcome!

I've been a madVR user since I don't really remember. A friend helped me with settings etc. Then I had a problem and I asked him to post here and ask to find a solution. I wanted to do it by myself but as you know you can't post immediately after you complete a registration process so he helped me and that's it. I don't consider myself as an expert or even as an advanced madVR user but I've learned a few things (still learning) and If I can i want to help. I read this topic quite a lot and yeah maybe it was just my first post but you know how it is. You gotta start somewhere.

btw. what do you mean by how did I remembered my UN and PW. I'm using 1Password.

[chros]

Originally Posted by madshi

Good question, I've no idea. I suppose this doesn't really have much to do with madVR, right? I mean you want to make MPC-HC send some messages to the video renderer (regardless of what the video renderer is), right? In that case you may have to talk to the MPC-HC devs. If you want to talk directly to madVR, that's a whole different topic, of course. There is a network protocol madVR supports, but it's not very simple, and currently the set of supported commands is limited to what I need for my own purposes (and what's needed for madTPG / calibration remote control). I could add more commands, if needed, but that makes sense only if you can manage to actually connect by using the specific network protocol.

Thanks, but no need for that. Since I couldn't manage to even connect to it I found a workaround (see here), which is way simpler and completely good for me now. Thanks anyway!
And that's why I asked the other shortcut question. (see below)

Originally Posted by madshi

Can you ask again some weeks/months later? My to do list is already too full atm.

No worries, I thank You!

@James Freeman: then what about me?!

[madshi]

Originally Posted by videonerd

Hi madshi - thank you. Since an enhancement to madvr is done to satisfy a subset of users (certain players rendering during pause) but results in an undesired side effect (blank during undetectable graph restarts) with no ready solution, how about adding a variable (ini is fine, need not be in GUI) to turn on/off this new feature? Thank you once again.

Originally Posted by ibius

Same here, would love to be able to turn that thing off (like creating empty file system object "ShowBlackBars").
Meanwhile I'm on v0.88.16 and looking forward to "clear black bars" option.

Alright. In the next build you can create an empty file or folder named "DontRenderAfterStop" in the madVR folder, which will stop madVR from rendering for 7 seconds after playback is stopped. That should solve the black screen during seeks and playrate changes.

Originally Posted by aufkrawall

Stupid question: When you said you'd like to look into the NNEDI3 issue, did you mean the coming weekend or the weekend after it?

The plan was for this weekend. But I have a full time schedule for this weekend, so I'm not sure I'll get to it.

Originally Posted by aufkrawall

Shouldn't madVR pick BT.2020 for UHD 10/12 bit content?
With 10 bit it guesses BT.709 here.

Once I had detection in for P3, BT.2020 etc. But I got several complaints from users trying to play 4K videos they downloaded from somewhere which were encoded in BT.709 without being flagged so.

All BT.2020 HDR streams I've seen so far were properly flagged. So I think for now it might be the better option to default to BT.709, unless the flags say otherwise. I'm happy to change this if time proves it would be better. But for now I see no urgency in changing anything.

Originally Posted by kasper93

"Clean up image borders" option was the issue. Even though black bars detection was disabled it still was cropping.

Ooops. Good find - thanks! Forgot to check if the "parent" option was checked, when applying the "sub" options. Will be fixed in the next build.

Originally Posted by ADude

What if the area of the video that is not black, is not the same frame size as the screen? Does that new smaller frame size trigger the madVR scaling profiles and algorithms ?

For example, suppose the screen is 1920x1080 and the area inside the black bars is 1280x720. Will madVR using the same scaling profiles and algorithms that would be used if the actual stated frame size of the video was 1280x720 ?

That's the plan. Although I haven't fully double checked yet if the values reported to the profiles are all corrected accordingly. If they aren't, feel free to report that as a bug.

Originally Posted by XMonarchY

Yey me! I made NVidia listen, I think...

[...]

I know I am not a beneficial contributor in this thread, but I'm trying , although I think madshi has a more direct communication with NVidia developers.

Good job - and thanks! FWIW, I've zero communication with NVidia, unfortunately. Anyway, I was planning to look into using a different interop interface this weekend, so maybe NVidia won't have to do anything. But I can't promise anything right now.

Originally Posted by XRyche

I've updated to a new Windows 10 Beta driver and it didn't make a difference. Still getting inordinately long wait times when any type of image doubling is used. It actually skips 500-700 frames before I actually get an image on screen including using NNEDI3. With NNEDI3 I am still getting an embossed effect with the image.

NNEDI3 is somewhat of a special case. It requires an OpenCL kernel to be compiled, which takes time - although the kernel is then saved to the registry, so the wait time should only occur the first time you run madVR. Are you sure the same problem occurs if you disable NNEDI3 everywhere and use a different sort of doubling (e.g. super-xbr)? Make sure you diable NNEDI3 also in chroma upscaling.

Originally Posted by XRyche

Also, I didn't notice until someone posted about it but, madVR isn't using FSE mode in FS only FS windowed.

Earlier reports indicate that this problem might be caused by non-standard DPI settings. Have you changed the DPI settings? Try setting them to default value. This may also be solved by updating your media player.

Originally Posted by fedpul

madshi, I have been doing several tests and finally I was able to identify what was causing the crashes with JRiver MC 20. It was NNEDI. The instant I choose it as Luma Doubling, then stop the movie, then click play and it crashes instantly. Also I find another problem, DX11 windowed mode is very slow (at the point i can't even use Super-XBR) in comparison with DX9 windowed, there is no such difference in FSE.

Can you send me your exact madVR settings, and maybe a sample video with which the problem occurs? Then I'll try to reproduce it here. Also please let me know which LAV settings you're using (software decoding or copyback or native DXVA or ...).

The madVR settings are stored in "madVR\settings.bin", if madVR has write access to that folder. Or in HKCU\Software\madshi\madVR\Settings otherwise.

Originally Posted by Sunset1982

Edit: problem solved. Wrong bios setting (PCI-E Lanes "16/0" instead of "Auto"; changed it to Auto solved the problem) Now everything works great with 0.89.2

Oh, interesting.

Originally Posted by Sunset1982

someone has a link to the registry hack or the thread page to force madvr to use nvidia gpu instead of onboard gpu?

That's *only* for OpenCL, not for anything else.

Originally Posted by BetA13

i have a strange problem with the new MADVR version...
ussually i double klick the media player, (mpchc) to go into fullscreen.

anyway, sometimes, mostly, when i go into fullscreen i only see 1/4 of teh picture. its like zooomes way in, and i cant seem to change it at all..

That's my fault, sorry about that, should hopefully be fixed in the next build.

Originally Posted by 6233638

Not a big deal, but I noticed that the screenshot function in JRiver MC seems to grab the full frame rather than the crop.

As I understand it, the screenshot function is supposed to grab an unscaled image, so this is probably intentional, but I think I've only ever used the feature to grab thumbnails for videos so it would actually be preferable to grab a cropped & scaled image. (e.g. aspect ratio correction for anamorphic videos)

Screenshot functionality is on my to do list, but there are some other more important things atm.

Originally Posted by SweetLow

madshi, thanks for new option of disable scaling video of near view size from lazy people

Pleasure!

Originally Posted by MSL_DK

I'll try to explain my self.
If running my display in 1920x1080@60 and madVR 10bit (or higher) present queue never gets filled (1-8 / 8) the same with render queue (1-8 / 8) Upload queue is fine (7-8 / 8

If running my display in 1920x1080@23 and madVR 10bit (or higher), then no problems.

and

If running my display in 1920x1080@60 and madVR 8bit, then no problems.

EDIT: Render times: around 5ms, present going crazy 13ms at 1920x1080@60 10bit and 0.10 at 1920x1080@60 8bit and 1920x1080@23 10bit

This is very likely a GPU driver problem, unfortunately. I don't really have any way to solve this, I believe. I'm not doing anything special which would explain a difference between 23Hz and 60Hz. Reducing the number of prepresented frames may help.

Originally Posted by kasper93

@madshi: Take a look at this sample AR.ts madVR have troubles to detect black bars after aspect ratio change. Green lines mark wrong area.

I've checked this sample, but as surprising at it may seem, madVR does what it's supposed to do here. Let me explain why:

There are two different kinds of AR changes:
1) The active video area could become bigger.
2) The active video area could become smaller.

Case 1) is rather easy to detect. If there are bright pixels in what madVR thought were black bars, obviously the black bar detection is no longer correct. In that case I discard the old detection immediately. So in case 1) madVR should react *immediately*.

Case 2) is troublesome because there's a *big* potential for false positives. E.g. look at this image:

http://madVR.com/doom9/stuff/falsePositiveDanger.png

If I'm not careful, I'd detect pillarboxing in this image. But actually it's a wide screen image which just has a black/dark left and right image area. Things like this do occur in movies once in a while. If I change black bar detection too quickly, I would often fall into such a false positive trap. Because of that, in case 2) I'm intentionally delaying the detection of a modified AR, to avoid false alarms.

Practically this means if the active video area gets smaller, I'm waiting a couple of seconds to confirm the new AR, just to be safe. How long I'm waiting depends on the circumstances. Could be anything between 5 and 35 seconds. If I detect heavy pillarboxing in the newly detected AR then there's an increased risk of it being a false positive, so in that case I wait up to 35 seconds.

In your sample video there are some such cases where the AR changes and the active video area gets smaller. madVR detects the AR change practically immediately, but it intentionally stays with the old AR detection, just to be safe. You can double check this like this: When the video switches to a new AR which madVR doesn't immediately switch to, pause playback for 40 seconds. Then continue playback. Now the new AR should be detected quickly. This is actually a hack showing that my waiting for 35 seconds can be screwed up by pausing playback. But I don't think this is worth worrying about so I'm probably not going to "fix" that.

In order to speed up things with e.g. IMAX movies, I'm storing ARs which were already detected and confirmed, and I'm switching to them immediately. So in IMAX movies this 5-35 second delay should not occur. It only occurs the first time a new AR is detected which is smaller than the previously detected AR.

Makes sense?

Originally Posted by FreeFall

Using MPC-HC, keep aspect ratio is disabled and stretch to window enabled (video frame options).

This Pillarboxed Blu-ray Disc doesn't want to scale to the screen resolution (1920*1080).

Please don't use "stretch to window", it's a very bad option which often distorts the original aspect ratio of the movie. Please use "touch window from inside". For me your pillarboxed Blu-Ray sample works perfectly fine with "touch window from inside" together with the black bar detection.

Originally Posted by FreeFall

I'm not sure if you can improve things with this DVD, fast scene / AR changes, detection is a bit slow. The subtitles also get cut off.

About speed see my reply to kasper93. There's an option in "zoom control" with which you can define if the subtitles should be cut off or not. I do see some issues with this DVD, though, which I have to investigate. Black bar detection sometimes gets broken when subtitles appear, which is not supposed to happen.

Originally Posted by CiNcH

I still have the failing DXVA processing with .2 when switching channels (1080i) with a subsequent switch-off of the deinterlacing.

A debug log would be great!!

[KhR0N1K]

Originally Posted by BetA13

i have a strange problem with the new MADVR version...
ussually i double klick the media player, (mpchc) to go into fullscreen.

anyway, sometimes, mostly, when i go into fullscreen i only see 1/4 of teh picture. its like zooomes way in, and i cant seem to change it at all..

i have to restart the player like 8 times, till it goes correctly into fullscreen..
dunno what is doing this, but 0.88.21 works as it should...

if you need more infos i would be glad to post em..

greetz

im having the same sort of issue. so i downgraded to 0.88.21 until this zoom stuff and black bars etc is sorted out. also liked when the OSD showed the actual target rectangle size instead of just saying "Touch Window From Inside" etc. thanks for any info in advance

[MSL_DK]

Originally Posted by MSL_DK

I'll try to explain my self.
If running my display in 1920x1080@60 and madVR 10bit (or higher) present queue never gets filled (1-8 / 8) the same with render queue (1-8 / 8) Upload queue is fine (7-8 / 8

If running my display in 1920x1080@23 and madVR 10bit (or higher), then no problems.

and

If running my display in 1920x1080@60 and madVR 8bit, then no problems.

EDIT: Render times: around 5ms, present going crazy 13ms at 1920x1080@60 10bit and 0.10 at 1920x1080@60 8bit and 1920x1080@23 10bit

madshi > i've thought the same, but downgrading driver before the windows 10 verdion doesn't help.

[aufkrawall]

Originally Posted by KhR0N1K

also liked when the OSD showed the actual target rectangle size instead of just saying "Touch Window From Inside" etc.

I'd like to see this back as well.

[kasper93]

Originally Posted by madshi

Practically this means if the active video area gets smaller, I'm waiting a couple of seconds to confirm the new AR, just to be safe. How long I'm waiting depends on the circumstances. Could be anything between 5 and 35 seconds. If I detect heavy pillarboxing in the newly detected AR then there's an increased risk of it being a false positive, so in that case I wait up to 35 seconds.

In your sample video there are some such cases where the AR changes and the active video area gets smaller. madVR detects the AR change practically immediately, but it intentionally stays with the old AR detection, just to be safe. You can double check this like this: When the video switches to a new AR which madVR doesn't immediately switch to, pause playback for 40 seconds. Then continue playback. Now the new AR should be detected quickly. This is actually a hack showing that my waiting for 35 seconds can be screwed up by pausing playback. But I don't think this is worth worrying about so I'm probably not going to "fix" that.

I understand that, but in case of EC_VIDEO_SIZE_CHANGED I think you should clear any previous assumptions. I think this it is safe to say that any previous active video area detection may be wrong. In this sample we have a switch and after that madVR still holds previous assumption (I'm looking at green lines).

Also there is another issue with this sample. madVR incorrectly detect "stretch to window" instead "touch window from inside" if you start playback after size change. Easiest to reproduce "mpc-hc64.exe AR.ts /startpos 0:30" (or with different sample). This is probably because mpc-hc sets video size to one reported from splitter before starting playback and then after running graph video decoder send proper video size. This change apparently fool madVR to think that we want "stretch to window" while we don't. Or whatever else happen, you will probably know instantly after looking at it.

Originally Posted by madshi

In order to speed up things with e.g. IMAX movies, I'm storing ARs which were already detected and confirmed, and I'm switching to them immediately. So in IMAX movies this 5-35 second delay should not occur. It only occurs the first time a new AR is detected which is smaller than the previously detected AR.

I can even see that in this sample. If I play it back once and seek to beginning. I think this is good idea, and for IMAX movies it works great.

[panetesan2k6]

Originally Posted by creativeopinion

I think we're talking here about two graphic cards. As you know madVR is using GPU for processing so your GPU is more powerful than integrated one. When you boot up your PC without HDMI your laptop is using a less powerful card hence frame skipping. Even if you plug your HDMI after boot up it still can have problems to switch so you need to do a restart with HDMI plugged in.

I have a friend with exact the same problem where his PC is using less powerful card for madVR even though he wants to use a better one. I'm not sure about possible solutions. You can google how to activate your cards as the default one or how to quickly switch between the two. I'm pretty sure it's a common issue. I might be wrong. Just shot in the dark but it makes sense to me.

Hi creativeopinion.

My laptop actually has two graphic cards, the main one is an independent Radeon Mobility HD4700 series. The secondary one it's the one on the i5 cpu, Intel HD 2000 I think. But this one is disabled by default, actually there are folks who own the same series of laptops trying to enable it with no luck as far as I know. I don't think it is active in any case. Maybe you misunderstood me and thought I was talking about a desktop computer.

Anyways, I reproduced the frame skipping this afternoon after a fresh start with the HDMI cable connected from the beginning. So I don't know what to think...

I would like to know how to dump as much info as I can into a file in both cases, with frame dropping and with smooth playback, and see what's causing the first scenario. Do you know how to do it?

Thanks.

[FreeFall]

madshi,

I just checked the Blu-ray disc again and it's working the Osd shows 1416 1065, 4:3, I was confused about how the current detection method works.

What I would like to be able to do is crop the black bars completely and then have the renderer upscale the video to the displays native resolution so that the image fills the screen, ignoring the original AR. Even though it may be technically wrong to do so I personally can't stand Pillarboxed videos, maybe a method similar to EVR's non-linear stretch could be applied in this case.

[propheticus]

Error report:

DVD playback with madVR results in what seems like frames going back and forth. This looks epileptic shock inducingly bad.
It goes something like this 1-2-3-4 3-4-5-6 4-5-6-7 6-7-8-9

When I choose System default or VMR as renderer everything's fine. So that's why I don't think it's MPC-BE or LAV's causing it.

Running:
Windows 10 64 bits
MPC-BE (64-bit) 1.4.5 (build 677) beta
LAV filters (splitter, video and audio decoder) 0.65.0 (64-bit)
madVR 0.89.2

[har3inger]

That tends to happen when smooth motion is on and you're just barely dropping frames every second. Did you have a look at render times in the OSD or try turning smooth motion off?

[propheticus]

Render time 3ms and smooth motion is off always.

off-topic: I've deleted the DVD rip cause it did not have the DTS stream. I'll use handbrake or somesuch to make a single container file (mkv/mp4) next time. Who uses DVD nowadays anyway?