Support forum for DG Tools

I know, and okay
Your skill and loyalty to DGTools users has more than earned my indulgence, it has earned my respect

Thank you! Just want to help guys trying to make good encodes to have some CPU left over for encoding.

How's that 1080 Ti working?

Installed it yesterday
Fans don't kick on until it hits 50C
Two fans with asynchronous control
Heat dissipating back plate
Real quiet and working with no glitches, used NVidia's latest drivers and left all the extra stuff on the install disk off

Sweet!

Will do but back to "business"


note the green lines on pvbob script

Tried another source and same result, driver version related?
I am on 382.05

That's not good. Can you give me a stream that causes that (just a few frames should be enough)? If so, I can probably fix it straightaway.

I'm on 381.65.

What version of Avisynth do you run?

Here is the link
http://www.mediafire.com/file/fqb918wl0 ... mple_1.mkv
Sample is from latest AVS+ 64 bit
Tried with AVISynth 2.6 32 bit and same result

Duplicated. Investigating...

Thanks for the report.

On a more fun note
Just used Afterburner to test the GPU
Afterburner could only get the GPU usage to 93%, stable at 70C with a clock of 1936MHz

Thanks for the PVBob. I run first tests, and from what I have seen the results look promising.
Just for fun I did a comparison for a synthetic (nasty pathalogical) source. Not that it is representative for any natural content, but regardless how irrelevant the source is for any typical use case it shows how the various bobbers produce different results. Even QTGMC has issues with it, it seems.
Don't downscale it for watching as the subsampling would introduce new artefacts. It's up to you to guess how the original images would look.

http://www.mediafire.com/file/5bka8m44l ... nttest.mkv

Surprisingly for PVBob() the pictures seem to converge to a static picture after the first few frames before they "return to life" when the pictures start to move later on in the video. I think this is very correct as PVBob displays both oroginal fields in every frame when there is no temporal movement (no combing), hence preserving maximum details and sharpness (adaptive deinterlacing/bobbing).

Edit:
Ooops! I noticed only now that gonca has already reported another issue. Interestingly it didn't show up in my uploaded testclip but I could now reproduce it with a different source. So I'll wait for the next slipstream and redo the test.

admin wrote:PVBob() is working and output is noticeably better than DGBob() (which is the yadif algorithm).

Nice ! ok, 2 questions.

1. Double-framerate NV deinterlacing used to introduce a double-framerate bug per
https://forum.doom9.org/showthread.php? ... ost1391269

Based on information I received from Nvidia I believe the Nvidia chain introduces a frame delay when doing double-rate deinterlacing. There's naught I can do about it.

http://forum.doom9.org/showthread.php?p ... ost1391556

OK, so I apply trim(1,-999999) to the NV double-rate deinterlaced clip and then it appears just like the others temporally. Thanks for checking.

Does this "feature" exist in the latest DGSource when specifying double framerate deinterlacing ?

2. Does the "feature" apply to either of PVBob (stand-alone PureVideo deinterlacer/bobber) or DGBob (yadif based deinterlacer) ?

Thanks

After some head scratching I figured out what is going on with the broken frames. Avisynth does not guarantee that the chroma pitch is 1/2 of the luma pitch! But the VPP takes only one pitch value (the luma pitch) and uses 1/2 of it for the chroma.

I can adjust the pitches with internal copies but before doing that I have a query to nVidia to see if there is any better workaround. I want to get this fixed before addressing your other questions. Thanks for your patience.

All fixed. I was able to avoid the extra copying by using the cuMemcpy2D() API to re-pitch the frame as it is copied to the GPU.

@Sharc

You have to be careful with that deint test file. The source version I have of it is not truly interlaced content. It is actually progressive shifted by one field so that field matching cleans it right up. Can you check that with your source?

@hydra3333

Everything is the same with the delay for DGSource and PVBob. DGBob is not affected. I will look at working around it in PVBob.

My file looks alright now, no more green lines

Good to hear, gonca. Thanks for reporting this issue and for your test results.

admin wrote:@Sharc

You have to be careful with that deint test file. The source version I have of it is not truly interlaced content. It is actually progressive shifted by one field so that field matching cleans it right up. Can you check that with your source?

You are right! The source is indeed field shifted and has no information from a true second field for creating a double rate bobbed output. DGTelecide(mode=0) restores the progressive picture perfectly. I just got fooled by the combed look.

Don't feel bad about it. You have a lot of company and I too initially got fooled. All the tests based on this (and there are a lot) are just nonsense. I was shocked when I discovered this. We're trusting souls, aren't we? The stream is useful for testing upsizing algorithms (after matching it back to progressive) but not for bobbing algorithms.

I use a high-quality 1080i natural video called Cityscape that has a lot of edges and problematic scenes. I can upload it if you want it.

This is why I always ask for the source video when someone shows a comparison. If there is no source provided I just ignore the comparison. Sort of like an EPR experiment where they don't give you all the data (e.g., Hensen et al).

I did few more tests and found PVBob to be most similar to TDeint or LeakKernelBob. Could this be correct?

admin wrote: I use a high-quality 1080i natural video called Cityscape that has a lot of edges and problematic scenes. I can upload it if you want it.

I would appreciate if you could upload the Cityscape testsource, thank you. My testfiles are mostly from my home videocamera and have their own deficiencies.

I haven't looked at the kernel bob stuff for years; I'll take a look at LeakKernelBob and report back. Is there a 64-bit version? As far as TDeint() is concerned, it depends on whether you use the edeint parameter and what you invoke with it. Feel free to post comparisons...with source video (or use Cityscape).

http://rationalqm.us/misc/Cityscape.ts

Initial results with LeakKernelBob are not stellar for me. E.g., it trashes the buildings at the beginning of Cityscape. It also has an overall softness that is to be expected from the convolution kernel. Nowadays, I'm also not too big on hard thresholds, even though I can be blamed for introducing that with Smart Deinterlace way back in the cave-man days of desktop video.

Cityspace - that's a really nice reference. Thanks for uploading

My pleasure. Looking forward to your comparisons.

The typical mpeg2 artefacts are sometimes overruling (or masking) the deinterlacing/bobbing artefacts. But I agree the LeakKernel algorithm leaves more residual combing and swallows more details.

Yes, that's MPEG2 at typical ATSC broadcast bitrate. A sad reality. Sorry about that. The scenes without fast motion are OK, though.