TDeint and TIVTC

[kedautinh12]

TIVTC v1.0.29 (20240302)

[FranceBB]

Yep, TDecimate() is now populating frame properties correctly.
Another tiny step forward.
At this point it's been a while since frame properties were introduced alongside the old clip properties but we're still finding those things and filters/functions not handling them correctly.
I feel like the migration to frame properties in Avisynth will probably end up the same as the migration from 16bit stacked / interleaved to 16bit planar (i.e slowly lots of functions/plugins will use them, but there will forever be exceptions that will have to be handled manually with propSet()... )

[pinterf]

TIVTC 1.0.29 released with flossy83's additions.

(20240302)
         - TDecimate: allow noblend=true when hybrid=1, noblend default value is false when hybrid=1 to keep 
           backward compatibility. (flossy83)
         - TDecimate to fill new frame properties. (flossy83)
           TDecimateCycleMetrics, TDecimateCycleMetricsPrev, TDecimateCycleMetricsNext (float arrays),
           TDecimateCycleFrameNums, TDecimateCycleFrameNumsPrev, TDecimateCycleFrameNumsNext (int arrays),
           TDecimateCycleBlendStatus
           See #48: https://github.com/pinterf/TIVTC/issues/48
         - Fix #46: TDecimate(hybrid=3) blending with wrong frame. (flossy83)
           https://github.com/pinterf/TIVTC/issues/46

(from TDecimate - READ ME.txt):

      Frame properties set by TDecimate (since TDecimate v1.0.11, pack v1.0.29):

        TDecimateCycleMetrics (float array): normalised metrics for all frames in current cycle
        TDecimateCycleMetricsPrev and TDecimateCycleMetricsNext: same as TDecimateCycleMetrics but for previous/next cycle

        TDecimateCycleFrameNums (int array): frame numbers corresponding to TDecimateCycleMetrics
        TDecimateCycleFrameNumsPrev and TDecimateCycleFrameNumsNext: same as TDecimateCycleFrameNums but for previous/next cycle

        TDecimateCycleBlendStatus (integer): indicates if frames in the current cycle are blended:
            -20=undefined, 
            0=not blended, 
            1=blended, 
            2=not blended due to scenechange, 
            3=not blended due to 2 dup cycle workaround

        Example usage:

            ScriptClip("PrintProps(last, current_frame)", after_frame=true, local=false)
            function PrintProps(clip c, int current_frame){
                metrics = propGetAsArray(c, "TDecimateCycleMetrics")
                fnums = propGetAsArray(c, "TDecimateCycleFrameNums")
                blendStatus = propGetAny(c, "TDecimateCycleBlendStatus")
                s = ""
                for (i=0, ArraySize(metrics)-1) {
                  s = s + "Frame " + String(fnums[i]) + ": " + String(metrics[i], "%0.2f") + "\n" 
                }
                s = s + "Blend status: " + String(blendStatus) + "\n"
                c.Text(s, lsp=0, align=7, size=20, bold=true)
            }

and change in noblend:

   noblend -

        With hybrid = 0 or 1 there is a special case when tdecimate will use blend decimation, and
        that is when it detects two duplicates in a cycle, cycleR=1, and neither duplicate is next
        to a scenechange.  In such cases tdecimate will drop one of the duplicates and replace the
        other with a blend of its neighbors.  The "noblend" parameter is used to disable this behaviour.

        From TDecimate v1.0.11 (pack *v1.0.29) noblend has effect for hybrid = 1, for backward
        compatibility its default value is different for hybrid = 0 and 1.

           true - no blending in the two duplicate case when hybrid = 0 or 1
           false - use blending in the two duplicate case

        Default:  true (bool) when hybrid = 0, false (bool) when hybrid = 1

[Matching_Mole]

I'm currently using TFM/TDecimate with Avisynth Filter (and Avisynth+) to perform on the fly IVTC with some of my japan bluray and DVD. So I'm trying to optimise my script as the rendering time is critical in this case.

Where I'm quite lost is regarding SetMTMode. It seems that TFM, to perform the field matching, can't use it or in serialised mode which is not the better mode. Is it true or does SetMTMode or Prefetch could be useful to optimise my rendering time?

So far, the betters options to optimise TFM seems to be slow and PP (the encoding of my bluray seems pretty clean and sometime no PP seems required). AssumeTTF (or BFF but I didn't see any occurence for the moment) help also. Does any other options I should considerate to optimise the rendering time?

Thanks in advance!

[Boulder]

IIRC TDecimate is the one that doesn't like multithreading and automatically uses the serial mode, so maybe you could try placing Prefetch right after TFM for best results.

[Matching_Mole]

Thanks, I will try.