madVR - high quality video renderer (GPU assisted)

[chros]

Originally Posted by ibius

On a side note, did anyone with a '8-bit + FRC' panel make some tests displaying 10-bit with madVR with dithering disabled to compare panel's dithering to that of madVR?

Well, since panel dithering is always on you can't really compare them. But I can't see any difference between 10 bit without madvr dithering and 8 bit with madvr dithering from 10 cm (usual viewing distance is 3m )

Originally Posted by ibius

And, is madVR's Ordered dithering enough to smooth out the gradients of a dithered 10-bit on a 8-bit panel or is Error Diffusion required?

Again, I don't see any difference from 10cm, so Ordered dithering would be fine.

Originally Posted by huhn

only testing will tell you this. i guess 6 bit will be better. seeing a difference shouldn't be really hard.

Originally Posted by Asmodian

In my testing I preferred madVR set to 6-bit on a 6-bit panel but I am sure it depends on the display.

Just checked on my laptop display (6bit+FRC, advertised as 16.02 million colors) with the 16 bit gradient test png image (dithering set to none in madvr): you can definitely see the difference between 6 and 8 bit output (but not above 8). So use 8bit output and ordered dithering.

Originally Posted by enphenate

Dang that sucks, my 4 year old LG 37LD450 passed 4:4:4 at all of the lower refresh rates

Really? How? With which refresh rates? With which hdmi port? Using dvi-hdmi? What's your graphics card?
I have the big brother but (no matter what I did) I didn't managed to get 4:4:4 with any combination that I've tried. I have to say I use hdmi-hdmi from my laptop. And this review also says that they couldn't make it work: http://www.hdtvtest.co.uk/news/lg-32...0101120901.htm

Originally Posted by enphenate

Im still confused at what the best option would be to use with MadVR? 4:4:4 60hz with limited calibration ability or 23hz with full calibration ability but not passing 4:4:4.

"with limited calibration ability" : if you have a meter than just create a 3dlut so you won't miss any of the calibration settings of your tv.
The 23hz vs 60hz is a different matter, just try it out how it looks.

Btw: do you know any display device (tv or projector) that can do 4:4:4 via hdmi-hdmi AND 23hz or 24hz???

[SweetLow]

Originally Posted by enphenate

my 4 year old LG 37LD450 passed 4:4:4 at all of the lower refresh rates

Originally Posted by chros

Btw: do you know any display device (tv or projector) that can do 4:4:4 via hdmi-hdmi AND 23hz or 24hz???

don't comment last post only, view the full thread

[Nullack]

Help please.

* Reducing GPU buffers reduces the GPU memory footprint which with just 2GB on 4K material is good for my setup especially given the need to run copyback DXVA 2 with madVR. Is there any practical problem with running just 4?

* Since I run 64bit builds of LAV, MPC-BE and madVR, and I have ample system ram at 16GB, I see no reason to change cpu decoding buffers from default. Does more of less than default decoding buffers have any practical impact?

* Whats with present frames in advance? Why do this? If it is a good thing, how many should be done? Whats the relevant factors with deciding on this setting?

Thanks

[chros]

Originally Posted by SweetLow

don't comment last post only, view the full thread

Errr ... What do you mean? He was talking about the Samsumg tv latter on not the LG.

[ShadyCrab]

Not sure what part of the chain is the problem here, but the exact same video is being detected as having BT.601 primaries on one opening and BT.709 on the next. I've noticed this bug on other videos too. Whats worse, is that it actually changes the color of the video (mainly in the greens). Is this a video encode bug or an actual bug in madVR/LAV's detection code (also using) xySubFilter and MPC-HC). So far its only on videos were instead of the matrix being 'best guess' its 'upstream' for the matrix and 'bitstream' for the primaries (on videos were in the mediainfo just the matrix has been set as BT.709, leaving the primaries guess to the chain).

http://i.j2.io/9EM0.png
http://i.j2.io/8T2O.png
(size difference is due to poor screenshot lossless PNG crop, not due to different frame. Color difference is there on madVR itself).

[nevcairiel]

Originally Posted by ShadyCrab

Not sure what part of the chain is the problem here, but the exact same video is being detected as having BT.601 primaries on one opening and BT.709 on the next. I've noticed this bug on other videos too. Whats worse, is that it actually changes the color of the video (mainly in the greens). Is this a video encode bug or an actual bug in madVR/LAV's detection code (also using) xySubFilter and MPC-HC). So far its only on videos were instead of the matrix being 'best guess' its 'upstream' for the matrix and 'bitstream' for the primaries (on videos were in the mediainfo just the matrix has been set as BT.709, leaving the primaries guess to the chain).

http://i.j2.io/9EM0.png
http://i.j2.io/8T2O.png
(size difference is due to poor screenshot lossless PNG crop, not due to different frame. Color difference is there on madVR itself).

If this info would be present in the bitstream, than it would also be coming from upstream LAV, and not leave madVR having to get it from the bitstream itself. Sounds like a bug in madVR to me. A sample video that shows this problem will be required, however.

[madshi]

Originally Posted by huhn

I don't know why a soft telecine DVD remux oder vob is treated as progressive but played back at 29p by default.

that looks pointless to me.

If it's *soft* telecine then it should be played at 23p if deinterlacing is disabled. Are you sure it's 29p? If it is, then it's probably not soft telecined.

Originally Posted by huhn

a soft telecine source is flagged progressive that's why deinterlacing isn't used.

Because HD DVDs and D-Theater captures are soft telecined and play perfectly with deinterlacing disabled. There are even some (rare) Blu-Rays with this mode. But if you want deinterlacing to be used for such sources, simply change your madVR settings to "if in doubt, activate deinterlacing". That's what that setting is for.

Originally Posted by aufkrawall

I'm aware that you don't necessarily share the opinion that everything must be open, which is totally fine as I agree that intellectual property should be valued. But is there a chance that you explain at some point how sharpen edges works?

Sorry, but no. It's also not necessarily the final version yet. It's a work in progress. I already have some plans to further improve it, at least the anti-ringing part of it.

Originally Posted by py930828

should I add MADVR into NVIDIA control panel? Since so far, I only set MPC-HC run by NVIDIA graphics card but not MADVR, I don't know what application I should choose to put into the control panel.

Your media player.

Originally Posted by py930828

These two pictures, when I was in windows mode, the render and present queue is full, but if I am in fullscreen, the queue drop to 2, and the present time is really really long.

Don't attach pictures to this forum, they often don't get approved, or with very long delays.

Originally Posted by py930828

I found the problem!!! The reason why the render queue and the present queue drop is because of DX11, if I set it to DX9 in "general setting", the queue will get back to full, and the presenting time goes back from 16ms to 2ms(in full screen case). However, there are two problems that I have found so far:

1. In DX9 mode, I can't use the exclusive mode since once I able exclusive mode, the full screen is just going to be black screen.

2. Instead of the increasing of dropped frame in DX11 mode, DX9 mode increases presentation glitches a lot, one completely movie might have 200 more presentation glitches.

Again, just a reminder, I am using a laptop with 3630QM+970M, do you think this can be a problem?

Is that an Optimus laptop? Those are known to have certain problems. You could try installing a different driver version, maybe it helps.

Originally Posted by py930828

There are some screen shots that might give you some information

I can't even see them because they're not approved (see above).

Originally Posted by har3inger

@madshi: the OSD font size (and maybe the font itself) changed a lot with the latest version. Is this intentional?

Yes. Forgot to mention it in the changelog.

Originally Posted by dbcooper

Hi Madshi, if you choose "use half frame rate for deinterlacing", the frame time on the OSD does not change. This is with DXVA deinterlacing.

It does for me. It says: "vsync 16.68ms, frame 16.68ms" with (DXVA) deinterlacing active and "vsync 16.68ms, frame 33.37ms" if I manually disable deinterlacing.

Originally Posted by Aktan

Which is why I think if there was an option to delay playback until decoder queue is full, then there be no problem. This is a capture source. If this capture source is to be reliable to capture at full framerate all the time, the computer must be fast enough and compress it fast enough, else there be drop frames. I can trust my computer can capture fine and that once the decoder queue is full, would stay full even if it can't deliver frames faster than realtime.

Edit: I just realized, why isn't the render queue delayed until full? When I first start playback, it isn't like the render queue is full then slowly goes down to 0-2. It's 0-2 from the start.

Your source filter simply doesn't deliver frames. I've told you before, the source filter should push frames until madVR blocks. But your source filter does not. There is NOTHING I can do to make the queues fill. It's the responsibility of your source filter. The key problem is that madVR's "delay" feature waits for frames to come from the source filter while the graph is still in paused mode. And in that mode it seems that your source filter doesn't send more than 1-2 frames. It only starts sending frames when playback in unpaused, and it never sends frames fast enough ("in advance") to allow the queues to fill.

Originally Posted by 6233638

I actually thought he had done that in this version.
I was just about to write up a post asking about the GUI changes because I find them difficult to read on my 1080p screen.
With this build I'm now seeing a big proportionally spaced and anti-aliased font (with bad keming) vs the old monospaced bitmap font.
It's worse in a window because the new stats now scale with the window size and get a lot smaller than the old ones.

I'm scaling the font size with the window/screen size now. I've tried many different fonts and spent many hours on this, trying to find a good solution. The biggest problem is that most fonts don't support grayscale anti-aliasing at smaller font sizes. The fonts must be rather big for them to start supporting grayscale AA. ClearType AA is supported at small font sizes, but looks terrible when transparently blended over the video frame as madVR does. So the font I'm not using (which is actually the Windows default GUI font) was the "best" compromise I could find. It's one of the VERY few fonts which supports anti-aliasing at smaller font sizes. Most other fonts look very thin and are thus also hard to read at smaller font sizes.

It's true that the font size is now allowed to get smaller if your playback window is very small. The purpose of that is to fit more of the stats into the window. If I didn't do that, the font size would be bigger which is easier to read, but a lot of the OSD content would then be cut off.

Originally Posted by SweetLow

It's possible (and i use it more then decade already - to increase monitor luminance on the fly to view video and pictures ), but, AFAIK, there is no standard user mode API to access this feature under Win platform.

Ok, but how many displays, especially how many TVs support that?

Originally Posted by Probe

Thanks for the response...just before providing the OSD...I decided to play with some additional settings...I eventually resolved the issue by changing the downscale setting from Lanczos to DXVA2.

Makes no sense to me that this would change anything related to HDR.

Originally Posted by SweetLow

no success with non ascii symbols in path! - to madshi

You mean chinese or russian characters? Or what do you mean?

Originally Posted by Nullack

* Reducing GPU buffers reduces the GPU memory footprint which with just 2GB on 4K material is good for my setup especially given the need to run copyback DXVA 2 with madVR. Is there any practical problem with running just 4?

Bigger is better, but 4 should work ok, too.

Originally Posted by Nullack

* Since I run 64bit builds of LAV, MPC-BE and madVR, and I have ample system ram at 16GB, I see no reason to change cpu decoding buffers from default. Does more of less than default decoding buffers have any practical impact?

Higher CPU/decoder queue means more protection against CPU spikes causing the decoder queue to get empty. But usually the default should be fine.

Originally Posted by Nullack

* Whats with present frames in advance? Why does this? If it is a good thing, how many should be done? Whats the relevant factors with deciding on this setting?

That's the size of the present queue. If your GPU queue is set to 4 frames, probably it would make sense to reduce the present queue size to 4, too, except if you're using smooth motion FRC. The frame presented in advance are frames which madVR has already sent to Direct3D for presentation. So they're out of madVR's hands, and even out of the responsibility of the media player process. Usually this increases reliability against frame drops.

It would be good if you could make up your mind if you want support for your specific playback problems in this thread, or in your own thread, because if you ask in both threads, questions and answers might overlap, causing me more support work. Thanks.

[madshi]

Originally Posted by ShadyCrab

Not sure what part of the chain is the problem here, but the exact same video is being detected as having BT.601 primaries on one opening and BT.709 on the next. I've noticed this bug on other videos too. Whats worse, is that it actually changes the color of the video (mainly in the greens). Is this a video encode bug or an actual bug in madVR/LAV's detection code (also using) xySubFilter and MPC-HC). So far its only on videos were instead of the matrix being 'best guess' its 'upstream' for the matrix and 'bitstream' for the primaries (on videos were in the mediainfo just the matrix has been set as BT.709, leaving the primaries guess to the chain).

http://i.j2.io/9EM0.png
http://i.j2.io/8T2O.png
(size difference is due to poor screenshot lossless PNG crop, not due to different frame. Color difference is there on madVR itself).

Originally Posted by nevcairiel

If this info would be present in the bitstream, than it would also be coming from upstream LAV, and not leave madVR having to get it from the bitstream itself. Sounds like a bug in madVR to me. A sample video that shows this problem will be required, however.

^

Yep - sample, please! I need to be able to reproduce this on my PC.

[madshi]

SUBTITLES - HELP

Today I wanted to look into the problem of moving subtitles into black bars not always working as expected. It has been reported to me that e.g. moving SRT subtitles into the black bars stops working if the SRT contains <i>italic</i> subtitles. So I've tried to reproduce that just now, but can't!

Does anybody have any sample with which I can reproduce that moving subtitles into the black bars works at first, but then stops working at some point?

[KoD]

Originally Posted by py930828

I tried windows overlay, mpc shows "creating Direct3D device failed (8876087b), I disable both FSE and DX11

If you are having issues with DX9 mode, maybe you don't have the DirectX 9 runtime installed? Run the web installer from here just to make sure.

[chros]

Originally Posted by KoD

If you are having issues with DX9 mode, maybe you don't have the DirectX 9 runtime installed? Run the web installer from here just to make sure.

Or is it an optimus system?

[SweetLow]

Originally Posted by madshi

Ok, but how many displays, especially how many TVs support that?

TVs? Almost none, AFAIK (and see IRL). Only monitors - and i use this on monitors (first Samsung 959NF, then Dell 2707WFP) at my primary PC (to view short videos), not theater PC.

Originally Posted by madshi

You mean chinese or russian characters? Or what do you mean?

Russian(Cyrillic). But - ANSI CP is 1251 (and OEM 866) on my PC - and if you internally use AnsiStrings - it shall not be a problem, i assume.

[aufkrawall]

Originally Posted by madshi

Sorry, but no.

No problem. I'm glad we have it in madVR though.

Different issue:
I'm instantly getting lots of dropped frames when I enable black bar detection for a HEVC 10 bit 4k 50fps video. Neither GPU nor CPU load is at max, so probably performance can be improved?
The video plays fine without it (except of some weird high bitrate locations).
CPU is a 4770k@4.1Ghz and GPU 780 Ti@1.2Ghz.

[huhn]

Originally Posted by madshi

If it's *soft* telecine then it should be played at 23p if deinterlacing is disabled. Are you sure it's 29p? If it is, then it's probably not soft telecined.

yes i'm sure it is soft telecine and the reported fps is 29.90 fps says source filter even with "if in doubt, activate deinterlancing".

some extra informations.
software decoding with IVTC sees 3:2.
quiicksync decoding with IVTC sees 2:2 (no repeat flags)

and there is no combed file in the whole source.

and ffmpegsource uses 23p for it.

[madshi]

Originally Posted by SweetLow

Russian(Cyrillic). But - ANSI CP is 1251 (and OEM 866) on my PC - and if you internally use AnsiStrings - it shall not be a problem, i assume.

Should be unicode, but I'll check.

Originally Posted by aufkrawall

I'm instantly getting lots of dropped frames when I enable black bar detection for a HEVC 10 bit 4k 50fps video. Neither GPU nor CPU load is at max, so probably performance can be improved?

Yes, I'm aware of the problem. It will be fixed soon(ish).

Originally Posted by huhn

yes i'm sure it is soft telecine and the reported fps is 29.90 fps says source filter even with "if in doubt, activate deinterlancing".

That's just what the decoder reports, but not what madVR actually draws. Try frame stepping again, you should be seeing 24fps not 30fps.

[huhn]

Originally Posted by madshi

That's just what the decoder reports, but not what madVR actually draws. Try frame stepping again, you should be seeing 24fps not 30fps.

the issue is that madVR isn't switching to 23p if possible and madVR isn't using smoothmotion at 60 hz with these sources.

[dansrfe]

OSD upscaling works great, however the text is hard to read when height is less then ~630px or within the smallest OSD size range.

Should peak luminance be set to 265nit for a 300nit (measured) display?

[huhn]

set it to what's looks best to you.

[Marsu42]

Is there some non-linear stretch option with MadVR I'm not finding in the various options ... i.e. like ffdShow warped resize or Cyberlink PanoVision(tm)(r)(c)(wtf)?

If not, would it be possible to implement this - the various tv sets all seem to have a 4:3->16:9 non-linear stretch feature as it's so convenient for watching older content on a newer wide-screen display. The catch with ffdShow is that it's software-only and is stuttering esp. when enabling other post filters.

[py930828]

Originally Posted by madshi

If it's *soft* telecine then it should be played at 23p if deinterlacing is disabled. Are you sure it's 29p? If it is, then it's probably not soft telecined.


Because HD DVDs and D-Theater captures are soft telecined and play perfectly with deinterlacing disabled. There are even some (rare) Blu-Rays with this mode. But if you want deinterlacing to be used for such sources, simply change your madVR settings to "if in doubt, activate deinterlacing". That's what that setting is for.


Sorry, but no. It's also not necessarily the final version yet. It's a work in progress. I already have some plans to further improve it, at least the anti-ringing part of it.


Your media player.


Don't attach pictures to this forum, they often don't get approved, or with very long delays.


Is that an Optimus laptop? Those are known to have certain problems. You could try installing a different driver version, maybe it helps.


I can't even see them because they're not approved (see above).


Yes. Forgot to mention it in the changelog.


It does for me. It says: "vsync 16.68ms, frame 16.68ms" with (DXVA) deinterlacing active and "vsync 16.68ms, frame 33.37ms" if I manually disable deinterlacing.


Your source filter simply doesn't deliver frames. I've told you before, the source filter should push frames until madVR blocks. But your source filter does not. There is NOTHING I can do to make the queues fill. It's the responsibility of your source filter. The key problem is that madVR's "delay" feature waits for frames to come from the source filter while the graph is still in paused mode. And in that mode it seems that your source filter doesn't send more than 1-2 frames. It only starts sending frames when playback in unpaused, and it never sends frames fast enough ("in advance") to allow the queues to fill.


I'm scaling the font size with the window/screen size now. I've tried many different fonts and spent many hours on this, trying to find a good solution. The biggest problem is that most fonts don't support grayscale anti-aliasing at smaller font sizes. The fonts must be rather big for them to start supporting grayscale AA. ClearType AA is supported at small font sizes, but looks terrible when transparently blended over the video frame as madVR does. So the font I'm not using (which is actually the Windows default GUI font) was the "best" compromise I could find. It's one of the VERY few fonts which supports anti-aliasing at smaller font sizes. Most other fonts look very thin and are thus also hard to read at smaller font sizes.

It's true that the font size is now allowed to get smaller if your playback window is very small. The purpose of that is to fit more of the stats into the window. If I didn't do that, the font size would be bigger which is easier to read, but a lot of the OSD content would then be cut off.


Ok, but how many displays, especially how many TVs support that?


Makes no sense to me that this would change anything related to HDR.


You mean chinese or russian characters? Or what do you mean?


Bigger is better, but 4 should work ok, too.


Higher CPU/decoder queue means more protection against CPU spikes causing the decoder queue to get empty. But usually the default should be fine.


That's the size of the present queue. If your GPU queue is set to 4 frames, probably it would make sense to reduce the present queue size to 4, too, except if you're using smooth motion FRC. The frame presented in advance are frames which madVR has already sent to Direct3D for presentation. So they're out of madVR's hands, and even out of the responsibility of the media player process. Usually this increases reliability against frame drops.

It would be good if you could make up your mind if you want support for your specific playback problems in this thread, or in your own thread, because if you ask in both threads, questions and answers might overlap, causing me more support work. Thanks.

Madshi, what is the difference between using DX11 or DX9? Does DX11 works better or?