DGDecomb

These CUDA filters are packaged into DGDecodeNV, which is part of DGDecNV.
User avatar
hydra3333
Posts: 393
Joined: Wed Oct 06, 2010 3:34 am
Contact:

Re: DGDecomb

Post by hydra3333 »

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
I really do like it here.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: DGDecomb

Post by admin »

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.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: DGDecomb

Post by admin »

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.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: DGDecomb

Post by admin »

@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.
DAE avatar
Guest

Re: DGDecomb

Post by Guest »

My file looks alright now, no more green lines
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: DGDecomb

Post by admin »

Good to hear, gonca. Thanks for reporting this issue and for your test results.
DAE avatar
Sharc
Posts: 233
Joined: Thu Sep 23, 2010 1:53 pm

Re: DGDecomb

Post by Sharc »

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. :facepalm: :facepalm: :facepalm:
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: DGDecomb

Post by admin »

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). ;)
DAE avatar
Sharc
Posts: 233
Joined: Thu Sep 23, 2010 1:53 pm

Re: DGDecomb

Post by Sharc »

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.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: DGDecomb

Post by admin »

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
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: DGDecomb

Post by admin »

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.
DAE avatar
Sharc
Posts: 233
Joined: Thu Sep 23, 2010 1:53 pm

Re: DGDecomb

Post by Sharc »

Cityspace - that's a really nice reference. Thanks for uploading :D
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: DGDecomb

Post by admin »

My pleasure. Looking forward to your comparisons.
DAE avatar
Sharc
Posts: 233
Joined: Thu Sep 23, 2010 1:53 pm

Re: DGDecomb

Post by Sharc »

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.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: DGDecomb

Post by admin »

Yes, that's MPEG2 at typical ATSC broadcast bitrate. A sad reality. Sorry about that. :cry: The scenes without fast motion are OK, though.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: DGDecomb

Post by admin »

I was playing around trying to fix the VPP one-frame delay for bobbing and nothing was working but then I decided to try something off-the-wall and shockingly it worked to flush the VPP and fully correct random access:

Code: Select all

	// Frame is on GPU and everything configured at this point.
	err = cuvidMapVideoFrame(cuDecoder, 0, &outPtr, &_pitch, &vpp);
	if (err != CUDA_SUCCESS)
		env->ThrowError("PVBob: could not run the VPP");
	if (vpp.second_field == 1)
	{
		// This is found heuristically to solve the VPP one-frame delay problem.
		cuvidUnmapVideoFrame(cuDecoder, outPtr);
		vpp.second_field = 0;
		err = cuvidMapVideoFrame(cuDecoder, 0, &outPtr, &_pitch, &vpp);
		if (err != CUDA_SUCCESS)
			env->ThrowError("PVBob: could not run the VPP");
	}
	// Postprocessed frame gets copied back to CPU at this point.
I also found a way to reduce the GPU<-->CPU traffic, increasing the frame rate by 50fps for 1920x1080. I'll regression test a bit and then slip-stream it. I will look into applying this fix to DGIndexNV and DGSource(deinterlace=2). It's not clear that it can be applied directly.
User avatar
hydra3333
Posts: 393
Joined: Wed Oct 06, 2010 3:34 am
Contact:

Re: DGDecomb

Post by hydra3333 »

admin wrote:I was playing around trying to fix the VPP one-frame delay for bobbing and nothing was working but then I decided to try something off-the-wall and shockingly it worked to flush the VPP and fully correct random access.

I also found a way to reduce the GPU<-->CPU traffic, increasing the frame rate by 50fps for 1920x1080. I'll regression test a bit and then slip-stream it. I will look into applying this fix to DGIndexNV and DGSource(deinterlace=2). It's not clear that it can be applied directly.
Crikey, Charlie ! Nice going.
I really do like it here.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: DGDecomb

Post by admin »

No bodgy code for me. Don't want to come a gutser.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: DGDecomb

Post by admin »

I figured out how to make the fix work for DGIndexNV and DGSource(deinterlace=2). I'll do some thorough testing before slipstreaming it.
DAE avatar
Guest

Re: DGDecomb

Post by Guest »

Just keeps getting better and better
DAE avatar
Sharc
Posts: 233
Joined: Thu Sep 23, 2010 1:53 pm

Re: DGDecomb

Post by Sharc »

Seems like I have a blackout, but how can I IVTC a 59.94 telecined 25fps source using DGTelecide() and DGDecimate() such as to get the 25.00 fps progressive source back?
(I think the 59.94 telecined material is 3:2:3:2:2 telecined)
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: DGDecomb

Post by admin »

Please post a sample. There are too many uncertainties in your post to comment yet.
DAE avatar
Sharc
Posts: 233
Joined: Thu Sep 23, 2010 1:53 pm

Re: DGDecomb

Post by Sharc »

Here is a sample (sorry for the confusion, I meant a 25 => 29.97 telecined source, not 59.94)
http://www.mediafire.com/file/by4ykayn2dmotwx/ma_30i.ts
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: DGDecomb

Post by admin »

This script makes the video 25 fps.

dgsource("C:\Users\Don\Downloads\ma_30i.dgi")
dgtelecide()
dgdecimate(cycle=6,keep=5) # makes 24.975 fps
assumefps(25)

The stream has no audio, so I could not assess whether the 24.975 vs. 25 will be an issue. Worst case, you may need to shrink the audio a bit, or leave it at 24.975 if your target format accepts that.
DAE avatar
Sharc
Posts: 233
Joined: Thu Sep 23, 2010 1:53 pm

Re: DGDecomb

Post by Sharc »

Thanks! I came to the exactly same conclusion with my experiments, but I thought I might have missed something. So there is no "direct route" for IVTCing this by field matching plus m by n decimation to hit the 25.00fps

Actually, it is not a real problem. I just bumped across it when I converted a 25p (deinterlaced mpeg2 PAL 25i home video) to 29.97i using good old DGPulldown, and encoding it to AVC (x264). When inspecting the hard-telecined alternating 3p-3c-3p-3c ... and 4p-2c-4p-2c... pattern every about 100 frames (p=clear, c=combed frame) I wondered how the heck to IVTC this properly. :o
Post Reply