madVR - high quality video renderer (GPU assisted)

[Niyawa]

That must have been random measurement spikes. Technically, all 2-tap algorithms (SoftCubic, Bicubic, Mitchell-Netravali, Catmull-Rom) in madVR use *exactly* the same shader code. Also all 3-tap algorithms (Lanczos3 and Spline3) use exactly the same shader code. The only thing that differs is a lookup table with weights. So performance should be 100% identical between e.g. Lanczos3 and Spline3. Performance depends only on the number of taps, nothing else. Oh, except for Jinc, of course, which is totally different from everything else.

Bicubic and Mitchell-Netravali have exactly the same performance. So the difference between Mid-tier and Low-tier doesn't make much sense to me.
That's what I don't understand. You're the developer so my word is weak but when I set M-N to chroma upscaling, either Spline or Lanczos slow downs a lot in the downscaling, and with Bilinear that doesn't happen. The only thing I could assume is that M-N is a little bit more power-consuming than Bilinear. Of course, as you said, it may be a measurement spike but I've tried several times already and in all of those it's the same result.

Generally, Bicubic 75 already has quite strong ringing. I think Bicubic 75 is a good chroma upsampling algorithm if you have the AR filter enabled. But without AR it might make sense to ease up a little on the sharpness and use maybe Catmull-Rom instead. So my suggestion would be to use Catmull-Rom for Mid- and Low-tier, as a compromise between ringing, aliasing and desaturation. Not sure if 6233638 will agree with me, though... :p Rest can stay as it is.
Well, he was the one who said Bicubic 75 is likely the best option (at the expense of lower ringing) but if that is with AR enabled then it comes to the case of vantages x disadvantages ratio. For now I'll keep it Catmull-Rom as a safe measure. Unless 6233638 has anything to add.

Actually, I'm planning to change madVR's defaults to Chroma Catmull-Rom, Image-Up Lanczos3 and Image-Down Catmull-Rom in the next madVR build. All without AR and without linear light, so that even "low-tier" can run smoothly. Also I'm planning to enable the trade quality for performance option "use half framerate for DXVA deinterlacing" by default. Ouch. You may want to consider enabling that option, too, for low- and lowest-tier, just to make sure even 1080i60 content runs fine.
I don't know much about deinterlacing or calibration options in general yet, I'll take a look (though it did seems a little extreme like nev said). Thanks for sharing your opinion.

I'm also a little curious about what and how buffers and the flush options can influence the video performance. Anyone mind sharing what they know about it?

[Asmodian]

That's what I don't understand. You're the developer so my word is weak but when I set M-N to chroma upscaling, either Spline or Lanczos slow downs a lot in the downscaling, and with Bilinear that doesn't happen. The only thing I could assume is that M-N is a little bit more power-consuming than Bilinear. Of course, as you said, it may be a measurement spike but I've tried several times already and in all of those it's the same result.


madshi didn't say anything about Bilinear, Bilinear is faster. The difference between Mid and Low doesn't make much sense, not Lowest. ;)

I'm also a little curious about what and how buffers and the flush options can influence the video performance. Anyone mind sharing what they know about it?

Keep them at the defaults. :)

edit: they are for dealing with diver and/or other issues, not performance per se.

Any opinions on this? Am I going crazy by planning to enable the "use half framerate deinterlacing" option by default?

Until recently, a few years ago being recent, "we" thought of half framerate deinterlacing as "normal deinterlacing" and full framerate deinterlacing as "double-rate deinterlacing" because most systems didn't play 60 fps content well.

I think the general public will not notice the half rate deinterlacing but would notice the choppyness from an underpowered GPU trying to do 60 fps. Anyone who gets annoyed by half-rate deinterlacing can change the setting and be happy (like me).

People who have a vague idea what we are talking about think video is 30i and would expect 30p when deinterlaced as this sounds like the same frame rate.

Is MadVR for everyone or only for those who have the hardware to support no-compromise maximum video quality?

As one who wants no compromise max video quality but thinks MadVR is mature enough for everyone to use I am happy to have to change a setting or two from the defaults if it improves the experiences of a large group of people who don't change settings. This does start to move away from "max quality > all" and it seems more significant than not setting Jinc as the default resize but I still think it is a good idea.

Just my 2c. :)

[DragonQ]

I think the general public will not notice the half rate deinterlacing but would notice the choppyness from an underpowered GPU trying to do 60 fps. Anyone who gets annoyed by half-rate deinterlacing can change the setting and be happy (like me).
The general public probably also don't notice the ridiculous bit rate squeezing on a lot of SDTV channels now, which makes them look like arse (partly to promote HD). That's no reason to accept it and move backwards in the continuing fight for quality.

Is MadVR for everyone or only for those who have the hardware to support no-compromise maximum video quality?
As I understand it, the latter. However, there are plenty of compromises that can be made before removing half of the bloody frames! :eek:

[Asmodian]

It is just the default but I don't feel strongly either way. I like playing with settings and I don't really know how many systems that can do DXVA deinterlacing have trouble with full-rate deinterlacing.

I do know that most of the time I cared about on-the-fly deinterlacing I didn't have a system that could play 60 fps content and I thought 30i -> 30p looked good.

I cannot think of any other compromises that would have a less significant impact on perceived quality while having a similar impact on performance.

[pie1394]

I don't agree that interlaced content is rare. Almost all TV is interlaced. Only films, drama series and some comedy series are typically progressive.

For HDTV programs in US, they are also broadcasted with MPEG-2 1280x720p60 format. It has higher vertical motion resolution (sensitive to human eyes) if compared to video stream encoded with 1920x1080i30 mode at the same bit rate.

Unfortunately 1080p24 HDTV video encoding format is only defined in ATSC system. So the FILM type DTV contents outside the North America (US, CA) need to send out via either of following 2 ways:

1. Make it telecined to i60. So the compressed MPEG-2 / H.264 video are actually 60 field images in 30 fps. The TV's post-processing engine detects if the decoded video is truly progressive and perform the IVTC process.
(Old day's many NTSC DVDs were also made in this way when the DVD player capable of 24fps progressive output was not popular...)

2. Just make the telecine flags (i.e. field first order, repeat field) in MPEG-2 / H.264 video header, and the video stream is still encoded with 24 full-frame image mode. The TV performs necessary post-processing depending on the display characteristics. Ex:

- 1080i CRT / ALiS PDP --> Telecine.
- Progressive PDP --> 48 / 72 / 96 fps panel driving
- Progressive LCD --> 120 Hz driving + black-image insertion with scanning LED backlight

The 2nd way is now widely used. The progressive full-frame often needs less bit rate to achieve the same video quality with the interlaced field-frame's. The DVD player / TV settop box is also cheaper to be made in order to achieive better FILM contents' video display quality.



I also doubt many GPUs fail to playback 1080i/30 content properly in EVR. Maybe Brazos but surely not much else - even the old Intel HD Graphics IGP can do it.

With EVR, the graphics driver utilizes the optimized processing pipelines inside the GPU. For the entry level GPU, which has very limited computation power and memory bandwidth, the image quality is not usually the first priority, but the smoothy playback.

[crotecun]

I don't know. Generally, I don't really recommend using DXVA scaling for ATI and NVidia users. But the option is there, if you want to use it. And of course I'm interested in fixing bugs, if any more show up.



I'm really liking DXVA scaling, after fixing my issues it works pretty well and gives decent quality on my ATI card. :thanks:



Actually, I'm planning to change madVR's defaults to Chroma Catmull-Rom, Image-Up Lanczos3 and Image-Down Catmull-Rom in the next madVR build. All without AR and without linear light, so that even "low-tier" can run smoothly. Also I'm planning to enable the trade quality for performance option "use half framerate for DXVA deinterlacing" by default. Ouch. You may want to consider enabling that option, too, for low- and lowest-tier, just to make sure even 1080i60 content runs fine.



I'm of the opinion we should keep the current 0.85 defaults, which are:

The new default scaling settings are Lanczos3 AR for image upscaling, Catmull-Rom AR with Linear Light for downscaling and Bilinear for Chroma.

As much as I want to avoid a slippery slope fallacy this is what the quest for satisfying the "low-tier" is looking like, eventually we'll end up just fielding bilinear on all three scalings and if that happens what's the point of switching from EVR-CP? :eek:

Let's take a step back and give the current 0.85 defaults some time, it's OK as it's not yet a version 1.0 release. As a relatively new user of the software I don't really see the defaults as the minimum settings, but the recommended; I view it as a reference point for what madvr's output should look like. Anything lower and I practically can't see the difference with other renderers.

After all if my video card couldn't keep up, I wouldn't want madvr to scale down for me, I'd try instead to upgrade my hardware so I can see what other madvr users could see. And I honestly believe many people coming to this thread think this way too with the frequent questions of what video card would be future-proof with madvr. :)

[iamhacked]

I'm getting static glitches on my Dimension E521 (Nvidia GeForce 6150LE). Graphic driver is latest I believe. I disabled separate device for presentation, and using Bilinear for chroma and DXVA for rest. What could be causing this?

[Niyawa]

madshi didn't say anything about Bilinear, Bilinear is faster. The difference between Mid and Low doesn't make much sense, not Lowest. ;)
Oops, I thought Bilinear was in the same group. Good to know it was just my misunderstanding.

Keep them at the defaults. :)

edit: they are for dealing with diver and/or other issues, not performance per se.
I see, thanks.

[ajp_anton]

The "use half frame rate for DXVA processing" is already quite agressive.I meant for "normal" videos =). To make it comparable to EVR in performance (and power consumption).
Interlacing is dead to me and I try to avoid it at all cost.

[Asmodian]

I'm getting static glitches on my Dimension E521 (Nvidia GeForce 6150LE). Graphic driver is latest I believe. I disabled separate device for presentation, and using Bilinear for chroma and DXVA for rest. What could be causing this?

What do you mean by static glitches? The only "GeForce 6150LE" I can find is very slow by today's standards, it is a seven year old integrated video part. I don't think it is good enough for MadVR at any setting.

The integrated Intel HD4000 is around 21 times faster.

[squall12]

Hi guy,

I only play blu ray movie mkv format which include 720p and 1080p so what setting is best for me using madvr with mpchc.

PC Spec.
Intel iCore 5 3570 3rd generation.
ATI 7750
4gb Memory.

Thanks

[6233638]

Actually, I'm planning to change madVR's defaults to Chroma Catmull-Rom, Image-Up Lanczos3 and Image-Down Catmull-Rom in the next madVR build. All without AR and without linear light, so that even "low-tier" can run smoothly.I'm not sure about Catmull-Rom for chroma upscaling. In some tests, I can definitely see aliasing introduced with it, even in real-world material. It's also not quite sharp enough to maintain the correct brightness/sharpness for chroma, and still rings quite a bit. I feel like it's an in-between option that has all three of the bad traits; aliasing, ringing, and loss of brightness/saturation to some degree. I would prefer an algorithm that only had two of them.

Bicubic 75 mostly only exhibits ringing. (which almost disappers with the AR filter)

In some ways, I wonder if Mitchell-Netravali might actually be the best choice as a default, even though it's definitely not my preference for chroma upscaling.

The reason being that most people are probably only used to seeing bilinear scaling applied to the image for chroma upscaling. Even Mitchell-Netravali can have more ringing than Bilinear in some cases (but usually not) though Mitchell-Netravali is definitely an improvement over bilinear when it comes to aliasing and sharpness.

Bicubic 75 is the first option where aliasing is mostly not a problem though. I can find examples where there is still aliasing with Mitchell-Netravali or Catmull-Rom, that don't have any (or a minimal amount) with Bicubic 75.

Lanczos 3 (no AR) for the luma upscaling:
http://www.abload.de/img/alldajg4.gif

At 200% Bilinear, Mitchell-Netravali (http://www.abload.de/img/b-mn27kjv.gif)
Mitchell-Netravali, Catmull-Rom (http://www.abload.de/img/mn-crggjeg.gif)
Catmull-Rom, Bicubic 75 (http://www.abload.de/img/cr-bcfcjjb.gif)
Bicubic 75, Jinc 8 (http://www.abload.de/img/bc-jc4k98.gif)
In particular, pay attention to the left of the A.

[ryrynz]

Why not Bicubic 75 with AR across the board until the high setting? High would be Jinc 3 AR and Ultra would be Jinc 8 AR.
It's not like Chroma processing is very demanding, if you absolutely had to you could disable AR at lowest tier (what is the lowest tier accommodating anyway?)
Just don't use bilinear on Chroma, it's nasty.

[jmone]

MN is a great choice if you are only using iGPU on the Intel CPU's as any of the "tap" based scalers are too demanding.

[madshi]

when I set M-N to chroma upscaling, either Spline or Lanczos slow downs a lot in the downscaling, and with Bilinear that doesn't happen.
Bilinear is very fast, much faster than anything else. It's not a 2-tap algorithm it's not even a 1-tap algorithm. It's more like 0.25-tap.

Well, he was the one who said Bicubic 75 is likely the best option (at the expense of lower ringing) but if that is with AR enabled then it comes to the case of vantages x disadvantages ratio. For now I'll keep it Catmull-Rom as a safe measure. Unless 6233638 has anything to add.
I have to correct my previous recommendation for chroma upscaling, when not using AR. See my reply to 6233638 at the bottom of this post.

I'm also a little curious about what and how buffers and the flush options can influence the video performance. Anyone mind sharing what they know about it?
Flush settings used to be important for older NVidia drivers which had a big bug in them, not allowing fullscreen exclusive mode to work properly. But that bug has been fixed for a few months now. Flush settings are also still in use by some CRT users for optimizing very high refresh rate output (120Hz etc). But other than that, I think the default flush settings should do for everyone.

The buffers are a complicated topic. On my NVidia 9400 mainboard, I have to increase the buffers and queues etc quite a bit to make 25fps @ 50Hz playback smooth. However, other users have reported that too high buffers makes things worse for them. Also, in fullscreen exclusive mode, higher buffers mean slower reaction when pausing playback or when showing any kind of OSD. So if the default settings work for you, there's no reason to change them. If your GPU should theoretically be fast enough, but you still get some stuttering, increasing the buffers and/or queues might sometimes help, especially in fullscreen exclusive mode.

Until recently, a few years ago being recent, "we" thought of half framerate deinterlacing as "normal deinterlacing" and full framerate deinterlacing as "double-rate deinterlacing" because most systems didn't play 60 fps content well.
Yes, that is my recollection, as well. However, when I tried to find hints about that yesterday via google, I failed. Did EVR ever only output 30 fps when using DXVA deinterlacing? I have in mind that a few years ago, the only way to get full (double) framerate deinterlacing with EVR was to use special decoders with a "double framerate" option. But EVR does seem to produce full framerate deinterlacing today with all decoders. So I'm wondering whether EVR always did full/double framerate and people just thought wrong a couple of years ago? I don't really know...

I think the general public will not notice the half rate deinterlacing but would notice the choppyness from an underpowered GPU trying to do 60 fps. Anyone who gets annoyed by half-rate deinterlacing can change the setting and be happy (like me).

People who have a vague idea what we are talking about think video is 30i and would expect 30p when deinterlaced as this sounds like the same frame rate.

Is MadVR for everyone or only for those who have the hardware to support no-compromise maximum video quality?

As one who wants no compromise max video quality but thinks MadVR is mature enough for everyone to use I am happy to have to change a setting or two from the defaults if it improves the experiences of a large group of people who don't change settings. This does start to move away from "max quality > all" and it seems more significant than not setting Jinc as the default resize but I still think it is a good idea.
Thanks, your thinking here is quite similar to mine. But it seems the majority vote is to keep full framerate deinterlacing active by default, so I'll do that.

I'm of the opinion we should keep the current 0.85 defaults, which are:

The new default scaling settings are Lanczos3 AR for image upscaling, Catmull-Rom AR with Linear Light for downscaling and Bilinear for Chroma.
The problem with the current default settings is the AR algorithm which seems to be a problem for many old GPUs. The previous default settings were without AR and I changed the default settings to ease up the GPU demands. But I fear I actually increased them with the new settings.

As much as I want to avoid a slippery slope fallacy this is what the quest for satisfying the "low-tier" is looking like, eventually we'll end up just fielding bilinear on all three scalings and if that happens what's the point of switching from EVR-CP? :eek:
There seems to be a general consensus on all forums that madVR should only be used for highest quality playback and that you need a bleeding edge GPU to use madVR. Now that madVR has pretty much all the features that EVR has, too (plus several more) I'd really like to get people to understand that madVR is not only about satisfying the highest quality demand people, anymore, but that it can be used very well with low-performance GPUs now, too (with lowered settings). Basically I want madVR to become the new default renderer for all but stone-age GPUs. But in order to make madVR attractive for owners of rather old/slow GPUs, I'd like to change the default settings to run smoothly even with old/slow GPUs. That doesn't have to stop anybody from changing the settings to get back all the lost quality.

Anyway, maybe I should delay this to v1.0 and then implement some kind of performance vs. quality slider or something like that. It just hurts me a little if I think of users trying madVR now and then dropping it again because the first impression is that it's too slow for their PC.

I'm getting static glitches on my Dimension E521 (Nvidia GeForce 6150LE). Graphic driver is latest I believe. I disabled separate device for presentation, and using Bilinear for chroma and DXVA for rest. What could be causing this?
Try Bilinear for everything. Your GPU is really slow, so you'll have to compromise on quality. Also try activating "use half framerate DXVA processing", if your content is interlaced and you can't get it smooth any other way.

P.S: What exactly do you mean with "static glitches"?

I only play blu ray movie mkv format which include 720p and 1080p so what setting is best for me using madvr with mpchc.
Try Jinc3 AR for image upscaling (disable linear light), Catmull-Rom AR with linear light enabled for image downscaling, and Bicubic75 AR for chroma upscaling. If that's too demanding for your GPU, try Lanczos3 AR for image upscaling instead.

Why not Bicubic 75 with AR across the board until the high setting? High would be Jinc 3 AR and Ultra would be Jinc 8 AR.
It's not like Chroma processing is very demanding, if you absolutely had to you could disable AR at lowest tier (what is the lowest tier accommodating anyway?)
Just don't use bilinear on Chroma, it's nasty.
Because AR is quite expensive on slower GPUs, even for chroma upscaling.

MN is a great choice if you are only using iGPU on the Intel CPU's as any of the "tap" based scalers are too demanding.
MN is 2-tap, just like Bicubic, SoftCubic and Catmull-Rom. That said, MN is a nice compromise algorithm.

I'm not sure about Catmull-Rom for chroma upscaling. In some tests, I can definitely see aliasing introduced with it, even in real-world material. It's also not quite sharp enough to maintain the correct brightness/sharpness for chroma, and still rings quite a bit. I feel like it's an in-between option that has all three of the bad traits; aliasing, ringing, and loss of brightness/saturation to some degree. I would prefer an algorithm that only had two of them.

Bicubic 75 mostly only exhibits ringing. (which almost disappers with the AR filter)

In some ways, I wonder if Mitchell-Netravali might actually be the best choice as a default, even though it's definitely not my preference for chroma upscaling.

The reason being that most people are probably only used to seeing bilinear scaling applied to the image for chroma upscaling. Even Mitchell-Netravali can have more ringing than Bilinear in some cases (but usually not) though Mitchell-Netravali is definitely an improvement over bilinear when it comes to aliasing and sharpness.

Bicubic 75 is the first option where aliasing is mostly not a problem though. I can find examples where there is still aliasing with Mitchell-Netravali or Catmull-Rom, that don't have any (or a minimal amount) with Bicubic 75.
You're right. I had in mind that Catmull-Rom had less aliasing than Mitchell-Netravali, but I was wrong about that (just checked the madVR scaling graphs). So I guess I agree with you to use either Mitchell-Netravali or Bicubic75 for chroma for good quality sources, when anti-ringing is disabled (SoftCubic for bad sources, though). It's probably a matter of taste which one to choose. Mitchell-Netravali has less ringing. Bicubic75 is sharper and has less aliasing, but has more ringing. Performance is the same.

[squall12]

thanks madshi and 1 question what is the correct way of updating the madvr latest version without losing my current config on the madvr?

[madshi]

Just unzip the new files and overwrite the old files, without deleting any old files.

[e-t172]

For HDTV programs in US, they are also broadcasted with MPEG-2 1280x720p60 format. It has higher vertical motion resolution (sensitive to human eyes) if compared to video stream encoded with 1920x1080i30 mode at the same bit rate.

Unfortunately 1080p24 HDTV video encoding format is only defined in ATSC system. So the FILM type DTV contents outside the North America (US, CA) need to send out via either of following 2 ways:

1. Make it telecined to i60. So the compressed MPEG-2 / H.264 video are actually 60 field images in 30 fps. The TV's post-processing engine detects if the decoded video is truly progressive and perform the IVTC process.
(Old day's many NTSC DVDs were also made in this way when the DVD player capable of 24fps progressive output was not popular...)

2. Just make the telecine flags (i.e. field first order, repeat field) in MPEG-2 / H.264 video header, and the video stream is still encoded with 24 full-frame image mode. The TV performs necessary post-processing depending on the display characteristics. Ex:

- 1080i CRT / ALiS PDP --> Telecine.
- Progressive PDP --> 48 / 72 / 96 fps panel driving
- Progressive LCD --> 120 Hz driving + black-image insertion with scanning LED backlight

The 2nd way is now widely used. The progressive full-frame often needs less bit rate to achieve the same video quality with the interlaced field-frame's. The DVD player / TV settop box is also cheaper to be made in order to achieive better FILM contents' video display quality.

What you're describing is how it should work in theory. In practice a surprising majority of broadcasters have absolutely no idea what they're doing and end up doing completely nonsensical processing. Basically:
- You're saying that "1080p24 HDTV video encoding format is only defined in ATSC system". You seem to be implying that in the US/CA, there should be some 1080p24 broadcasting. In practice, I've never seen any sign of it anywhere.
- You're describing the typical so-called "hard" (1) and "soft" (2) telecine methods. You're saying that soft telecine is now widely used. Ah, if only it was that simple… in practice, not only is hard telecine still in heavy use on almost all broadcasts, madshi and I have seen some mind-blowing horrors when developing our inverse telecine filters. Did you know that a number of broadcasts (e.g. TV shows on CBS) do not use soft or hard telecine exclusively, but instead switches back and forth constantly between the two, sometimes several times in the same second? Not only is this a completely brain-dead way of doing things, it makes developing inverse telecine algorithms much, much harder than necessary. And for what?

Thank god 1080p24 is supported natively (and universally used) on Blu-rays.

[pie1394]

What you're describing is how it should work in theory. In practice a surprising majority of broadcasters have absolutely no idea what they're doing and end up doing completely nonsensical processing. Basically:
- You're saying that "1080p24 HDTV video encoding format is only defined in ATSC system". You seem to be implying that in the US/CA, there should be some 1080p24 broadcasting. In practice, I've never seen any sign of it anywhere.

You are right... I should have said that progressive-mode encoding for FILM contents are actually only seen on modern Region 1 DVD and BluRay discs. :p

A lot of re-encoded Region3 DVD discs in my country are still made hard-telecined while the average bit rate is also reduced from Region1's 8.8 Mbps to 5 Mbps. It quite hurts the video's quality. Anyway most people have not seemed to care about it any more since BluRay came out.

Fortuantely it does not seem so stupid any more in the produced BluRay disc. My country is arranged to the same region with US regarding the BlueRay system. So I guess the producers don't actually re-encode the Hollywood-made contents again.



- You're describing the typical so-called "hard" (1) and "soft" (2) telecine methods. You're saying that soft telecine is now widely used. Ah, if only it was that simple… in practice, not only is hard telecine still in heavy use on almost all broadcasts, madshi and I have seen some mind-blowing horrors when developing our inverse telecine filters. Did you know that a number of broadcasts (e.g. TV shows on CBS) do not use soft or hard telecine exclusively, but instead switches back and forth constantly between the two, sometimes several times in the same second? Not only is this a completely brain-dead way of doing things, it makes developing inverse telecine algorithms much, much harder than necessary. And for what?


Thanks for the information!

I did not evaluate all US broadcaster's HDTV contents when I designed the video decoding systems for media player + SDTV recorder 5 years ago... So my experience is obviously not enough!

This indeed sounds quite funny. I am also curious why these professional real-time MPEG-2 encoding equipments can produce such strange behavior. :confused:

If I don't remember it wrong, the Japanese broadcasters send out the anime programs with hard-telecined i30 mode. The main contents are still 24 fps progressive while the Opening + Ending scenes / contents with horizontal-scrolling texts could be interlaced. Since it is not changed back and forth within 1 second, I guess it can be easily handled by the the algorithms designed by you guys. :D

[madshi]

I've seen switches between soft- and hard-telecine with DVDs, too, it's not limited to broadcasts. It's quite possible to handle this with a good IVTC algorithm, though. madVR should have no problems with this, even if it switches back and forth within 1 second. What I find more difficult is to stay in the cadence if there are heavy compression artifacts with hard-telecined content, if you want your IVTC algorithm to be able to react to bad edits quickly at the same time. Staying in cadence and reacting quickly to bad edits are contradicting goals. So it's hard to make both work without negatively effecting each other.

[SamuriHL]

Madshi, for now you could document in the op and the madvr read me what settings to use for various levels of hardware. Make the information widely and easily available. Then if someone tries the defaults and it's slow, they can quickly check the read me and determine what to change to make it work properly. The issue now is that information isn't obvious for a beginner and difficult to find. I just recently had to help someone tweak settings for an underpowered laptop and I wasn't even sure exactly what to tell them. After a bit of trial and error they got it. But it'd be easier if they could look in a doc and see what settings they should try. Hell you've got about 50 people in this thread will to do the write up... Just include it in the op and read me and then we just have to make it clear that info is out there.

Sent from my Xoom using Tapatalk 2

[DragonQ]

For HDTV programs in US, they are also broadcasted with MPEG-2 1280x720p60 format. It has higher vertical motion resolution (sensitive to human eyes) if compared to video stream encoded with 1920x1080i30 mode at the same bit rate.

Unfortunately 1080p24 HDTV video encoding format is only defined in ATSC system. So the FILM type DTV contents outside the North America (US, CA) need to send out via either of following 2 ways:

1. Make it telecined to i60. So the compressed MPEG-2 / H.264 video are actually 60 field images in 30 fps. The TV's post-processing engine detects if the decoded video is truly progressive and perform the IVTC process.
(Old day's many NTSC DVDs were also made in this way when the DVD player capable of 24fps progressive output was not popular...)

2. Just make the telecine flags (i.e. field first order, repeat field) in MPEG-2 / H.264 video header, and the video stream is still encoded with 24 full-frame image mode. The TV performs necessary post-processing depending on the display characteristics. Ex:

- 1080i CRT / ALiS PDP --> Telecine.
- Progressive PDP --> 48 / 72 / 96 fps panel driving
- Progressive LCD --> 120 Hz driving + black-image insertion with scanning LED backlight

The 2nd way is now widely used. The progressive full-frame often needs less bit rate to achieve the same video quality with the interlaced field-frame's. The DVD player / TV settop box is also cheaper to be made in order to achieive better FILM contents' video display quality.
I can't comment on 60 Hz regions but for 50 Hz regions, any progressive content is typically just broadcast as 1080i (films sped up from 24p to 25p beforehand). As long as the deinterlacer is half-decent, it'll notice a lack of movement between the fields and play it back using weave. No weird IVTC needed.

1080i/25 is also far more prevalent than 720p/50 in Europe.

[AndreaMG]

I'd really like to get people to understand that madVR is not only about satisfying the highest quality demand people, anymore, but that it can be used very well with low-performance GPUs now, too (with lowered settings). Basically I want madVR to become the new default renderer for all but stone-age GPUs. But in order to make madVR attractive for owners of rather old/slow GPUs, I'd like to change the default settings to run smoothly even with old/slow GPUs. That doesn't have to stop anybody from changing the settings to get back all the lost quality.
Anyway, maybe I should delay this to v1.0 and then implement some kind of performance vs. quality slider or something like that. It just hurts me a little if I think of users trying madVR now and then dropping it again because the first impression is that it's too slow for their PC.

You surely have a point, but I think people who use HTCPC and decide to go beyond power dvd, beyond VLC, beyond basic players, and begin to choose filters, etc. have knowledge of what they are doing and a person who tries MadVR and plays a file and sees that it stutters most probably will interrogate himself and he will play with settings, I don't think that he will simply go away from MadVR... There is also a risk that some people with strong GPUS will find the MadVR with the "easy default settings" perfectly play everything without even realizing that they are reproducing interlaced videos at half rate:)

[aufkrawall]

I think madVR should not sacrifice any quality over performance by default. That's what makes it different from other renderers and what it's known for, offering best quality for enthusiasts.
Maybe later there should be some kind of wizards or autodetection for slower hardware. Doubled framerate is the only real advantage of interlacing left, so why drop it? :devil:
And coming spring/summer there will be faster GPUs, leading to even more consumer hardware being able to handle madVR with very most content with the current default settings.

[druneau]

I think madVR should not sacrifice any quality over performance by default. That's what makes it different from other renderers and what it's known for, offering best quality for enthusiasts.
Maybe later there should be some kind of wizards or autodetection for slower hardware. Doubled framerate is the only real advantage of interlacing left, so why drop it? :devil:
And coming spring/summer there will be faster GPUs, leading to even more consumer hardware being able to handle madVR with very most content with the current default settings.

Could be a forced educational tutorial explaining the algorithms lol.

With a quiz at the end. You fail, MadVR self destructs.

[HoP]

@madshi
play with madVR v0.85.4

http://imgair.net/i/clipboard01-1356201033.gif

play with EVR CP

http://imgair.net/i/clipboard02-1356201062.gif

why??

file info:

Format : MPEG-TS
Format profile : No PAT/PMT
File size : 107 MiB
Duration : 3mn 40s
Overall bit rate mode : Variable
Overall bit rate : 4 060 Kbps

Video
ID : 67 (0x43)
Format : MPEG Video
Format version : Version 2
Format profile : Main@Main
Format settings, BVOP : Yes
Format settings, Matrix : Custom
Format settings, GOP : M=3, N=12
Duration : 3mn 40s
Bit rate mode : Variable
Bit rate : 3 601 Kbps
Maximum bit rate : 10 000 Kbps
Width : 720 pixels
Height : 576 pixels
Display aspect ratio : 4:3
Frame rate : 25.000 fps
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.347
Stream size : 94.4 MiB (89%)

Audio
ID : 46 (0x2E)
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 2
Duration : 3mn 40s
Bit rate mode : Constant
Bit rate : 256 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Compression mode : Lossy
Delay relative to video : -498ms
Stream size : 6.72 MiB (6%)

[pie1394]

Maybe later there should be some kind of wizards or autodetection for slower hardware. Doubled framerate is the only real advantage of interlacing left, so why drop it? :devil:


I agree with you about this.

If madshi wants madVR to be widely used in public, however, it cannot be just designed for enthusiast's hardware or newly coming hardware. The most commonly used hardware's life cycle need to be considered, too. It is something like chicken-egg quiz --- who is the first...

The simpler configuration method by default is more important than the flexibility for most people who do not have the knowledge to figure out what is the best setup for his equipments. It is engineer and enthusaist's job to sort out these combinations.

Tell you guys a story about my mother who is 66 years old. She has the PC using experience near 10 years (Win98 / WinXP / Win7). But I found she still cannot remember any function which needs more than 2 mouse-click steps or by hot-key. Last year when I replaced her broken old PC with a new one + Win7 OS, she complained to me that she didn't know how to use it... The evil Microsoft had changed the operation flow and UI look. It also happens to office 2007/2010, which drives me crazy, too. :mad:

Instead of teaching her everything from scratch, I just setup the UI arragement to layouts which she is familiar with... :D

Fortunately her toy's (was iPad2, now iPad3) most function usage is very straight forward and consistent. So she seldom calls me for help now ... :D

[leeperry]

Sure.
Having more thought about it, it's be great if you could make it "PC > TV > 2X > 3X > 2X > TV >" so we could quickly roll between 2X and 3X because that's usually where the big dilemma lies IME....I've got that washed out 720p video where I can see that the ffdshow histogram starts around 30 but I kinda like the oversaturated colors of 3X anyway....OTOH, it's on a SMPTE-C CRT with a REC709 video and I don't have gamut rolling enabled (yet) :o

Anyway, it'd be great if we could roll them from bright to dark then gradually brighter instead of going bright > dark > bright. I also really enjoy how the hotkey starts from the current position instead of starting all over again from "PC" :)

I haven't gotten through the gamut PS script PotP automatic profile stuff yet, but I have to say that I'm as thoroughly impressed as ever by mVR's PQ when using Jinc3 AR for chroma/luma :devil:

And I believe it's only a matter of knowing about the ITU issue because I now can fairly easily horizontally stretch the video in order to look natural....you really learn new stuff everyday, huh!

Also, I really enjoy how it will finally be possible to force EBU for 25p HD and SMPTE-C for 23.976/24p HD via PotP automatic profiles because as much as I realize that this is out of specs, I still find the colors more true to life....and so do Kazuya, the french CEO of the ISF, Joe Kane and many other ppl....what matters in the end is that we can all set up the picture exactly the way we want it http://forum.slysoft.com/images/smilies/agreed.gif

I still think that you may wanna setup a dumbed down config panel for newbies and a more advanced panel for power users so the former wouldn't be scared by the zillion settings and the latter would find all the options they could ever crave. I can only imagine how a complete newbie could be scared by the current config panel, but this isn't quite a good reason to dumb it down to death IMHO.

:thanks:

[SyrupBuccaneer]

Anyway, according to the log, PotPlayer does not use madVR's screenshot functionality at all. I suppose that PotPlayer grabs the video frames directly from the decoder. You'll have to ask the PotPlayer devs to use madVR's screenshot functionality instead. It's available through the official Microsoft interface (IBasicVideo::GetCurrentImage).

Can you suggest a way of contacting them? I've been looking around for a way to them but all I've found is the Korean Daum media center page. Do they have an English team at all?

[iamhacked]

Try Bilinear for everything. Your GPU is really slow, so you'll have to compromise on quality. Also try activating "use half framerate DXVA processing", if your content is interlaced and you can't get it smooth any other way.

P.S: What exactly do you mean with "static glitches"?


I turned on all the settings for compromise quality. The glitches look like static noise flashing, I think you guys call it presentation glitches. It might be because of the flush settings I changed for performance (from someone in this thread). But I don't always get glitches. I'm still getting it even with bilinear for everything. I'm using it with LAV filters and KMPlayer

[6233638]

I think madVR should not sacrifice any quality over performance by default. That's what makes it different from other renderers and what it's known for, offering best quality for enthusiasts.
Maybe later there should be some kind of wizards or autodetection for slower hardware. Doubled framerate is the only real advantage of interlacing left, so why drop it? :devil:
And coming spring/summer there will be faster GPUs, leading to even more consumer hardware being able to handle madVR with very most content with the current default settings.I'm not sure that we need to make such a big fuss over it right now to be honest. I think it is best to have madVR set up in such a way that most systems can handle it by default, while still offering a visual improvement over other video renderers. It's not like the quality options are going to disappear, or that your current settings will be changed.

By the time it hits 1.0, I expect Madshi will have implemented a look-up table to pick good defaults based on the card detected in your system, or possibly even a quick benchmark on first launch to see what it's capable of.

We will hopefully also see the ability to use different scaling algorithms for different types of content (e.g. different algorithms for SD upscaling, HD upscaling/downscaling, and 4K downscaling) which could also alleviate some of the problems by using less demanding algorithms on HD content than SD content for example.

I turned on all the settings for compromise quality. The glitches look like static noise flashing, I think you guys call it presentation glitches. It might be because of the flush settings I changed for performance (from someone in this thread). But I don't always get glitches. I'm still getting it even with bilinear for everything. I'm using it with LAV filters and KMPlayerPresentation glitches look like stutters in the video similar to dropped/delayed frames, not static noise flashing. I actually wonder if it could be problems with your video card. (is there anything else you run that stresses the card?)

What happens if you use LAV filters to decode this video using another renderer?

[markanini]

By the time it hits 1.0, I expect Madshi will have implemented a look-up table to pick good defaults based on the card detected in your system, or possibly even a quick benchmark on first launch to see what it's capable of.

We will hopefully also see the ability to use different scaling algorithms for different types of content (e.g. different algorithms for SD upscaling, HD upscaling/downscaling, and 4K downscaling) which could also alleviate some of the problems by using less demanding algorithms on HD content than SD content for example.


This would be great.

[iamhacked]

Presentation glitches look like stutters in the video similar to dropped/delayed frames, not static noise flashing. I actually wonder if it could be problems with your video card. (is there anything else you run that stresses the card?)

What happens if you use LAV filters to decode this video using another renderer?

It's fine with other renderers, I don't run anything else graphic-related

[Niyawa]

Hey people, this could have already been answered but I did a search and didn't find anything, so I have to ask. Why madVR overrides MPC-HC OSD interface, and is there a way to turn it off so I can customize it?

[iSunrise]

We will hopefully also see the ability to use different scaling algorithms for different types of content (e.g. different algorithms for SD upscaling, HD upscaling/downscaling, and 4K downscaling) which could also alleviate some of the problems by using less demanding algorithms on HD content than SD content for example.
Yes, I am also waiting for that to happen. SD content is not going to disappear over night anytime soon and for some sources, never. Together with customizable SD/HD resolution threshold settings (if enabled, otherwise use the auto-detect logic), these would indeed be great additions to madVR.

[vivan]

Why madVR overrides MPC-HC OSD interface, and is there a way to turn it off so I can customize it?In fullscreen mode? It's because exclusive mode is active (which you can rutn off in madVR settings)...

[aufkrawall]

Oooh, that's interesting... :) Without full/half floating point processing, basically EVR converts to 8bit RGB, I believe. madVR refuses to do that because it's too low quality. So it seems EVR isn't really faster than madVR in this case, it just uses lower (too low) quality by default than madVR.

You could try the test build from yesterday (see a few posts up), which now uses float16 instead of float32. Maybe that will be enough to make madVR run fluidly on your E-350? What happens if you switch EVR to half floating point processing? Is that running smoothly?

Yep, that madVR builds works and it works also with EVR half floating point processing (maybe a little worse).
With madVR I don't get any dropped frames after lowering queues in windowed mode.
But unfortunately, in FSE I get dropped frames, present queue sometimes gets emtpy.

Btw: I figured out why FSE wasn't working at all: It seems it didn't like 16 frames presented in advance, with lower values like 4 or 8 this doesn't happen. Then there are just those frame drops.

[Niyawa]

In fullscreen mode? It's because exclusive mode is active (which you can rutn off in madVR settings)...
Nope, I don't use fullscreen mode. It's simple the OSD style that madVR overwrites from MPC-HC, I don't know why it does that and neither how to turn it off (if it's possible).

[Kado]

Nope, I don't use fullscreen mode. It's simple the OSD style that madVR overwrites from MPC-HC, I don't know why it does that and neither how to turn it off (if it's possible).

I only get the custom osd if in fullscreen exclusive mode, you can disable it in mad vr settings, rendering, general settings, uncheck "enable automatic fullscreen exclusive mode".

Feliz Natal! (Merry Christmas!)

Unless you're talking about this (custom buttons), just erase "toolbar.bmp" in mpc folder.
http://img94.imageshack.us/img94/8790/mpccustombuttons.png


OK, just saw your picture because before it wasn't approved yet. I think ost implementation is renderer dependent, haali renderer does not have osd for instance, and that was the style used by madashi.

[madshi]

play with madVR v0.85.4

play with EVR CP

why??

file info:
EVR exposes different interfaces to the media player compared to VMR9. Try VMR9, I think it will behave similar to madVR. madVR currently exposes the same interfaces that VMR9 exposes. I plan to add support for EVR interfaces in a future version, but probably not too soon.

Having more thought about it, it's be great if you could make it "PC > TV > 2X > 3X > 2X > TV >" so we could quickly roll between 2X and 3X because that's usually where the big dilemma lies IME....
I'm not sure if I like that. All other toggles work differently, and I somehow have to allow switching back to auto detected levels, too.

Can you suggest a way of contacting them? I've been looking around for a way to them but all I've found is the Korean Daum media center page. Do they have an English team at all?
I think there's a forum, but I don't know where and whether there's support for English users. @leeperry? (Question is about how to contact PotPlayer developers.)

I turned on all the settings for compromise quality. The glitches look like static noise flashing, I think you guys call it presentation glitches. It might be because of the flush settings I changed for performance (from someone in this thread). But I don't always get glitches. I'm still getting it even with bilinear for everything. I'm using it with LAV filters and KMPlayer
So you mean you're getting some video frames which look corrupted or overly noisy? This doesn't sound like a usual problem, no other user has reported a problem like this. This may be a problem with your GPU drivers, or maybe the GPU is overheating, or something like that. I can't really say. Do you get the same problem in windowed and fullscreen exclusive mode? You could try going back to madVR default settings, just to double check.

Hey people, this could have already been answered but I did a search and didn't find anything, so I have to ask. Why madVR overrides MPC-HC OSD interface, and is there a way to turn it off so I can customize it?
madVR does not override anything. madVR offers various different OSD interfaces which the media player can use. MPC-HC could show the same OSD with madVR which is shows for VMR/EVR. The MPC-HC devs would have to add support for that, too, by using one of the madVR OSD interfaces. Currently MPC-HC uses a very simple madVR interface to show text messages, which are then shown by madVR's own style/design. Actually the code MPC-HC uses for that was added to MPC-HC by me. Making MPC-HC show the same OSD it shows for EVR/VMR9 would be possible, but would cost a bit of extra work. Furthermore it's a matter of taste, too. Personally, I like the madVR style much more than the MPC-HC style. If you want to get the MPC-HC style, you'd have to ask the MPC-HC devs to add support for that for madVR. But I'm not sure if they want to spend the development time for that, considering that the current solution works well, and the only difference would be a different "look". Also I think some users prefer the current solution.

Yep, that madVR builds works and it works also with EVR half floating point processing (maybe a little worse).
With madVR I don't get any dropped frames after lowering queues in windowed mode.
But unfortunately, in FSE I get dropped frames, present queue sometimes gets emtpy.

Btw: I figured out why FSE wasn't working at all: It seems it didn't like 16 frames presented in advance, with lower values like 4 or 8 this doesn't happen. Then there are just those frame drops.
Ah, that's interesting. I'm glad to hear that madVR seems to run just as fast as EVR with your ultra-slow GPU, when switching EVR to half-way decent quality settings. That does confirm that madVR can work with very low-power GPU hardware, too.

[leeperry]

@leeperry? (Question is about how to contact PotPlayer developers.)
like this (http://forum.doom9.org/showpost.php?p=1597613&postcount=2), but I'm 99.99% sure that the answer will be "use other player!!!!!!!!!!!"http://forum-images.hardware.fr/images/perso/guppy84.gif

so he'd better make a compelling case :D

[HoP]

EVR exposes different interfaces to the media player compared to VMR9. Try VMR9, I think it will behave similar to madVR. madVR currently exposes the same interfaces that VMR9 exposes. I plan to add support for EVR interfaces in a future version, but probably not too soon.


thanks for info :thanks:
yes,"VMR9 windowed" is similar to madVR.
but "VMR9 renderless" is not.

[madshi]

madVR v0.85.5 released

http://madshi.net/madVR.zip

* fixed: DXVA deinterlacing: when GPU couldn't keep up, audio sync got lost
* fixed: odd source rectangles could result in "green" images (DXVA)
* fixed: display mode changer sometimes didn't work for DVDs
* slightly modified "use separate device for DXVA processing" behaviour
* changed scaling defaults once more (Bicubic75, Lanczos3, Catmull-Rom)
* disabled "perform deinterlacing in separate thread" by default
* DXVA NV12 conversion routine now uses 16bit float instead of 32bit (faster)
* up to 56% speed improvement for Jinc3 chroma upscaling
* up to 40% speed improvement for Jinc3 AR chroma upscaling
* up to 53% speed impr. for Jinc3/4 image upscaling with 2x scaling factor
* up to 47% speed impr. for Jinc3/4 AR image upscaling with 2x scaling factor
* up to 39% speed impr. for non-Jinc image upscaling with 2x scaling factor
* up to 27% speed impr. for non-Jinc AR image upscaling with 2x scaling factor
* up to 44% speed impr. for non-Jinc image upscaling with 3x scaling factor
Please note that the speed improvements only apply in very specific circumstances. E.g. the Jinc chroma upsampling speed improvement only applies to 3-taps (with or without AR). There's no improvement for Jinc4/8 chroma upscaling. And all the other improvements only apply if there's an *exact* 2x or 3x scaling factor requested by the media player. With any other scaling factor there's no improvement at all for image scaling performance. The exact scaling factors of 2x and 3x allow me to write hard wired shader code which runs more efficiently, thus the speed improvement. There are no further similar improvements for other scaling factors planned. The 3x scaling factor improvements only apply when not using AR. There's no improvement for 3x AR image upscaling.

The main purpose of the 2x and 3x speed improvements is the upcoming UltraHD (4k) displays. Now with v0.85.5 you can upscale Blu-Ray to UltraHD with significantly lower GPU usage, as long as you use exactly 2x upscaling. Also 720p -> UltraHD happens to be exactly 3x upscaling, so that's why I added some dedicated 3x pixel shaders, too. Please note that the exact speed improvement depends on the circumstances and especially on the GPU model.

Here's the list of my own benchmarks, tested with NVidia 9400 (very old and slow) and AMD 7770:

2x scaling
tap 2 : 8.53 -> 6.51 (23.7%) NVidia 9400
tap 3 : 11.98 -> 7.86 (34.4%) NVidia 9400
tap 4 : 14.92 -> 9.02 (39.5%) NVidia 9400
tap 2 : 6.30 -> 5.92 ( 5.9%) AMD 7770
tap 3 : 8.08 -> 6.02 (25.5%) AMD 7770
tap 4 : 9.55 -> 6.75 (29.3%) AMD 7770

3x scaling
tap 2 : 13.16 -> 9.91 (24.7%) NVidia 9400
tap 3 : 19.96 -> 12.65 (36.6%) NVidia 9400
tap 4 : 25.24 -> 17.08 (32.3%) NVidia 9400
tap 2 : 9.04 -> 7.61 (15.8%) AMD 7770
tap 3 : 12.12 -> 7.84 (35.3%) AMD 7770
tap 4 : 16.58 -> 9.28 (44.0%) AMD 7770

2x AR scaling
tap 2 : 16.75 -> 13.64 (18.6%) NVidia 9400
tap 3 : 20.24 -> 17.79 (12.1%) NVidia 9400
tap 4 : 24.78 -> 21.87 (11.7%) NVidia 9400
tap 2 : 7.99 -> 6.45 (19.3%) AMD 7770
tap 3 : 9.71 -> 7.29 (24.9%) AMD 7770
tap 4 : 11.47 -> 8.36 (27.1%) AMD 7770

2x Jinc scaling
tap 3 : 38.84 -> 19.23 (50.5%) NVidia 9400
tap 4 : 61.27 -> 40.74 (33.5%) NVidia 9400
tap 3 : 14.09 -> 7.33 (48.0%) AMD 7770
tap 4 : 25.55 -> 12.00 (53.0%) AMD 7770

2x Jinc AR scaling
tap 3 : 86.92 -> 70.58 (18.8%) NVidia 9400
tap 4 : 137.87 -> 118.62 (14.0%) NVidia 9400
tap 3 : 15.97 -> 9.78 (38.8%) AMD 7770
tap 4 : 27.00 -> 14.30 (47.0%) AMD 7770

Jinc Chroma scaling
tap 3 : 38.84 -> 27.57 (29.0%) NVidia 9400
tap 3 : 14.27 -> 6.24 (56.3%) AMD 7770

Jinc Chroma AR scaling
tap 3 : 89.03 -> 86.84 ( 2.5%) NVidia 9400
tap 3 : 15.90 -> 9.50 (40.3%) AMD 7770
(I've used different test videos for AMD and NVidia GPUs, and also for different test sequences. So the absolute rendering times are not suitable for any sort of comparisons).

-------

Once again I need your FEEDBACK:

I'm trying to figure out again which defaults to use for a couple of options. I'm especially interested in these:

(1) "perform deinterlacing in separate thread". This was enabled in earlier madVR builds by default. It's now disabled by default in v0.85.5. With my AMD GPU, there's no difference. My NVidia GPU runs slightly better with this option disabled.

(2) "use a separate device for presentation". This was and still is enabled by default. It used to be a good method to reduce glitches with older NVidia drivers. I'm wondering if this option is still beneficial today with both NVidia and AMD GPUs. I've been told this option can make problems for NVidia Optimus, so I'm wondering whether I should disable it by default.

(3) "use a separate device for DXVA processing". This is a rather new option, introduced recently. I've got one report that it helped. So I wonder if I should enable it by default. But I guess this might also make problems with NVidia Optimus (because it's similar to (2), see above). Right now I'm wondering whether maybe I should combine options (2) and (3) into one, so that I'm either using only 1 device for everything, or 3 devices, one for rendering, one for presentation and one for DXVA processing. Thoughts?

(4) "enable windowed overlay". When I originally implemented overlay, it wasn't ready for prime time yet, so I disabled this by default. But since its introduction, I have applied lots of fixes, so now it seems to work very well (only for NVidia and Intel, unfortunately). It works so well IMHO that I'm reevaluating whether I should enable this by default (not for AMD, obviously). Any thoughts on this?

Please check which way these options work better for you, and let me know your test results. If you can't see a difference, please let me know that, too.

Thanks!

[madshi]

yes,"VMR9 windowed" is similar to madVR.
but "VMR9 renderless" is not.
Yeah, madVR currently behaves like VMR9 windowed. In the future this might change, but that's the current state, and it's "as intended" for now.

[DrNein]

(4) "enable windowed overlay". When I originally implemented overlay, it wasn't ready for prime time yet, so I disabled this by default. But since its introduction, I have applied lots of fixes, so now it seems to work very well (only for NVidia and Intel, unfortunately). It works so well IMHO that I'm reevaluating whether I should enable this by default (not for AMD, obviously). Any thoughts on this?

Thanks!

Another negative is that limits video to one at a time. Obscure perhaps but I frequently use multiple instances of MPC-HC. If enabled by default it would not really be obvious why that functionality stopped working.

No, thank you! :)

[madshi]

Another negative is that limits video to one at a time.
True, but I should be able to detect the situation and use standard windowed mode playback for the 2nd, 3rd etc instances of the media player.

[aufkrawall]

I can confirm that with 0.85.5 it now properly switches to the correct display mode with my tested DVD.

Furthermore, now it also seems to be fast enough for the 4k test sample @720p with native DXVA2, Jinc3 AR and CR AR LL, at least if I max out CPU, GPU and presentation queues (which doesn't seem to give me any real drawback). :)
At the moment it seems there is no single problem for me with this version on my system. :thanks:
Boring. :D

[Majin3]

(2) "use a separate device for presentation". This was and still is enabled by default. It used to be a good method to reduce glitches with older NVidia drivers. I'm wondering if this option is still beneficial today with both NVidia and AMD GPUs. I've been told this option can make problems for NVidia Optimus, so I'm wondering whether I should disable it by default.

(3) "use a separate device for DXVA processing". This is a rather new option, introduced recently. I've got one report that it helped. So I wonder if I should enable it by default. But I guess this might also make problems with NVidia Optimus (because it's similar to (2), see above). Right now I'm wondering whether maybe I should combine options (2) and (3) into one, so that I'm either using only 1 device for everything, or 3 devices, one for rendering, one for presentation and one for DXVA processing. Thoughts?
I get a black screen with any of them enabled with AMD's Switchable Graphics as well so it's not limited to Optimus.
I guess combining them sounds reasonable unless one of them has side effects (can't really notice any difference on my Nvidia desktop).

[Prinz]

With 0.85.5 I can now use DXVA native without framedrops without scaling. But only in windowed mode, in exclusive mode the render and present queue drop to 1 and 0. And the framedrops start... In windowed mode the all queues are full.

[Mangix]

(4) "enable windowed overlay". When I originally implemented overlay, it wasn't ready for prime time yet, so I disabled this by default. But since its introduction, I have applied lots of fixes, so now it seems to work very well (only for NVidia and Intel, unfortunately). It works so well IMHO that I'm reevaluating whether I should enable this by default (not for AMD, obviously). Any thoughts on this?

I've used the Overlay mode since its inception on my GTS 450 and have never ran into any issues. The only issue with it is that when "present several frames in advance" is disabled, overlay is also disabled.

I vote for it to be enabled by default.

edit: I just noticed an issue when I disabled "use a separate device for presentation". With it enabled, my rendering times are around 8ms whereas with it disabled they are around 13ms. I am using CUVID as well as SVP. One of those could account for the difference. Not sure.

edit2: now this is odd. when I disable SVP, my rendering times go up to 17ms whereas with it enabled, i get 13ms... shouldn't a higher frame rate cause higher rendering times? I also disabled CUVID and went to software decoding and got 16ms instead of 17ms. So it's not an issue with CUVID.