Support forum for DG Tools

Hi,

I'm just wondering, which deinterlace kernel acheives the best result, DGDecodeNV(deinterlace=1) or KernelDeint?

I'm planning on converting a bunch (aprox 200 hrs) of interlaced material from Canon HF10 and HF20 cameras and want to get a recommendation for the best deinterlace results possible.

All things being equal I'd prefer to have the delinterlace happen in the GPU so the CPU can be freed up for the encode. Is DGDecodeNV(deinterlace=1) just an implementation of KernelDeint in CUDA?

Any recommendations for getting the absolute best results possible? I'd like to eventually delete the source material.

Thanks in advance...

Well, it's a bit problematic for me to do a side-by-side / frame-by-frame analysis searching for motion combing and other deinterlace artifacts in various scenarios, so I thought I'd ask whether they're equivalent algorithms.

But thanks for the mention of QTGMC, I'll check into that.

A few small tests I did, sporting CUDA-deint, TGMC, tdeint(kernel), and Yadif: one, two, three

Didée wrote:A few small tests I did, sporting CUDA-deint, TGMC, tdeint(kernel), and Yadif: one, two, three

Thanks!!

For those of us with limited bandwidth to dl the samples, is there a clear winner?

Groucho2004 wrote:

laserfan wrote:For those of us with limited bandwidth to dl the samples, is there a clear winner?

Do you use one of these to connect?

Worse. A satellite dish!

Thank you. I guess we know now why your handle is Anon17!

Anon17 wrote:

laserfan wrote:I guess we know now why your handle is Anon17!

I don't get it.

Well duh. I asked a simple question, and instead of answering you gave me crap about my ISP.

<Here> is a page with some "objective numbers" about various (bob-) deinterlacers.


But there is bad news: For you, QTGMC probably is out of reach, anyway.
Reason: the package-of-plugins for QTGMC is approx. 18.5 MB in size. And as we have learned, you obviously cannot download such a gigantic file.

So, just forget about the slow QTGMC, and be happy with the simple, fast-running, flickering & bitrate-sucking traditional deinterlacers . (:

Didée wrote:<Here> is a page with some "objective numbers" about various (bob-) deinterlacers.

Thanks for the useful link.

people happily use slow, slower and evenslower x264 settings to improve 2 percent here, another percent there. But when it's about vastly improved frame quality at vastly reduced birate, then no, thanks, it is too slow. Let's rather use the poor Yadif to quickly turn the source into a psychedelic something, then compress with insane x264 settings to no avail.

I will look for the oppty to try it!

QTGMC that is!

I haven't been able to check back here in a while, but thanks all for the helpful info.

Instead of using a `compromise` deinterlacer you don`t fully trust, why not encoding interlaced? MBAFF has seen significant improvements recently.

Can you tell us what the improvements were? Is it actually adaptive now? Thank you.

Adaptive quantization and efficiency improvements as I understand; more details e.g. from here:
https://github.com/DarkShikari/x264-dev ... its/master