madVR - high quality video renderer (GPU assisted)

[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

[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)

[kasper93]

@madshi: Take a look at this sample AR.ts (https://www.dropbox.com/s/a5nwmkgv2thhe8o/AR.ts?dl=1) madVR have troubles to detect black bars after aspect ratio change. Green lines mark wrong area.

[Magik Mark]

I have a 10bit video. It turns out madvr doesn't do chroma upscaling anymore. Is there a way for madvr to REDO the chroma upscaling?

[Asmodian]

I have a 10bit video. It turns out madvr doesn't do chroma upscaling anymore. Is there a way for madvr to REDO the chroma upscaling?

I can assure you that madVR does chroma upscaling with 10-bit video. At least my experience with 10-bit video is normal with v0.89.2.

What makes you believe madVR is no longer doing chroma upscaling?

[FreeFall]

madshi,

Thanks for your continued development of madVR. I'm having trouble with a couple of videos using the new detect black bars function.

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).
https://www.dropbox.com/s/e4qayrnsehxltlp/mvrtest1.zip?dl=0

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.
https://www.dropbox.com/s/5z81qo74htz61st/mvrtest2.zip?dl=0

[Magik Mark]

I can assure you that madVR does chroma upscaling with 10-bit video. At least my experience with 10-bit video is normal with v0.89.2.

What makes you believe madVR is no longer doing chroma upscaling?

I have 10bit x265. Pressing ctrl j does not indicate chroma upscaling. Using gtx 960 & dxva copy back in latest lav. Is there a setting that I'm missing? Only happening in 10bit x265. 8bit has no problem at all

[Qaq]

I have 10bit x265. Pressing ctrl j does not indicate chroma upscaling.
Perhaps, video is 4:4:4 already? OSD screenshot would help a lot.

[SweetLow]

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

[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.

[MSL_DK]

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]

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]

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

Here you go:

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

[huhn]

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]

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]

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]

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]

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 (http://forum.doom9.org/showthread.php?p=1735591#post1735591)), which is way simpler and completely good for me now. Thanks anyway!
And that's why I asked the other shortcut question. :) (see below)

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?! :D

[madshi]

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.
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.

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? :o
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.

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.

"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.

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.

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

[...]

I know I am not a beneficial contributor in this thread, but I'm trying :helpful:, 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.

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.

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.

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.

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.

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.

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.

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.

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

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.

@madshi: Take a look at this sample AR.ts (https://www.dropbox.com/s/a5nwmkgv2thhe8o/AR.ts?dl=1) 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?

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.

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.

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]

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]

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]

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]

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.

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]

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? :D

[XRyche]

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.

Yes, NNEDI3 is completely disabled, including chroma upscaling. . Even when just using Nedi or super-xbr I get the inordinately long wait times with frame drops from 500-700. Although when I use NNEDI3 for chroma upscaling it looks fine, no emboss effect, except when I'm using NNEDI3 for image doubling. If I use super-xbr or Nedi in conjunction with NNEDI3 chroma upscaling I don't get the emboss effect just the inordinately long wait times.


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.



Yes, I had DPI set at 125% when it would only output FS windowed mode. Setting my DPI settings to 100% solved this particular issue. I actually did read about that about 10 or 20 pages back but totally forgot about it. Oops............I am sorry about that. I can plainly see how annoying it is to have to repeat the same thing over and over again.

[petran79]

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

I have this issue with a video that has a resolution 704x400 and black horizontal stripes.

On windowed mode it appears in the correct aspect ration but on full screen mode black stripes disappear and image fills the whole screen. Problem is that subtitles are hidden and impossible to appear, even if they're in ASS format.

I am confused as to what settings to add in madvr. I havent touched anything in the media player. When I switch video renderer, full screen appears fine.

WINDOWED:
http://abload.de/img/gf18fu9u.jpg

FULLSCREEN

http://abload.de/img/gf2kkumh.jpg

[BetA13]

madshi allready answered that question here ;)


Quote:
[QUOTE]Originally Posted by BetA13 View Post
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..

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

[kongfl888]

madshi allready answered that question here ;)

[QUOTE]
Quote:


madshi
BetA13
Thank you for your info:goodpost:

madshi,
Thanks:thanks:

[egandt]

MadVR Windows 10 and refresh changing, using .89.2 I'm unable to get the refresh rate to change when I start a full screen video in ZP 11RC1, on Windows 8.1 this was working, has anyone else encountered a similar issue?

ERIC

[leeperry]

Not sure it's any relevant or useful feedback but I see that you're going all the way when it comes to black bars and I've seen myself using this "Borders" PS script (http://forum.doom9.org/showthread.php?t=170357) a few times in order to hide TV channel logos.....I guess a worst case scenario would be a 15/9 TV broadcast with a nasty TV logo in the black bars("arteHD" comes to mind).

It would make sense to me to allow adding black bars first and then detecting what's left of them afterwards(be it TV logos, ugly borders or maybe encodes with hardsubs in the black bars when you'd like to use subs in a different language or simply hide them altogether), anyway it can come in handy IME.

My ex-HC3100 DLP pj came with an option to add horizontal black bars on purpose and I did use it a few times, especially on music videos captured from TV broadcasts.....so why not a filename tag while we're at it :D

[CiNcH]

A debug log would be great!!
Here we go...

I started the DVBViewer on a 1080i channel. That worked. No error and deinterlacing is on. Then I switched to another 1080i channel. DXVA processing failed and deinterlacing was off from then on. Log attached...

madVR - log (https://www.dropbox.com/s/yfyksrho536bzpo/madVR%20-%20log.zip?dl=1)

[madshi]

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
I'd like to see this back as well.
I'm not sure how useful it would be. Would you like to see the original target resolution asked for by the media player? Or the final target resolution decided on by madVR? These may differ, depending on "zoom control".

madshi > i've thought the same, but downgrading driver before the windows 10 verdion doesn't help. :(
I didn't mean to say that it's isolated to one specific driver. I believe this is a general driver problem which is probably in all drivers of your GPU manufacturer. And until they specifically look at this problem and try to fix it, there's not much we can do about it.

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.
You can either use MPC-HCs "touch window from outside" for that purpose, or in madVR's "zoom control" activate the option "if there are big black bars -> zoom the bars away completely".

No NLS in madVR any time soon, I hate NLS and consider it harmful for image quality. I might add it, anyway, at some point, to make users happy. But priority is very low atm.

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.
Is that with video mode deinterlacing or forced film mode? Which GPU are you using? And do you have the options "use a separate device for presentation / DXVA processing" enabled? Try disabling those.

Yes, NNEDI3 is completely disabled, including chroma upscaling. . Even when just using Nedi or super-xbr I get the inordinately long wait times with frame drops from 500-700.
If you upload a debug log for me, I can have a look.

MadVR Windows 10 and refresh changing, using .89.2 I'm unable to get the refresh rate to change when I start a full screen video in ZP 11RC1, on Windows 8.1 this was working, has anyone else encountered a similar issue?
Not heard about such issues yet, I think. Upload a debug log and I'll have a look. Which exact settings are you using in the madVR "display modes" settings page?

Not sure it's any relevant or useful feedback but I see that you're going all the way when it comes to black bars and I've seen myself using this "Borders" PS script (http://forum.doom9.org/showthread.php?t=170357) a few times in order to hide TV channel logos.....I guess a worst case scenario would be a 15/9 TV broadcast with a nasty TV logo in the black bars("arteHD" comes to mind).
Have you actually tested a 15/9 arteHD broadcast with TV logo with madVR's black bar detection, and found there to be actual problems?

If yes: Thanks for the report, and please post a small sample.

(If no: Please refrain from fantasizing about problems that you think might be there, and then following that up by suggesting various potential solutions to those imagined problems. If every madVR user started doing that, I might as well stop madVR development right now, because I'd never see the end of it. I've enough work to do as it is with working on problems that actually exist.)

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).
You're right! I missed the fact that there was a stream AR change. I've now added code to clear the current AR detection information when the video stream changes AR. And it actually did improve the black bar detection with your sample a bit, so thanks.

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"
Thanks. I can reproduce it. Shouldn't be too hard to fix. FWIW, currently madVR tries to guess the zoom setting MPC-HC is using by looking at the target rect MPC-HC asks for. Obviously there's a bug in my interpretation code. But even if I fix all the bugs, it can't ever be perfect because often "normal size" and "touch from inside" will result in the same target rect, so in that situation madVR cannot know what MPC-HC wants, just by looking at the target rect. So my plan is to add a simple interface which MPC-HC can then use to tell madVR which exact zoom mode it wants (plus additional zoom and position tweaks), so I don't have to guess. But that's for a future build, I'll let you know when it's ready. Should only cost minimal extra code in media players.

Here we go...

I started the DVBViewer on a 1080i channel. That worked. No error and deinterlacing is on. Then I switched to another 1080i channel. DXVA processing failed and deinterlacing was off from then on. Log attached...

madVR - log (https://www.dropbox.com/s/yfyksrho536bzpo/madVR%20-%20log.zip?dl=1)
Thanks! It was a timing issue in combination with the relatively new feature to render in stopped mode. I think the following test build should fix it. If not, could you please provide another debug log from this test build?

http://madshi.net/madVR892dxva.rar

[romulous]

I'm not sure how useful it would be. Would you like to see the original target resolution asked for by the media player? Or the final target resolution decided on by madVR? These may differ, depending on "zoom control".

I'd like to see this return also - it was handy for determining what resolution the current video was playing at (not the actual video clip resolution, but the actual resolution currently being used, taking into account the window size - I'd have to use an on-screen ruler tool to get that window size now that it has been removed from madVR).

romulous

[MSL_DK]

I didn't mean to say that it's isolated to one specific driver. I believe this is a general driver problem which is probably in all drivers of your GPU manufacturer. And until they specifically look at this problem and try to fix it, there's not much we can do about it.

hmm ... I had no problems when I ran Windows 7, the problem started with windows 10. Considering therefore to switch back to windows 7

[huhn]

the current version is already trying to detect subtitles in black boarders and TV logos.

there is even an option to ignore or not ignore subtitles

[leeperry]

the current version is already trying to detect subtitles in black borders and TV logos.

there is even an option to ignore or not ignore subtitles
Fair enough, I'll try to come back with nasty samples then.

[SweetLow]

@James Freeman
>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?
It's very simple. madshi asks confirmation of rendering problem introduced in 0.88.17. In my environment it is reproduced very well. But since 5 day wait of posting for new users it's not need (after 5 days) ;)

[XRyche]

If you upload a debug log for me, I can have a look.




When I activate debug mode it says "cannot find madvr.ax". I have MPC-HC running and playing a video with the OSD for madVR displayed so obviously it's using madVR.ax. So I don't seem to be able to upload a debug log :confused: .

[KhR0N1K]

[QUOTE=Originally Posted by madshi View Post
I'm not sure how useful it would be. Would you like to see the original target resolution asked for by the media player? Or the final target resolution decided on by madVR? These may differ, depending on "zoom control".

Originally Posted by romulous View Post
I'd like to see this return also - it was handy for determining what resolution the current video was playing at (not the actual video clip resolution, but the actual resolution currently being used, taking into account the window size - I'd have to use an on-screen ruler tool to get that window size now that it has been removed from madVR).

romulous [/QUOTE]

i would like to see both like how it is in 88.21. so i can see the orig movie resolution and the final movie target rectangle.

[CiNcH]

Thanks! It was a timing issue in combination with the relatively new feature to render in stopped mode. I think the following test build should fix it.
Looks good. I switched a lot between 576i, 720p and 1080i (with 1920 and 1440 horizontal resolution) and it did not fail again. I will keep an eye on it. Thanks a lot so far!

[James Freeman]

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?
It's very simple. madshi asks confirmation of rendering problem introduced in 0.88.17. In my environment it is reproduced very well. But since 5 day wait of posting for new users it's not need (after 5 days) ;)

Ain't that the truth. :D
Hats off for madshi!

[aufkrawall]

I'm not sure how useful it would be. Would you like to see the original target resolution asked for by the media player? Or the final target resolution decided on by madVR? These may differ, depending on "zoom control".

I'd like to see the information what exact size the portrayed video by the player has.
This is very useful when resizing to a certain resolution (e.g. when you want to resize pixel exact to a size that isn't offered by the player as a template like "50%" or you want to make sure the player really resizes as it's told).
Otherwiese I might be really handicapped when doing image quality comparisons in the future. :(

[egandt]

Not heard about such issues yet, I think. Upload a debug log and I'll have a look. Which exact settings are you using in the madVR "display modes" settings page?


http://madshi.net/madVR892dxva.rar

Here is the log from madvr debug, not sure what to look for my self and the log was huge so I only include the first 20K lines or so.

Thanks,
Eric

[aufkrawall]

Please upload it to some sharehoster like Mediafire, it usually takes too long here until attachments are unlocked for downloading.
If you compress it as 7z archive with Ultra preset, size also shouldn't be a real problem.