What's the difference between display card harware "inverse telecine" & software IVTC

The reason to use dscaler is that the GPU hardware/driver can detect pulldown, but can't actually do IVTC for HD movies in broadcast, right? Which pp you use depends on how you configure the video playback pipeline. You could stream video to the driver's algorithm, but once video is converted to the progressive format by dscaler, the driver will do nothing.

splitter -> dscaler -> renderer without GPU's post-processing, or
splitter -> dscaler -> GPU's post-processing -> renderer

but why use dscaler anymore? the consensus seems to be that madVR does a better job and is actively being developed unlike dscaler5 which seems to be orphaned.

Want to (or have to) use EVR?

The GPU can do IVTC just fine, you shouldn't see any weave artifacts if its active. However, it cannot perform the decimation step, which means you get a properly re-constructed image, but still 30 images, and not reduced to 24.
The advantage of letting the GPU do it is that it'll also work if you have mixed interlaced and telecined content, which in broadcast is quite common (ie. some interlaced ad banners slowly moving over the otherwise telecined image)

If you're from the US, you should be used to the whole 3:2 pulldown judder anyway and just watch it like that.

He's talking about the mpeg decoder, you can use that with madVR just fine, 2 different issues.

The main reason you'd see better results with the IVTC mod is that you can get 24Hz output from 60Hz material which great if you're running at 24Hz or a multiple and don't like 3:2 judder.

The GPU IVTC can be OK but I find it slow to lock and quick to fall out and is also confused by high detail, i.e. just when you want it it switched to video mode, most of the imeplementations I've spent any tiem with also introduce a frame drop around the going in and out of video which can result in extra judder.

John

I think mbordas was talking about the IVTC algorithm built into madVR which should (at least in theory) be better than the one used by the DScaler IVTC Mod. The madVR IVTC algorithm can handle all kinds of cadences, not just 3:2. However, it consumes quite a bit more CPU power than the DScaler IVTC Mod.

Thanks for the clarification, I didn't know it had one

Is that CPU rather than GPU? I would have thought doing it in GPU would be more efficient.

John

Well, it's a rather new feature. Was added just a couple of weeks ago...


Currently it's CPU (hand written SSE2 assembler). The main reason for that is that the way Direct3D pixel shaders work is very limited. Basically pixel shaders are great for doing pixel-by-pixel work in parallel. But in order to do decimation, a cadence must be detected, and then based on the cadence, some frames must be thrown away. Throwing a frame away is not a decision that can be made inside of a pixel shader, because a pixel shader really only transforms some source pixels to one destination pixel. In order to do all that cadence related stuff, the CPU needs information about how different fields/frames compare to each other, and D3D pixel shaders are simply not able to return any such information.

In the long run I plan to move my IVTC algorithm to the GPU by using CUDA and/or OpenCL. I could do that with CUDA right now. But AMD doesn't support CUDA. AMD does support OpenCL, but current AMD drivers don't offer OpenCL <-> D3D9 interop. So basically there's no (pretty) way to do this on AMD GPUs right now. I hope that AMD will sooner or later fully support OpenCL 1.2, including the new OpenCL 1.2 <-> D3D9 interop extension. Then I can finally start using CUDA/OpenCL in madVR. Currently I'm not looking into this because only supporting NVidia and not AMD doesn't make much sense to me.

well, nevcairiel supported cuda with lav video decoders for quite a while before anything else, and nobody complained. You have to start somewhere

Well, the current IVTC algorithm works well enough on the CPU. So there's no hurry to move it to the GPU.

Was thinking it's be possble using a diff then 3-4 pass reduce, mainly to avoid having to copy DXVA buffers back to the CPU for processing. But if the input is a software decode then sse2 is hard to beat for working out the diff, what do you use for 2:2 detection, I never found anything perfect and fast with DScaler, high vertical detail always seemed to cause issues.

John

I think I'll wait until I can implement it on the GPU without copying back textures to the CPU. Should be easy enough with CUDA/OpenCL. If only AMD would finally support OpenCL <-> D3D9 interop...


I'm using a totally different logic compared to the IVTC algorithm used in the DScaler IVTC mod. Basically for every top field I'm checking which bottom field (previous frame, current frame or next frame) matches best. And for every bottom field I'm checking which top field matches best. As long as I've not locked onto a specific cadence, I'm simply weaving the "best match" fields together. This "best match" weaving logic already produces quite good results. Then there's another algorithm which analyzes the "best match" results and tries to find a cadence pattern in them. The field matching algorithm itself is quite complex, using interpolation, simple noise reduction, weighted error counting etc.

I was talking about the code in DScaler 4, the IVTC mod code is very basic and 3:2 specific.


For current frame do you mean you check if the top field line below the current one is a better fit than either of the bottom fields?


Does sound quite similar to the DScaler 4 method. The sort of thing that caught that out was slight camera movement in scenes with high vertical detail like grills, skyscraper windows in the distance. But for most content I'd expect it to work pretty well.

John

No. I'm not looking at separate lines. Basically I scale up every top and every bottom field (kinda like BOB video deinterlacing, just not with line doubling, but with a very soft linear resampler). Then I compare the full upscaled top field of the current frame with the full upscaled bottom field of the previous frame, and of the current fame and of the next fame.


From my tests, as soon as there's any sort of camera movement, my algorithm works very well. The biggest problems I have are scenes where there's only a low amount of movement, because I use mostly only relative error comparisons and not absolute error comparisons. Due to how video compression works, in such scenes sometimes the top/bottom field of the current frame matches best, even if they don't belong together, simply because they were encoded as one frame with low bitrate.

Do you have a smple where the DScaler 4 method has problems with "slight camera movement in scenes with high vertical detail"? Would love to test if my algorithm has problems with that, too. I don't think it has, but would be good to check, just to be safe.

I seem to remember a diffs of up to about 8 being likely as mpeg errors even at quite high bitrates. But you're right when the bit rate is starved the images get blockier and blockier and start to look film like even if they should be interlaced, in this case I think it's ok to go to film mode as long as you fall back quickly enough.


Can't remember the exact time but there was a scene from a pal dvd of 2001 that had a grill in the bottom right that seemed to trigger the jaggie detection in DScaler 4. In this case in your algo the top frame would "belong" with itself and the bottom frames with itself too. Also have you tried the MS DVD Annex film zone plate torture tests?

John

Oh, is that for video mode detection? I'm currently not even trying to detect video vs film mode yet. The user has to manually switch to IVTC mode and then I expect the content to be film. I don't have any jaggie detection in my algorithms at the moment at all.

I plan to add video vs. film detection in a future version.


Nope, never heard of that. Does MS offer that for download somewhere?

Even if you know it's film there are some odd things that happen, this is espcially true in 3:2 world where the TV stations sometimes play with the run-time they can have odd sequences like 3:2:2:2:3:2:2:2 and if you stay in film mode these can look horrible, this is on top of the bad edits that quite often occur in drama.


From memory they are free but I think I had to pay postage for the discs, some other torture tests are these:

http://www.bigdish.info/other/pgscan.html

I can't seem to find where I got it from quickly though.

No problem, madVR detects "any" cadence, even something like 2:3:4:5:6:7:8 should be detected, if it were used.


Yeah, bad edits can be a problem. I have one DVD sample (silent film) which was encoded with a 4:3:3 cadence. madVR properly detects the cadence and locks onto it. But there are "bad edits" virtually every second. Basically, in random distances some of those 3 become 4. That's something I still have problems with.


Thx, will investigate. FWIW, I have the HQV SD test disc, which contains a test with various different cadences. madVR detects those just fine.