DGDecomb

These CUDA filters are packaged into DGDecodeNV, which is part of DGDecNV.

Re: DGDecomb

Postby hydra3333 » Fri May 19, 2017 6:13 am

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
User avatar
hydra3333
Distinguished Aussie Member
Distinguished Aussie Member
 
Posts: 77
Joined: Wed Oct 06, 2010 3:34 am

Re: DGDecomb

Postby admin » Fri May 19, 2017 11:41 am

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.
admin
Site Admin
 
Posts: 2917
Joined: Thu Sep 09, 2010 3:08 pm

Re: DGDecomb

Postby admin » Fri May 19, 2017 1:35 pm

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.
admin
Site Admin
 
Posts: 2917
Joined: Thu Sep 09, 2010 3:08 pm

Re: DGDecomb

Postby admin » Fri May 19, 2017 1:43 pm

@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.
admin
Site Admin
 
Posts: 2917
Joined: Thu Sep 09, 2010 3:08 pm

Re: DGDecomb

Postby gonca » Fri May 19, 2017 4:18 pm

My file looks alright now, no more green lines
gonca
Distinguished Member
Distinguished Member
 
Posts: 224
Joined: Sun Apr 08, 2012 6:12 pm

Re: DGDecomb

Postby admin » Fri May 19, 2017 4:23 pm

Good to hear, gonca. Thanks for reporting this issue and for your test results.
admin
Site Admin
 
Posts: 2917
Joined: Thu Sep 09, 2010 3:08 pm

Re: DGDecomb

Postby Sharc » Fri May 19, 2017 5:45 pm

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:
Sharc
Distinguished Member
Distinguished Member
 
Posts: 152
Joined: Thu Sep 23, 2010 1:53 pm

Re: DGDecomb

Postby admin » Fri May 19, 2017 5:59 pm

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). ;)
admin
Site Admin
 
Posts: 2917
Joined: Thu Sep 09, 2010 3:08 pm

Re: DGDecomb

Postby Sharc » Sat May 20, 2017 11:09 am

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.
Sharc
Distinguished Member
Distinguished Member
 
Posts: 152
Joined: Thu Sep 23, 2010 1:53 pm

Re: DGDecomb

Postby admin » Sat May 20, 2017 11:32 am

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
admin
Site Admin
 
Posts: 2917
Joined: Thu Sep 09, 2010 3:08 pm

PreviousNext

Return to CUDA Filters

Who is online

Users browsing this forum: No registered users and 1 guest

cron