[madshi]

Originally Posted by secvensor

image upscaling - Jink 4 or 8 select
go to
croma upscaling - Jink 3
go to
image downscaling - Spline 4
go to
image upscaling - Jink 4 or 8 be in false

Thanks, this will be fixed in v0.85.2.

Originally Posted by petri234

Don't know if this has been mentioned yet, but DXVA decoding with default settings crashes MPC-HC for me about 50% of the time when viewing 23.976p material. This only happens when skipping forward or backward, however if the player does not crash, I can skip forward safely as many times as I please. I am using LAV filters and a laptop with ATI 4670.

Does this occur with all 23.976p movies for you, or just with some? Does it e.g. depend on the codec? Have you updated to the latest LAV version? I've not heard about such instability by anyone else yet, so I wonder why it only seems to affect you. Maybe it's just with some specific video files?

Originally Posted by manma

I'm not sure if I understand completely yet. Can increasing or decreasing queue sizes help reduce dropped frames? Ever since I set up yCMS color calibration with madvr, I've had a good amount frame dropping, and I need to do something to make up for the performance loss. Is there anything I can do other than get another GPU (not an option, as I'm on a laptop).

You could try turning down the scaling algorithms. In the worst case you could try bilinear (ouch). Tuning the queue sizes might have minor effects, but nothing major, so I don't think it will help.

Originally Posted by 6233638

I really don't think that having Bilinear as the default for Chroma is a good choice. As Chroma is only ever a 2x scaling operation, the performance impact of using a better scaling algorithm seems to be minimal in most cases.

Interesting. I haven't really measured performance, but it makes some sense. Chroma upsampling is cheaper because I hard coded it to do exactly 2x which allowed me to write more efficient shader code. Maybe using Bilinear as default for chroma upsampling isn't necessary. But then we come back to the very old discussion about which algorithm to use instead, and we never seem to be able to agree there...

Originally Posted by 6233638

While not related to selecting good defaults, in my testing, I also happened to come across a use-case for Jinc 8. There are some images I came across where using Jinc 8 AR for Chroma was the only option that looked really good, being the only choice that avoided aliasing and maintained the correct brightness/saturation for Chroma. This is not an endorsement of using it, as there are most likely problems using it with other images (as there tends to be with higher-tap filters) but I thought it was interesting.

The only other algorithm that looked decent with this image was SoftCubic 100, which was too dull/desaturated, but avoided most of the aliasing.

Yeah, my preference for using SoftCubic 100 is exactly that it avoids aliasing quite nicely with problematic sources. I've recently found a broadcast where a guy was wearing a black/red patterned jacked and it looked so much less bad with SoftCubic 100 compared to e.g. Bicubic or Lanczos.

Originally Posted by 6233638

Now I don't suggest that SoftCubic 80 be the default for Luma at all, but I worry that Lanczos 3 AR will be too taxing for a lot of hardware.

I really hoped that going from Lanczos 4 (original default) to Lanczos 3 would allow me to activate AR by default, but maybe you're right and it's too taxing. However, from HD 4000 reports it seems that Lanczos 3 AR is not really a problem. So the big quesion is which hardware to use as reference.

Originally Posted by 6233638

From looking at those numbers, I think that it would probably be best to use Bicubic 75 Chroma, which can be a significant visual improvement over Bilinear in many cases (often a close visual match to Lanczos or Jinc) for a minimal performance hit compared to Bilinear.

I'm still not sure which chroma algorithm to use. With some content I prefer SoftCubic, but in the meanwhile I've also run into real life content where a sharper chroma algorithm looks noticeably better.

Originally Posted by 6233638

And now that I've overclocked the card (1GHz GPU/720MHz RAM) I seem to be able to play Blu-ray downscaled in linear light using Catmull-Rom AR without any problems, though it is probably still too taxing on some systems.

Interesting. So Catmull-Rom AR downscaling in linear light is less taxing than Lanczos 3 AR upscaling?

Originally Posted by 6233638

That's interesting, I was under the impression that all the Bicubic variations (Mitchell-Netravali, Catmull-Rom, Bicubic, and SoftCubic) were all the same algorithm with adjusted values, that wouldn't change the load they put on the GPU.

All 2-tap algorithms should have exactly the same performance. And all 3-tap algorithms should have exactly the same performance. Etc...

Originally Posted by 6233638

EDIT: And from doing some extra testing, at least with some scale factors (I don't know if it will change dynamically) Nvidia basically using Bilinear scaling with the DXVA2 option. (results are slightly different) So it's even worse than I thought, considering that with madVR's Bilinear Luma scaling I was getting render times of about 3ms compared to the 50ms+ of DXVA2.

EDIT2: Actually, it's worse than that - if you use DXVA2 for Luma upscaling, Chroma upscaling is basically ignored. Unless DXVA2 is handled a lot better on AMD/Intel, I wonder if it should actually be removed.

madVR v0.85.2 will change from NV12 -> NV12 DXVA2 scaling to NV12 -> RGB DXVA2 scaling. Maybe NVidia will use a better algorithm then? I don't know, but a retest might make sense.

Originally Posted by mindbomb

I have an interesting problem. With hardware deinterlacing on my radeon, it doubles the frame rate, and thus, halves the movie frame interval, requiring even faster rendering than I can manage. Can I disable this in the registry somehow to keep the frame rate the same?

There are different types of content. If you have native video content, doubling the framerate is the only right thing to do. If you have native movie sources (telecined to 25i/30i) you can switch madVR into film mode (see keyboard shortcuts) and you'll get 24p/25p output instead of 50p/60p.

Some day in the future I hope to be able to automatically switch between DXVA deinterlacing and madVR's IVTC. But that won't come any time soon.

Originally Posted by DragonQ

If the material is interlaced, that's what's supposed to happen (50/60p after deinterlacing). If it's progressive material in an "interlaced wrapper" (e.g. films or dramas in a TV stream) then it should be detected as such and deinterlaced using "weave", reproducing the original progressive image (25/30p after deinterlacing).

Unfortunately DXVA2 is not telling anybody which content type it detected during deinterlacing. At the same time it's not DXVA2 which decides the framerate, but the renderer. So madVR always outputs double framerate when deinterlacing with DXVA2.

Originally Posted by MSL_DK

I do not know if it's ycms who fails or it is the way madVR handle ycms ... but something's wrong

Unfortunately I don't have access to the yCMS sources so I can't say what's wrong exactly or fix the problem myself. However, I would guess that inconsistencies in your measurements might be the problem.

Originally Posted by DarkSpace

Many thanks for this piece of work, it's really great! However, I'd like to report a possible bug:
When switching the screen refresh rate (manually, not using the automatic Refresh Rate Changer) to 120Hz on my Laptop's internal 1080p screen, madVR stops outputting a picture. The Media Player window still changes its size to the video resolution in Windowed Mode, but both Fullscreen Exclusive and Windowed Mode only show a black picture. Interestingly, the Debug OSD (already enabled from before swit) doesn't display in Windowed mode, but in FSE, it briefly shows an additional line

Desktop Composition Rate: 120.000Hz [there are a few trailing zeros, but I couldn't count them]

before that line vanishes, but the interesting part is that it shows

display 0.000000Hz

It doesn't update during playback at all, and when the playback is paused, it only updates the Render Queue. I have included a Debug Log of a few seconds of video playing for both Windowed Mode and FSE. Also interesting is that while the screen stays blank except for the Debug OSD, the FSE seekbar does show up, albeit with a delay of a few seconds. Also, after a while, it seems MPC-HC just hangs, because audio also stops playing. In the case of the Debug logs, the audio stopped at around 25 seconds.
I should mention that EVR-CP works perfectly fine.
My Setup:

AMD Radeon HD 670M with up-to-date drivers
Windows 7 Ultimate
MPC-HC 1.6.5.6291
LAV Filters 0.54.1
ReClock 1.8.7.9
madVR 0.85.1

I did use the search and didn't find anything alike. Unfortunately, I don't have any other screens capable of 120Hz at all, so I can't test if it's maybe my drivers' fault.

There was one other user with 120Hz which reported the same problem many months ago. The problem is that madVR tries to find a pattern in the VSync scanline position readings (which are done in high frequency by madVR) and it seems that sometimes when using 120Hz madVR has a problem finding a reliable pattern. As a result madVR is unable to figure out the exact refresh rate and when exactly the VSync interrupts will occur in the future. This is needed for playback, though, because the whole madVR presentation logic is based on syncing the frames to the future VSync interrupts. I would really like to fix this problem, but it's going to be hard without having a 120Hz display for testing, and unfortunately all my displays top out at 60Hz at the moment...

Originally Posted by DragonQ

I'm sure I've mentioned this before but auto-detection of deinterlacing seems to be broken for some HDTV (UK) streams in MKVs (maybe other types of files too, dunno). The same streams in TS files deinterlace fine, and the MKVs deinterlace fine in EVR too. Using LAV Splitter/Video/Audio.

EDIT: On second thoughts, I think this is probably an issue in MKV Merge. My older MKVs work fine, newer ones don't. If it is, Mosu needs to know why the interlacing isn't detected properly so can you help with this please madshi?

The problem is the framerate in the MKV header. It says 50p. LAV Splitter reads that and passes it on to the decoder. The decoder passes that forward to madVR and that's why madVR decides not to deinterlace the video because madVR generally does not deinterlace 50p or 100i content.