frame properties

[realfinder]

Hi, in case you didn't note, but Asd-g added frame properties to MPEG2Dec/D2VSource, and since TIVTC and others used hints hack I think it's time to support frame properties to use it instead of hints if it available

[pinterf]

Yes, I was already looking for that possibility but seemed to be no an hours' work so I postponed. But it is not forgotten. (Those hints made me nervous :) and caused many extra hours of debugging. When I was making changes I was usually comparing the results of the old and the new code, and there always were very small differences. It turned out that those different bits came from the hints encoded on the 1st 64 bytes of the frames.)

[realfinder]

with DG (videoh) new test DGDecode now I can do https://github.com/Asd-g/MPEG2DecPlus/issues/9#issuecomment-1114307244 so I think it possible to update tfm() to use these properties instead of d2v string input and it int "flags"

it can be done maybe by adding negative to int "flags"

1st "0" will be "If d2v file is used then check the d2v file for illegal transitions and set the order parameter if it is not already manually set. Also, pass on rff flag duplicate info to tdecimate. If d2v file is not used then check _FieldOperation property if it 0 then check _RFF, _EncodedFrameTop and _EncodedFrameBottom properties and set _ToDecimate property to 1 if _RFF=1 and the _EncodedFrameTop in previous and current frame is the same number in case of _FieldOrder=1, and _EncodedFrameBottom in previous and current frame is the same in case of _FieldOrder=0"

           -1 - Same as 0, plus use the _ProgressiveFrame=1, _EncodedFrameTop and _EncodedFrameBottom properties for field matching (rematch the top and the bottem based on _EncodedFrameTop and _EncodedFrameBottom)

           -2 - Same as -1, but _ProgressiveFrame not have to be 1 (very much not recommended!)

           -3 - do nothing, I think?

           -4 - same as -1 but soft matches are checked for being combed.  If a soft match is detected
                   as combed then tfm uses its own matching routine for that frame.

           -5 - Same as -4, but soft matches are only checked for being combed around scenechanges.

the "VERY IMPORTANT (MUST READ)" will need to replace "For options 0, 1, 2, 4, and 5 to work correctly" with "For options 0 (if d2v file used), 1, 2, 4, and 5 to work correctly"

edit: the default of int "flags" after this should be 4 if d2v file is used, -4 if d2v file not used

[pinterf]

Hi! I think by now I'm not even familiar with the terminology - I've encountered with this tfm-tdecimate thing only when modernized the source and I was given test videos and parameters to work with. So all I can say that pull requests (preferably cleaned up - not ad-hoc trials) are welcome. :(

[videoh]

I've been following things and know the jargon so perhaps I'll try my hand at this. Beware however, it won't be a high priority for me.

Is there an actual identifiable upside to making this change?

[pinterf]

Actually I have started backporting the use-frameproperties-no-hints modifications from VS port. (temporarily with one difference: hints can still be used)

[realfinder]

@pinterf any news about backporting?

[pinterf]

Most of the changes and backport were done already - except for a variable frame-rate magic - but not polished at all. For example the role of the usehint parameter is not guarded well and ambigous. In VS version it is only for getting the info from frame properties (VS got rid of the hints), but historically in Avisynth version we use the bit-hints encoded by the lowest bits in the first 32 pixels of the frame. I could not decide what to do: mixed bit hints and frame properties? Use both? Ignore the hints? I was thinking about to stop supporting the old content destructive method.

Why does it take so long time?

I didn't want to upload a 'dirty', not 100% commit, just for showing the present - though almost ready - state. Maybe I'd create a branch and upload the changes I have done already, and someone could test the builds from that work branch.

[realfinder]

mixed bit hints and frame properties? Use both?

I think it's better as start is to remove the hints and make test build and it will be better if there are some "hints to/from properties" functions (same as http://avisynth.nl/index.php/ConvertStacked)

if everything ok after test build then we will talk about re-add the hints :) anyway my opinion https://github.com/pinterf/TIVTC/issues/32#issuecomment-1052625793

[realfinder]

except for a variable frame-rate magic

speaking of that, it will be nice if https://github.com/pinterf/TIVTC/issues/26 can be done and better with https://github.com/pinterf/TIVTC/issues/27

and about the "hint" parameters in TFM and TDecimate I see no problem making them work for either props or hints (but not both in same time of course), as start they only write/read props since hints was removed but later if hints re-added TFM write hints only for avs 2.6 not for avs+ and it's kinda safe to say same thing for TDecimate hint reading

or maybe adding new parameters for props away from "hint" parameters?

[realfinder]

@pinterf btw, what is the best/clean way to go of these cases:-

1- backport all tivtc from vs and update it (with https://github.com/pinterf/TIVTC/issues/26 and https://github.com/pinterf/TIVTC/issues/27) and with "hints to/from properties" functions (similar to http://avisynth.nl/index.php/ConvertStacked) with/without re-add the hints later

2- adding vs change with the current avs one

I think the 1st one better? unless there are compatibility breaking changes in vs port, anyway I'm still waiting for testing build :)