Differences in TFMMatch judgments based on the opening frame

[Ikotas]

The result of TEMMatch == n seems to differ depending on whether the frame 0 is C or P.

ConditionalFilter(last,last,last,"""propGetInt("TFMMatch",offset=-8)""","=","0",show=true)
or
ConditionalFilter(last,last,last,"""propGetInt("TFMMatch",offset=-8)==0""","=","true",show=true)

current_frame: 0-7

opening frame: C
-> Result: FALSE

opening frame: P
-> Result: TRUE

* In case of TFMMatch == 1, the opposite result

It seems that if the forward frame specified by offset is outside the area, the opening frame is used for judgment.
If it does not exist, it would be correct to always assume a false judgment.

[pinterf]

Please note that solving these problems alone will take me a lot of time, since I completely forgotten this field match / decimation knowledge (maybe never has adopted it since I never had to use them), for example I had to search for what C and P mean, what TFM is, so you can imagine from whom you are asking advice :). I need time for even understand the issue itself.

[Ikotas]

C and P should have been written in lower case.
These are the TFM match codes.

p = match to previous field
c = match to current field

I thought this Issue was due to the recently added Frame Propaties, but now I understand that it needs to be reviewed from the ground up.
Until this is fixed, we will combine this with current_frame to avoid referencing frames outside of the region.

[pinterf]

i wonder if Vapoursynth port does the same. They forked the project from this repo, then made the frame property stuff, which I imported back. So they should behave in a similar way. The only difference that due to compatibility reasons, when there are no frame props, then the burn-in bit hints are used instead.

This is what the doc says

- Source code: backport other simplification changes.
- Frame properties (priority over burned-into-image hints). Similarly to bitmapped hints, they are used when parameter "hint" is true.
  Frame properties set by TFM: TFMMatch, _Combed, TFMD2VFilm, TFMField, TFMMics, TFMPP
  Frame properties read by TFM and TDecimate: TFMMatch, TFMD2VFilm, TFMField
  Frame properties read by TFMPP: TFMField, _Combed
  Frame properties read by TDecimate creation: TFMPP (but if Avisynth variable "TFMPPValue" exists then the variable has priority over it)
  Frame properties never read: TFMMics
  Traditionally, TFM is using a 32 bit "hint" encoded in the lsb bits of the first 32 pixels of a frame.
  When Avisynth interface V8 is available, then frame properties are used instead of the image destructing bit hints.
  - Bitmapped hint replacement frame property names are: TFMMatch, _Combed, TFMD2VFilm, TFMField.
      Mapping:
        Bits 0-2: (ISP, ISC, ISN, ISB, ISU, ISDB, ISDT) are filled upon match (TFMMatch) and combed (_Combed) and field (TFMField)
          ISP: match == 0
          ISC: match == 1 && combed < 2
          ISN: match == 2
          ISB: match == 3
          ISU: match == 4
          ISDB: match == 1 && combed > 1 && field == 0
          ISDT: match == 1 && combed > 1 && field == 1
        Bit 3: set to 1 if field == 1 (TFMField 0 or 1)
        Bit 4: set to 1 if combed > 1 (_Combed)
        Bit 5: set to 1 if d2vfilm is true (TFMD2VFilm)
  - Other frame properties:
      TFMMics: array[6] of integer
      TFMPP: integer
  Frame properties set by TDecimate:
    TDecimateCycleStart (not used)
    TDecimateCycleMaxBlockDiff uint64_t[] (not used)
    TDecimateOriginalFrame (not used)
    _DurationNum, _DurationDen (not used yet, for variable frame rate (?), backport from VapourSynth port is in progress)

[pinterf]

It seems that if the forward frame specified by offset is outside the area, the opening frame is used for judgment.
If it does not exist, it would be correct to always assume a false judgment.

Sorry, I don't know why I did not understand this problem. It's Avisynth which is choosing frame 0 in this case.

n = min(max(n + offset, 0), vi.num_frames - 1);

where n is current_frame in the conditional runtime environment.

propGetInt always returns with the property, but the frame number - modified with the offset - is clipped to a valid range.