madVR - high quality video renderer (GPU assisted)

[ryrynz]

HTPC Specs
Intel i3-2120T
8GB
EVGA GTX 750Ti 2GB
Windows 7 SP1 32bit
Nvidia drivers 335.23 WHQL
1920x1080@59p resolution output to TV

MadVR Global Settings
Image Downscaling: Catmull-Rom AR LL
Deband: Low/High
Dithering: ED1, colored noise, change every frame
SmoothMotion: Always
3DLUT: Enabled
All ‘trade quality for performance’ unchecked


If you're going to use SmoothMotion set to always then a higher refresh rate should be better (set to 60Hz)

Personally I found SmoothMotion when set to 'always' to significantly soften the image.
I still use it on it's basic setting 'only if' but my TVs motion interpolation does a far better job of keeping details whilst providing much of the same benefit as the 'always' setting.
SVP is also something you could look at if your TV doesn't offer this functionality. Soft pans are just ew.

[n3w813]

If you're going to use SmoothMotion set to always then a higher refresh rate should be better (set to 60Hz)

Personally I found SmoothMotion when set to 'always' to significantly soften the image.
I still use it on it's basic setting 'only if' but my TVs motion interpolation does a far better job of keeping details whilst providing much of the same benefit as the 'always' setting.
SVP is also something you could look at if your TV doesn't offer this functionality. Soft pans are just ew.

I set my output refresh rate to 59(.94) because it is an exact 2x of 29.97(30p) and 2.5x of 23.976(24p) content. IMO, using 59 provides smoother motion than at 60. MadVR OSD shows clock deviation of less than 0.0004% and 1 frame drop every 1.5 hours. ;)

SVP actually interpolates the data between frames and may introduce artifacts. It produces the so-called soap opera effect like what most TV's built-in cinemotion filter does. Tried it before, hated it. :)

[hu1kamania]

So if I set Image Doubling to double Luma resolution "always - if upscaling is needed" what is the resolution threshold or perhaps "scaling factor" at which "upscaling is needed" for presenting content at 1080p?

[Asmodian]

Anything bigger than 1080. :confused:

[hu1kamania]

Anything bigger than 1080. :confused:

I mean to say, when does MadVR determine scaling is needed? It won't double a 1080p clip, if I'm already at 1920x1080 because scaling is not needed, but it will double a 720p clip.

What about clips larger than 720p, but smaller than 1080p? Some get doubled, and some do not. How does MadVR determine this if set to "always - if scaling is needed"? What is the magic number?

[Asmodian]

madVR determines scaling is needed if scaling is needed. There is no magic number, if the video get resized up at all it is supposed to use NNEDI3 (1079 and below with a 1080p display). With samples where this doesn't happen is the horizontal resolution equal to or over 1920?

If you think NNEDI3 is not used sometimes when it should be please post a sample that demonstrates the problem.

[Stereodude]

madVR should now be able to decimate 720p50/60 movies to 720p25/24. You need to manually activate deinterlacing for that and force film mode. Or add "deint=film" to the file name.
How do you manually activate deinterlacing without changing the file name on a progressive clip? I tried a 720p60 clip I know is 24FPS based with the "disable automatic source type detection" box checked and "force film mode" checked but nothing seemed to be happening.

[mandarinka]

Yeah, MST is just messy, it randomly freaks out various applications as they think you run two screens.
No idea why the vendors ever thought that was a good idea.

Mainly so that the LCD can be made cheaply I think - if you use the tiled arrangement, you don't need a new, beefy controller for 4K, just two less complex ones. I don't know much about that area of hardware, but it is possible that at the beginning, there even weren't controllers that would handle a single 4K matrix (or maybe the latency would be too high?). And many LCDs were going to require two connections anyway (HDMI or DVI)...

[hu1kamania]

madVR determines scaling is needed if scaling is needed. There is no magic number, if the video get resized up at all it is supposed to use NNEDI3 (1079 and below with a 1080p display). With samples where this doesn't happen is the horizontal resolution equal to or over 1920?

If you think NNEDI3 is not used sometimes when it should be please post a sample that demonstrates the problem.

Thank you for clearing that up. I have an odd clip that runs at 1916x1076 so it gets doubled, and I was trying to figure out why it would be doubled, but a 1920x800 clip would not. Seems obvious now....

[mandarinka]

Hmm, maybe that's not a bad idea for a feature request, to have a switch that would tell madvr to avoid scaling factors very close to 1.0x (1916 -> 1920 etc...) and just pad with black bars instead.

[truexfan81]

Maybe your 59.94Hz setting is too slow (e.g. 59.90Hz instead of 59.94Hz), which would mean madVR has to constantly drop frames to keep audio and video in sync.

i just did a test, i set it back to 60hz all is fine, i set madvr to change it to 1080p59 it has the same problem. In previous madvr versions this used to work, not really sure when that was broken, but the reason for trying to use 1080p59 is to remove judder without the blur caused by smooth motion.

[StinDaWg]

I've only just implemented decimation and wanted to get your feedback on whether it's working correctly or not. I'm not actually sure whether madVR should be switching to a 23Hz display mode when decimating 60p content. More see below:

50p/60p decimation is a bit different to 50i/60i IVTC. With 50i/60i content, if you turn on madVR film mode, you will only get correct results if the content is actually a movie. Practically that means that madVR relies on your decision to turn on film mode. As a result it can safely switch to 23Hz, because the content must be film, otherwise playback would be full of combing artifacts. So there's no way 60Hz would be correct. So switching to 23Hz is a safe decision.

With 50p/60p decimation the situation is very different: If you force on film mode, madVR will still produce a "good" output even if the content isn't film. So basically you could turn on film mode for all 50p/60p content, even for sports and music concerts. madVR should detect that and should only throw away duplicate frames if the source is really a movie. This means that 50p/60p decimation is actually better than 50i/60i IVTC, in that it more or less already contains a film vs video detection. That, however, means that it suddenly isn't sure, anymore, which refresh rate is the right one to switch to. If the content is film, switching to 23Hz would make sense. But if it isn't film, switching to 60Hz would be more appropriate. In theory madVR could switch back and forth between 23Hz and 60Hz, depending on the current state of the film vs video detection. But this could result in display modes switching back and forth e.g. if there are TV station video mode overlays over film mode content, which would not be cool. Because of that currently I think madVR should probably stay at 60Hz, because thanks to Smooth Motion FRC 60Hz works ok for both film and video content, and for mixed content, too.
I'm not sure I understand your take here. The whole reason to use decimation on 720p59.94 videos is to play it back at it's original frame rate of 23.976. The same thing "the scene" does when encoding (also called "reverse pulldown"). For instance, Almost Human, 24, Family Guy, Cosmos, New Girl, or whatever else on Fox is filmed at 23.976 but broadcast on Fox at 59.94 because of 60hz U.S. broadcasting standards. If I can play these at 23.976 then I can play the file back without 3:2 pulldown judder. It also allows me to use NNEDI doubling otherwise my card can't handle it at 59.94 and I am left with an inferior picture.

I don't see why you would want to use IVTC on true 59/60 fps content like sports, that doesn't even make any sense. It's supposed to be played back at that frame rate because it was filmed that way.

[turbojet]

Here's a clip that glitches while seeking and from the start: http://www.mediafire.com/download/5f37jw6mv8q156l/sm+glitch+deint%3Dfilm.mpg it's reproducable most of the time, just jump around. If SM is off it doesn't happen at 60hz. At 48 and 50hz the glitches happen at 72 and 75 the glitches don't happen.

On the fly ivtc is kind of hard I guess. If you don't want to add a setting how about scanning a part of the video, in the middle, before determining what to do with ivtc, refresh rate, sm? I'd surely give up a few seconds of life to get these corrected.

[renethx]

This anime clip (http://www.4shared.com/file/4CCpTKuece/One_Piece_444.html) (One Piece #444) is 1440x1080i59, obviously 2:2 cadence. When I press Ctrl+Shift+Alt+T twice (or add the tag "deint=ivtc"), the desktop refresh rate changes to 23Hz, resulting in lots of dropped frames. (The list of display modes is "1080p60, 1080p59, 1080p50, 1080p30, 1080p29, 1080p25, 1080p24, 1080p23", all of them are supported in my display.) So I have to add both tags "deint=ivtc" and "refreshRate=29".

Of course leaving ivtc to the graphics driver is the easiest @59Hz (2:2 means no judder). But it seems that NNEDI3 breaks it (I turn it on for 1.2x or higher).

[hu1kamania]

Hmm, maybe that's not a bad idea for a feature request, to have a switch that would tell madvr to avoid scaling factors very close to 1.0x (1916 -> 1920 etc...) and just pad with black bars instead.

I had a similar thought, but it's not too difficult to avoid with profiles.

[huhn]

I don't see why you would want to use IVTC on true 59/60 fps content like sports, that doesn't even make any sense. It's supposed to be played back at that frame rate because it was filmed that way.

720>p<60 with true 60 FPS is 2:2 MadVR IVTC detects this and is not decimating the stream the stream still placsback at 60 FPS. so nothing happen. this is not meant to be used on 1080i30 60 fields with no matching fields because this still needs Deinterlacing.

This anime clip (One Piece #444) is 1440x1080i59, obviously 2:2 cadence. When I press Ctrl+Shift+Alt+T twice (or add the tag "deint=ivtc"), the desktop refresh rate changes to 23Hz, resulting in lots of dropped frames. (The list of display modes is "1080p60, 1080p59, 1080p50, 1080p30, 1080p29, 1080p25, 1080p24, 1080p23", all of them are supported in my display.) So I have to add both tags "deint=ivtc" and "refreshRate=29".

Of course leaving ivtc to the graphics driver is the easiest @59Hz (2:2 means no judder). But it seems that NNEDI3 breaks it (I turn it on for 1.2x or higher).
Display mode always switches to 23p with 1080i30 60 fields when Forced film mode is active. it is simply this way now.

[nevcairiel]

720>p<60 with true 60 FPS is 2:2

True 60 fps content is 1:1, or more precisely, those things don't apply.

A Telecined PAL video would be 2:2, 50p which should be decimated to 25p.

[huhn]

True 60 fps content is 1:1, or more precisely, those things don't apply.

A Telecined PAL video would be 2:2, 50p which should be decimated to 25p.

Of cause it is true that progressive files didn't have fields but in the end MadVR IVTC detects it this way. the MadVR cadence is about fields not frames at all. and if you think about this like an encoder/decoder a 1080i30 60 field hard telecine or true i30 is yet another 30p stream with interlacing flag for the encoder/decoder but this is about 50p/60.

it simply treate it as Interlaced and check it so a 720p60 is treated as 720i60 120 fields and if this is 2:2 it is not touched and output as 720p60.

720p50 is treated as 720i50 100 fields and if 4:4 is detected it is supposed to decimate it to 25 fps but this is currently not working only 6:4 in 720p60 is decimated to 720p24 at the moment.

[StinDaWg]

it simply treate it as Interlaced and check it so a 720p60 is treated as 720i60 120 fields and if this is 2:2 it is not touched and output as 720p60.

720p50 is treated as 720i50 100 fields and if 4:4 is detected it is supposed to decimate it to 25 fps but this is currently not working only 6:4 in 720p60 is decimated to 720p24 at the moment.
Please stop mixing and matching terms. In my post above I was specifically referring to 720p59.94 6:4 videos that should switch to 23hz when film mode is turned on, because this is the way they were filmed and the correct frame rate to play them back at. It doesn't have anything to do with being interlaced. These are progressive files. There's no reason to ever turn on film mode or IVTC true 720p50 or 720p60 videos.

[huhn]

Please stop mixing and matching terms. In my post above I was specifically referring to 720p59.94 6:4 videos that should switch to 23hz when film mode is turned on, because this is the way they were filmed and the correct frame rate to play them back at. It doesn't have anything to do with being interlaced. These are progressive files. There's no reason to ever turn on film mode or IVTC true 720p50 or 720p60 videos.

read this:
http://forum.doom9.org/showpost.php?p=1678622&postcount=26139

MadVr uses the IVTC cadence detection to see if a 720p60 stream is 24 not 60, the real difference is that all odd field should match the top field in the same frame. so there shouldn't be an uneven number in the cadence.

force film mode = MadVR IVTC

btw. i was talking to nevcairiel

this is what i said to you 720>p<60 with true 60 FPS is 2:2 MadVR IVTC detects this and is not decimating the stream the stream still placsback at 60 FPS. so nothing happen. this is not meant to be used on 1080i30 60 fields with no matching fields because this still needs Deinterlacing.


not this

it simply treate it as Interlaced and check it so a 720p60 is treated as 720i60 120 fields and if this is 2:2 it is not touched and output as 720p60.

720p50 is treated as 720i50 100 fields and if 4:4 is detected it is supposed to decimate it to 25 fps but this is currently not working only 6:4 in 720p60 is decimated to 720p24 at the moment.

[turbojet]

On 25p sources it shows cadence 2:2 too, I've never understood that. What can madvr do with 25p source? Can it decimate 25 to 24 or 20, 18, etc?

Is 25 -> 24 without blends common?

[nevcairiel]

Any progressive movie is technically 2:2 if you force it through IVTC. The numbers basically means how fields belong together and in what patterns, and if you splice progressive into fields, you always have 2 fields that belong together exactly, hence 2:2.

[huhn]

Is 25 -> 24 without blends common?

a slowdown should be "more" common but i live in a Pal country so we normally get speedup dvds or untouched 25hz.

[turbojet]

Actually I wrote it in respect to madvr handling. Never really any need for a source like that as dvds and broadcasts aren't 24p and blurays accept 24p throughout the world. What I meant are 24p -> 25p sources common without blends?
Trying to figure out what madvr is trying to do with 25p. As far as I know it currently only decimates to 23.

[huhn]

MadVR gets 578i25 50 fields with IVTC is should detect 2:2 and creates simple 25p and plays it back as this speed. there is simply nothing to decimate at all.

there is no decimation need because of this:

24 -> 25 is general speed up.

they simple go and let the move run with 25 without changing anything at the frames.

audio is done this way (i leave the 24000/10001 out for a good reason):
48000/24*25 =50000
so audio is now plays at 50000 hz a sec (this is lossless)and then simply resampled to 48000 hz (this is not lossless at all) to be DVD confirm.
so decimation is totally useless.

this changes the audio everything clearly sounds different and a DVD with 25 hz is roughly 5 min shorter in duration as it counter part BD with 23p.

to get proper audio back you can use reclock plus madvr and slow it down to 23p again, this is yet again not lossless for audio but it shouldn't sound strange anymore.

EDIT: dvds and broadcasts aren't 24p
DVD can be 23p with soft telecine they are technical progressive but the decoder can read the repeat flags and creates a 3:2 30i 60 fields stream.
if the repeated flags are not used the put is 23p, this is not unusual at all! this is unusual for anime X-)

[StinDaWg]

read this:
http://forum.doom9.org/showpost.php?p=1678622&postcount=26139

MadVr uses the IVTC cadence detection to see if a 720p60 stream is 24 not 60, the real difference is that all odd field should match the top field in the same frame. so there shouldn't be an uneven number in the cadence.

force film mode = MadVR IVTC

btw. i was talking to nevcairiel

this is what i said to you

not this

I still don't get what point you are trying to make. If you force film mode on 720p59.94 content, it should play it back at 23hz. I realise this isn't the way it works at this moment, but it should. The reason you force film mode on 1080i29 content is to get rid of telecine and play it back the way it was filmed (23.976), same should apply to 720p59 content. If it's not telecined, then don't force film mode, leave it as is. Simple enough?

[turbojet]

huhn: I understand all that already. What I'm trying to figure out is what madvr is trying to do with a 25p file. It's not deinterlacing but it's trying to find a cadence. Madvr seems limited to decimating to 23/24 currently so is removing 1 out of 25 frames what it's looking for? Or is some pal content flagged progressive really interlaced?

Is there pal content that converts 24 -> 25 by adding 1 dupe frame every 25? I've heard of some dvd's adding blended frames instead of speeding up the framerate but never adding one duplicate frame out of 25.

[nevcairiel]

What I'm trying to figure out is what madvr is trying to do with a 25p file. It's not deinterlacing but it's trying to find a cadence.

It will only try to find a cadence if you force it to look for one, and if you do that on a progressive movie, it will ALWAYS find a 2:2 cadence, since thats technically what all progressive movies are.
Stop forcing madVR into IVTC mode on progressive content, and you won't have to worry about what its doing.

In general though, madVRs IVTC is pretty flexible, and if your 25p file was actually 20p with a couple of repeated fields, it would manage to detect that. (note: this example is not out of the real world, but just to illustrate what it could potentially do)
AFAIK its not limited to decimating to 24p, it can handle various patterns - it previously just encountered a few issues if it has to decimate way too many frames (ie. to 24p from 60p).

[huhn]

Is there pal content that converts 24 -> 25 by adding 1 dupe frame every 25? I've heard of some dvd's adding blended frames instead of speeding up the framerate but never adding one duplicate frame out of 25.

2:2:2:2:2:2:2:2:2:2:2:3 this is a possible 25i 50f cadence.
if MadVR finds a cadence doesn't mean it makes use of it...

I still don't get what point you are trying to make. If you force film mode on 720p59.94 content, it should play it back at 23hz.

you missed one very important point. MadVR does this 720p60 with 6:4 is playback at 24 hz but is didn't change the refreshrate to 24, but we got SM and thanks to SM this isn't a real problem and a miss detection doesn't end up in a huge mess. so even if the stream is true 60 it isn't harming it and nothing bad should happen, same for a switch to 4:4 cadence or something like that as long as MadVR stays in 60 hz and has SM it can deal with it.
or it should be able to.
The reason you force film mode on 1080i29 content is to get rid of telecine and play it back the way it was filmed (23.976), same should apply to 720p59 content. If it's not telecined, then don't force film mode, leave it as is. Simple enough?

do you know all your 72060 cadence?

if it is true 60 FPS nothing is happing and playback is fine, if it is 6:4 MadVR decimate it to 24hz and Thanks to SM every thing is fine too.

WIN WIN situation

BTW. this version is just a test for it.

[NicolasRobidoux]

Mathias:

(I am sure you are busy with other things, so I don't necessarily expect anything to happen as a result of what follows.)

The current madVR Jinc4 (which I believe has a "deblur" set more or less like madVR's Jinc3) is a rather ordinary scheme compared to Jinc3.

The exceptional 4-lobe Jinc scheme is the one I've been calling EWA LanczosSharpest, and last showed off in the context of pixel art resampling. It is only different from what you do already in the "deblur" that defines it, which is smaller and consequently makes it use a smaller disc. In other words, the better Jinc4 is actually a cheaper scheme than what I understand you are using now.

In ImageMagick notation, it is defined by

-define filter:blur=0.88451002338585141

which I would guess could be accomplished a minor modification of madVR, and would provide a Jinc4 different from Jinc3 in a worthwhile way.

Some of the justification for the choice:

http://www.imagemagick.org/discourse-server/viewtopic.php?f=2&t=25268&sid=3875f4556d4fa75ecdf59ce7372d229d

(To see the plots in the Luminous-Landscape post you unfortunately need to join. They make clear that EWA LanczosSharpest 4 is an exceptional passband filter. It's basically as good as tensor Lanczos without the latter's lack of damping of the checkerboard mode.)

[NicolasRobidoux]

Specifically, the full radius of the EWA LanczosSharpest 4 disc is
4.2410628637960699 * 0.88451002338585141 = 3.75126261284
which is not much larger than the full extent of the EWA LanczosSharp 3 you use, namely
3.2383154841662362 * 0.9812505644269356 = 3.17759889663.
(I do understand that you chop off the disc a little. At 3 if I remember correctly.)

[StinDaWg]

You missed one very important point. MadVR does this 720p60 with 6:4 is playback at 24 hz but is didn't change the refreshrate to 24, but we got SM and thanks to SM this isn't a real problem and a miss detection doesn't end up in a huge mess. so even if the stream is true 60 it isn't harming it and nothing bad should happen, same for a switch to 4:4 cadence or something like that as long as MadVR stays in 60 hz and has SM it can deal with it.
or it should be able to.


do you know all your 72060 cadence?

if it is true 60 FPS nothing is happing and playback is fine, if it is 6:4 MadVR decimate it to 24hz and Thanks to SM every thing is fine too.

WIN WIN situation

BTW. this version is just a test for it.

It's not a WIN WIN situation because my tv does 24p output better than madVR smooth motion frame blending. I don't want to use smooth motion, I want to use 23hz output and play it back the way it was filmed, without any modification by madVR.

[huhn]

if you force 23 hz it will play the file fine as long as the cadence stays 6:4, but no IVTC detections is good enough to make this 100 % sure. you will run in problems sooner or later. 720p60 is usual TV broadcast and this makes things even more tricky, it is way harder to do this with a TV broadcast thanks to compression artifacts, on screen logos, scrolling text and a lot more.

and MadVR Decimation for higher frame rate than refresh rate is pretty bad right now too and makes even more problems.

I don't want to use smooth motion, I want to use 23hz output and play it back the way it was filmed, without any modification by madVR.
fair enough.

and how do you get 720p23p out of 720p60 without MadVR modifications?
I'm not sure I understand your take here.
I still don't get what point you are trying to make.
but this part is cleared up now? You know now why it is working this way.

if you don't like it this is a difference thing i called some of the reason why it's a good thing, and i hope you see the benefits.

[Anime Viewer]

seidweise over on the KCP Codec forum put out a program that detects OpenCL on systems (http://haruhichan.com/forum/showthread.php?7545-KCP-Kawaii-Codec-Pack&p=36999&viewfull=1#post36999). Looks like AMD and Intel have the lead over Nvidia when it comes to the OpenCL version implemented on their devices. It makes me wonder if the Nvidia bug is related to Nvidia using the 1.1 version of OpenCL. Anyone feel like installing one of the old drivers that correctly functioned with OpenCL/NNEDI3, and then run seidweise's program to see if maybe the old drivers were using 1.0 compared to the new drivers which are using 1.1?

[huhn]

seidweise over on the KCP Codec forum put out a program that detects OpenCL on systems (http://haruhichan.com/forum/showthread.php?7545-KCP-Kawaii-Codec-Pack&p=36999&viewfull=1#post36999). Looks like AMD and Intel have the lead over Nvidia when it comes to the OpenCL version implemented on their devices. It makes me wonder if the Nvidia bug is related to Nvidia using the 1.1 version of OpenCL. Anyone feel like installing one of the old drivers that correctly functioned with OpenCL/NNEDI3, and then run seidweise's program to see if maybe the old drivers were using 1.0 compared to the new drivers which are using 1.1?

you are aware that this bug doesn't matter for MadVR at all anymore?

[wolfman2791]

I ran that check on my NVIDIA GTX 660... and with my driver version (337.50), the OPEN CL version is 1.1. Interestingly, the CPU is running version 1.2 lol. OPEN CL's latest version is 2.0...

[wolfman2791]

you are aware that this bug doesn't matter for MadVR at all anymore?It doesn't. But i'm sure newer versions of OPEN CL run more efficiently regardless of MadVR, no? Just like updating your driver makes MadVR run faster too typically.

[Asmodian]

Anyone feel like installing one of the old drivers that correctly functioned with OpenCL/NNEDI3, and then run seidweise's program to see if maybe the old drivers were using 1.0 compared to the new drivers which are using 1.1?

From what I understand based on madshi talking about the workaround it has nothing to do with the OpenCL version but more likely an optimization or an unintended consequence from something Nvidia changed.

The interop would report finished so madVR cleared the memory and started on the next frame but the interop wasn't really done. Not clearing the memory until later solved the black/green screen. This isn't something that would change in the specs between 1.0 and 1.1. I suppose it could be a bug present in Nvidia's implementation of OpenCL 1.1 that wasn't present in their implementation of OpenCL 1.0 but even if true I am still not sure what benefit knowing this would give us.

It doesn't. But i'm sure newer versions of OPEN CL run more efficiently regardless of MadVR, no? Just like updating your driver makes MadVR run faster too typically.

I don't think newer versions of OpenCL would run faster only due to the new version. New versions have more features, but if madVR doesn't use these new features they do not change anything. The reason new drivers are sometimes faster is due to optimizations not features sets.

A new feature sets might offer a faster solution for a specific task compared to a previous version but the developer would need to implement them for them to do anything.

[Soukyuu]

seidweise over on the KCP Codec forum put out a program that detects OpenCL on systems (http://haruhichan.com/forum/showthread.php?7545-KCP-Kawaii-Codec-Pack&p=36999&viewfull=1#post36999). Looks like AMD and Intel have the lead over Nvidia when it comes to the OpenCL version implemented on their devices. It makes me wonder if the Nvidia bug is related to Nvidia using the 1.1 version of OpenCL. Anyone feel like installing one of the old drivers that correctly functioned with OpenCL/NNEDI3, and then run seidweise's program to see if maybe the old drivers were using 1.0 compared to the new drivers which are using 1.1?Ha. I still have the old 327.23 driver installed. You're right, the old one says "OpenCL 1.0 CUDA" for me.

you are aware that this bug doesn't matter for MadVR at all anymore?It's still a bug. nVidia's stance of "if there is a workaround, don't bother fixing" is bound to lead to this bug reapppearing somewhere else again.

[Ceremony]

iGPU of an A10-7850K is performing remarkably well:
using Jinc as the upscaling algorithm, it can play any 1080 or below resolution flawlessly.

Unfortunately, 48fps or higher content is out of question (at these settings), as well as any NNEDI upscaling or the smooth motion feature.

Hopefully, it'll become e

[Mangix]

if Nvidia truly supports OpenCL 1.1, shouldn't this line of code be changed to use || ?

#if defined(__GPU__) && defined(__AMD__) && __OPENCL_VERSION__ >= 110

[James Freeman]

madshi, I think we're ready for a high quality Frame Interpolation algorithm now... :p

[wolfman2791]

I get the sense that the NVIDIA OpenCL bug will likely get fixed in the driver that upgrades from version 1.1 to 1.2 since it seems that the bug occured from 1.0 to 1.1.

[QBhd]

madshi, I think we're ready for a high quality Frame Interpolation algorithm now... :p


No I don't think so... Frame Interpolation is just bad VooDoo

QB

[James Freeman]

No I don't think so... Frame Interpolation is just bad VooDoo

Bad Frame Interpolation is bad.
HFR is the future.

[aufkrawall]

Personally, I think "proper" frame interpolation with madVR would be a dream.

Different topic:
Does anyone know if DXVA scaling with Maxwell is still bilinear + sharpening?

[QBhd]

So you guys want to take up GPU resources to do something that is not really the job of a renderer. Interesting concept when we are all trying to squeeze every last drop of GPU performance for the best PQ image scaling.

QB

[aufkrawall]

What's the difference to current smooth motion?

[Asmodian]

Smooth Motion is a mathematically exact way to display a frame rate at a different refresh rate while frame interpolation is trying to guess what a middle frame might have looked like and cannot be done without artifacts (in the near future at least). There is no "correct" way to do the interpolation and lots of situations where the best course is simply not to attempt an interpolation. This is a very complex problem with no right answer, a much bigger development effort, and no way to reach near perfection so I can see why madshi would not implement or would wait to implement something.

[Ceremony]

smooth motion blends frames occasionally, in case the video framerate isn't a multiple of the display refresh rate to avoid sudden jumps and skips.

frame interpolation (check out SVP (http://www.svp-team.com/) if you wanna test it) analyses the difference between two frames and "guesses" the step inbetween (often taking multiple frames before and after into account). While this works remarkably well for stills and simple panning shots, anything fast moving (action scenes, etc.) and transforming will cause major artifacts unfortunately. Also, its pretty tough to calculate, so dont expect this to work properly on a laptop or something!

most smart TVs (imo smart means dumb, because they suck big time!) have such a feature built in with some ways to tune it (be it on/off or degree of interpolation).