madVR - high quality video renderer (GPU assisted)

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

Originally Posted by turbojet

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]

Originally Posted by huhn

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]

Originally Posted by turbojet

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]

Originally Posted by turbojet

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

(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]

Originally Posted by huhn

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

Originally Posted by Anime Viewer

seidweise over on the KCP Codec forum put out a program that detects OpenCL on systems. 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]

Originally Posted by huhn

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]

Originally Posted by Anime Viewer

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.

Originally Posted by wolfman2791

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]

Originally Posted by Anime Viewer

seidweise over on the KCP Codec forum put out a program that detects OpenCL on systems. 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.

Originally Posted by huhn

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