It's time for a driver's ed refresher course!admin wrote:Now I have to find out what a lane is.


It's time for a driver's ed refresher course!admin wrote:Now I have to find out what a lane is.
use_pf uses source stream flags; there is no analysis. It isn't something you can rely on generally, but if you know that your stream properly sets the progressive_frame flag, it can be useful to avoid deinterlacing frames marked as progressive. Even so, a frame may be coded and marked interlaced but have no motion and thus not need deinterlacing. So analysis is the fully correct general strategy to preserve frames whose content is progressive.Sharc wrote:DGSource has the boolean parameter "use-pf".
Is the decision about the frame type (progressive/interlaced) based on flags of the source, or does the algorithm analyse the frames and decide for combed or non-combed frames for deinterlacing (similar to DGDecomb)?
How will this be with the new DGDecombNV? Is it a pure FM / Decimate function?
Thanks !admin wrote:BTW, while profiling the filters I was able to find a useful speed gain for DGSource(). About 20%. I'll slipstream it at some point.
... and DGdeblockNVadmin wrote:Maybe it's time for me to look into the NV encoding samples. After I complete DGDecomb, of course.
Thanks for clarification.admin wrote:use_pf uses source stream flags; there is no analysis. It isn't something you can rely on generally, but if you know that your stream properly sets the progressive_frame flag, it can be useful to avoid deinterlacing frames marked as progressive. Even so, a frame may be coded and marked interlaced but have no motion and thus not need deinterlacing. So analysis is the fully correct general strategy to preserve frames whose content is progressive.Sharc wrote:DGSource has the boolean parameter "use-pf".
Is the decision about the frame type (progressive/interlaced) based on flags of the source, or does the algorithm analyse the frames and decide for combed or non-combed frames for deinterlacing (similar to DGDecomb)?
How will this be with the new DGDecombNV? Is it a pure FM / Decimate function?
I am just now starting to think about postprocessing/deinterlacing for DGDecomb. It will perform analysis in some way (I'm trying to re-use the field matching metrics) and then any frames appearing combed after field matching will be deinterlaced with an as yet to-be-determined CUDA kernel. We will save one frame copy to the GPU because it is already there from the field matching. The primary goal is speed, and not necessarily to reproduce all classic Decomb behavior and options.
Code: Select all
LoadPlugin("C:\Program Files (Portable)\dgdecnv\DGDecodeNV.dll")
DGSource("I:\test.DGI", fieldop=0)
DGTelecide(pthresh=3.5)
DGDecimate()
#DGDenoise()
#DGSharpen()
ConvertToYV12().AssumeFPS(24000,1001)
Old habits die hardOne thing: You don't need that last line, as it's already in YV12 at 23.976 fps coming out of DGDecimate().