rff flag property

[realfinder]

Hi can we got repeat field flag property? https://forum.doom9.org/showthread.php?p=1967719#post1967719

[ghost]

If you add RFF and TFF flags we can use Ignore Field Pulldown, detect VFR and skip decimate :)

[Asd-g]

Try the attached version. There is a frame property _RepeatedFirstField and _TopFieldFirst.

D2VSource.zip

[ghost]

Something is off, on a film section I should get something like a 3012 pattern (11000110).

Sorry, now it works. Seems if you do "ignore" the flags get wiped out.

I checked and in the D2V file with ignore pulldown flag the flags are present, why the RFF flag is not displayed in this case?

[realfinder]

it said _RepeatedFirstFrame here, is this ok?

[Asd-g]

I checked and in the D2V file with ignore pulldown flag the flags are present, why the RFF flag is not displayed in this case?

They are still there but are ignored (Field_Operation=2 in the d2v file).

it said _RepeatedFirstFrame here, is this ok?

It's typo.

[ghost]

It's not possible to get the flags with Field Operation = 2? If I don't I can't detect film/VFR sections :(

[Asd-g]

Try this version. There is a new parameter ff (default false). You want it ff=true in order to decode the raw stream (without repeated fields) and the rff flags from the d2v file to be displayed as a frame property.

D2VSource.zip

[realfinder]

ff seems not do anything in my test

anyway what about take the vs path?

dvsource in vs got

    nocrop  - Always use direct-rendered buffer, which may need cropping.
              Provides a speedup when you know you need to crop your image
              anyway, by avoiding extra memcpy calls.
    rff     - Invoke ApplyRFF (True by default)

nocrop is offtopic but it also welcome :)

[realfinder]

also, Asd-g, can you take a look at https://forum.doom9.org/showpost.php?p=1967913&postcount=62 using this sample ? I think the rff and the tff kinda random to make _ToDecimate

edit: another sample https://www.mediafire.com/file/k9o6gu5rqf27xqd/VTS_01_2.demuxed.m2v/file

[Asd-g]

ff seems not do anything in my test

You must have Field_Operation=2 in the d2v file (DGIndex->Video->Field Operation->Ignore Pulldown Flags).

Actually these frame properties _RepeatedFirstField/_TopFieldFirst should be set only when the stream is decoded without repeated fields (Field_Operation=2/DGIndex->Video->Field Operation->Ignore Pulldown Flags).

Edit: both samples with Field_Operation=2 have the expected _RepeatedFirstField/_TopFieldFirst values.

[realfinder]

Actually these frame properties _RepeatedFirstField/_TopFieldFirst should be set only when the stream is decoded without repeated fields (Field_Operation=2/DGIndex->Video->Field Operation->Ignore Pulldown Flags).

can it also be updated to work with Field_Operation=0 too?

also can ff be replaced with vs "rff - Invoke ApplyRFF (True by default)"?

[Asd-g]

can it also be updated to work with Field_Operation=0 too?

The number of the rff flags is the same as the number of the frames of the raw stream (Field_Operation=2).

Field_Operation=0 (Honor Pulldown Flags) = the raw stream (same as Field_Operation=2) is read, the rff flag is read too and then the final video is decoded with repeated fields (if there are). So a correct _RepeatedFirstField frame property (for Field_Operation=0) should be result of the rff flags for the frames from the raw stream and some other value (3 for example) for the constructed frames from the rff flags. Is there a use case here?

also can ff be replaced with vs "rff - Invoke ApplyRFF (True by default)"?

This means change between Field_Operation=0 and Field_Operation=2 on fly. Is that what you mean?

[videoh]

I would like to propose the following:

http://rationalqm.us/board/viewtopic.php?f=7&t=1158

[ghost]

I managed to detect VFR with ff=true but I'm off of a few seconds, so it means I have some false positive due to post telecine editing. Tomorrow I will try to figure out the problem. So yeah, the attached version works flawlessly.

[realfinder]

Field_Operation=0 (Honor Pulldown Flags) = the raw stream (same as Field_Operation=2) is read, the rff flag is read too and then the final video is decoded with repeated fields (if there are). So a correct _RepeatedFirstField frame property (for Field_Operation=0) should be result of the rff flags for the frames from the raw stream and some other value (3 for example) for the constructed frames from the rff flags. Is there a use case here?

kinda of, I just need to know the raw frame that got TFF and RFF to know that the next frame after it will be Decimate (you can read or test my code to see)

This means change between Field_Operation=0 and Field_Operation=2 on fly. Is that what you mean?

yes, don't know how D2VWitch work but I think it don't has anything but "Honor Pulldown Flags" so the vs d2vsource got this option

[realfinder]

I would like to propose the following:

http://rationalqm.us/board/viewtopic.php?f=7&t=1158

Hi DG, let see what CeppoTools and Asd-g will said but I think your suggestion is the best, but still I don't get why you put honor and force film is same case, isn't better to put force film alone? or with ignore rff?

[videoh]

IIRC, force film is just honor with additional frame repetition/decimation as needed to hit 23.976 (I'll double check that). Assuming that is true, the point is that they both do repeat fields so that you no longer have the unpulled down progressive frames. So in both cases we want to signal what got pulled down. Ignore is the only case where you get the original progressive frames.

[ghost]

The original problem is to detect VFR, so either DGIndex generates a VFR file when using "ignore", or we make a plugin that creates the VFR file. If we use ignore we have the progressive source (+VFR file) we only need to deinterlace 60i and post telecine cuts. So no need for field matching / decimate.

[realfinder]

detect VFR is not a problem, all _FieldBased=0 are 24 fps whether they Combed or not, and the others will depend on the ivtc plugin like how your ctools work before adding "3:2 pulldown" (soft pulldown)

[ghost]

My source has VFR frames with _FieldBased=0 due to post telecine editing.

[realfinder]

then in this case you need to make some codes in the ivtc plugin for these cases, I think tfm did the same

[Asd-g]

I'm ok with the @videoh suggestions.

[videoh]

That's great, thank you. I updated the proposal yesterday to suggest the following int variables:

_FO _TFF _RFF

Probably better to have separate variables to avoid having to do bit operations. I'll go ahead and implement this in my stuff. BTW, your body of work is very impressive!

[Asd-g]

BTW, your body of work is very impressive!

I can tell the same thing for you too.

[realfinder]

I note vs d2vsource has _AbsoluteTime

    float _AbsoluteTime   
    The frame’s absolute timestamp in seconds if reported by the source filter. Should only be set by the source filter and not be modified. Use durations for all operations that depend on frame length. 

maybe this can help in your case? CeppoTools

also Asd-g, vs d2vsource seems has multi threads MPEG2 decoder, can we got update for it too? maybe it may case some problems in some cases or sources so maybe it can be made if with threads=1 it back to current old single thread MPEG2 decoder

edit: also there are missing _ColorRange and _ChromaLocation in avs d2vsource

[Asd-g]

The vs d2vsource is using the ffmpeg decoders so it's more or less similar to ffms2/lwlibavvideosource. Did you compare it against lwlibavvideosource (loading m2v)?

[realfinder]

didn't compare it but CeppoTools note that ffms2 is faster than avs d2vsource in doom9 posts, but if it the same then why they rewrite d2vsource and D2VWitch from scratch?

I will ping @myrsloik @dwbuiten @dubhater then to see what they will say and maybe they can help in "3:2 pulldown" (soft pulldown) cases above, the goal is https://forum.doom9.org/showthread.php?p=1967314#post1967314

anyway the multi threads MPEG2 decoder is not very important, better focus on the rest

[ghost]

@realfinder What's wrong with https://forum.doom9.org/showthread.php?p=1968121#post1968121, isn't better to create stuff that do stuff with the vfr file? I don't see the point of honoring the pulldown then remove it back, IMO it's a waste of time.

[realfinder]

it use HDD/SSD space and I remember ffms2 not work with hybrid DVD I got back then (it show it with random sections and skip others IIRC)

anyway if you don't want d2v/frame properties support in your plugin then it's fine it's up to you in the end, but there are tivtc and http://avisynth.nl/index.php/Decomb by @videoh and many others that can support these frame properties :)

edit: also the videoh suggestion has both cases (with and without honoring the pulldown)

[ghost]

@realfinder I will add them in the next version anyway since already I have the code, but they are not reliable so you are not getting the best result, that's what I mean. EDIT: you need ffvideosource only to extract the timecode you are not forced to use it for decoding. EDIT: and it would be a piece of cake if dgindex would extract the timecode file in a mkv timecode format anyway. EDIT: I was thinking maybe a double call of the filter would work, like 1 pass from the flag and 2 pass from the metrics, and the last field matching script that i made can also detect 60i

[realfinder]

maybe the timecode file will be ok maybe not (since as I said about the dvd I got before)

and I don't get the point of the ffms2 timecode file, theoretically it can be made even with simple avs some code using _FieldBased==0 to mark the 24 fps sections and then do analysis pass

also if you still don't believe me about ffms2 and the DVDs read starting from https://forum.doom9.org/showthread.php?p=1912901#post1912901 (note the manono, StainlessS posts)

[ghost]

I agree, but ffvideosource doesn't create the timecode it just extract it from the source, it's a file inside the m2v, you refresh a freame and it creates it, if it is wrong the source wil play wrong as well and I don't think they sell dvds off synch or stuff like that.

[realfinder]

I agree, but ffvideosource doesn't create the timecode it just extract it from the source, it's a file inside the m2v, you refresh a freame and it creates it, if it is wrong the source wil play wrong as well and I don't think they sell dvds off synch or stuff like that.

I don't think there are timecode in dvd https://forum.doom9.org/showthread.php?p=1923432#post1923432 (note the "pseudo vfr") it just made it from soft vs hard sections

[ghost]

@realfinder It does have it. The dvd player often ignore the soft pulldown, then it gets a mixed frame rate for example the credits. It has a timecode to read those mixed stuff right. If you don't believe me demux a m2v and use mediainfo, you will see there is a text file attached to the video.

[realfinder]

you mean this?

Text
ID                          : CC3
Format                      : EIA-608
Start time (commands)       : 2 s 2 ms
Start time                  : 2 s 970 ms
Bit rate mode               : Constant
Stream size                 : 0.00 Byte (0%)
Count of frames before firs : 72
Type of the first event     : PopOn

https://en.wikipedia.org/wiki/EIA-608

and even so, it still for soft vs hard sections (it just do ApplyRFF to make all the sections as 60i to send them to the tv since no tv can do read VFR or even dvd pseudo vfr :) ) since I don't think "dvd player often ignore the soft pulldown"...

[videoh]

The video-related timestamps are:

GOP timestamps: not per-frame DTS/PTS timestamps: notoriously unreliable

Hopefully Ceppo will enlighten us on which timestamps/timecodes he is referring to.

[dubhater]

I will ping @myrsloik @dwbuiten @dubhater then to see what they will say and maybe they can help in "3:2 pulldown" (soft pulldown) cases above, the goal is https://forum.doom9.org/showthread.php?p=1967314#post1967314

🧐😵‍💫🤑

[ghost]

It was wrong of me to assume stuff to give an explanation basing myself of the observation of an empirical result. Still, ffvideosource got the timestamp right from 3 cursed DVD sources of mine, so there must be data in the stream that it uses, otherwise, I got a perfect result 3 times from a random process and in my opinion it is very unlikely. Still, I have no objective explanation as to why it works. Only ffmpegsource author can give us that. So either is meant to or it just happened to work.

It was also wrong of me to say that the flags are not reliable. All I can say is that I was not able to get good results. So maybe TIVTC and DECOMB authors, if they are interested in your idea, will do better than me since they have much much much ... more skills than me.

Also the claim that VFR can be done in 1-pass, I don't see it possible since you don't know the output frame count, so you will get the last frame repeated too match the source frame count. But once again this is just me and my limited knowlodge.

I hope more expert programmers can figure it out so that all the community of encoders can benefit from it.

[videoh]

"so there must be data in the stream that it uses"

Thank you, Captain Obvious. But that doesn't mean there is anything other than the video frames themselves, the pulldown flags, and the DTS/PTS flags. Given your sorely limited knowledge of the theory and software, why don't you actually study the specs and the algorithms used by ffmpeg, etc.?

Nobody needs to "figure it out". It's all been well understood for decades.

[realfinder]

Also the claim that VFR can be done in 1-pass, I don't see it possible since you don't know the output frame count, so you will get the last frame repeated too match the source frame count. But once again this is just me and my limited knowlodge.

tivtc has 1-pass vfr since ages, TIVTC authors for now dubhater for vs and @pinterf for avs since tritical no longer active

[ghost]

videoh You started calling me stupid and stuff otherwise I would never have done it. And nope, I don't feel good insulting people.

Anyway I'm off this stuff, since it seems there is a lot I don't know and I can't be of help.

EDIT: Also, you don't need to help me. This is realfinder request that you can see in the doom9 post above. I was trying just to help him. So, if I can't help him, I have no reason to continue this. Aside from pointing out my mistake for who will read this, there is nothing more I can do. If for obscure reason someone needs me, you can PM me on doom9, I will turn off notifications now.

[realfinder]

@CeppoTools you can take a rest, thank you for all things you did :) but you can wait until Asd-g final update to see if you can do something

videoh, what FO https://github.com/Asd-g/MPEG2DecPlus/issues/9#issuecomment-1107890122 mean here? force film?

so, I got this

D = DoubleWeave()
M = CTelecine() #or any field matching filter like tfm(pp=0)
Q = M.CPostProcessing() #or any alternative available
ScriptClip("""
ATOP = PropGetInt("_EncodedFrameTop")
ABOT = PropGetInt("_EncodedFrameBottom")
FIELD = PropGetInt("_FieldBased")
rff = PropGetInt("_RepeatedFirstField", offset=-1) #it don't need the offset if videoh suggestion done
tff = PropGetInt("_TopFieldFirst", offset=-1) #it don't need the offset if videoh suggestion done
FIELD != 0 ? Q.Subtitle("Not Soft",400) : \
ATOP != ABOT ? D.DuplicateFrame(0).SelectEven().Subtitle("Soft Match",400) : last.Subtitle("No Match",400)
FIELD == 0 && IsCombedTIVTC() ? M.Subtitle("Bad Soft",400) : last
rff == 1 && tff == 1 && FIELD == 0 ? propSet("_ToDecimate", 1) : propSet("_ToDecimate", 0)
""")

[realfinder]

better idea

D = DoubleWeave()
M = CTelecine() #or any field matching filter like tfm(pp=0)
ScriptClip("""
ATOP = PropGetInt("_EncodedFrameTop")
ABOT = PropGetInt("_EncodedFrameBottom")
FIELD = PropGetInt("_FieldBased")
rff = PropGetInt("_RepeatedFirstField", offset=-1) #it don't need the offset if videoh suggestion done
tff = PropGetInt("_TopFieldFirst", offset=-1) #it don't need the offset if videoh suggestion done
FIELD != 0 ? M.propSet("_FieldMatchingOnly", 0).Subtitle("Not Soft",400) : \
ATOP != ABOT ? D.DuplicateFrame(0).SelectEven().propSet("_FieldMatchingOnly", 1).Subtitle("Soft Match",400) : last.propSet("_FieldMatchingOnly", 1).Subtitle("No Match",400)
FIELD == 0 && IsCombedTIVTC() ? M.propSet("_FieldMatchingOnly", 1).Subtitle("Bad Soft",400) : last
rff == 1 && tff == 1 && FIELD == 0 ? propSet("_ToDecimate", 1) : propSet("_ToDecimate", 0)
""")

So now the Post Processing will be another story, but whatever happen, when _FieldMatchingOnly=1 there will be never Post Processing

[videoh]

FO - Field Operation

Same semantics as DGIndex.

[realfinder]

@Asd-g any news about adding videoh suggestion?

[videoh]

Here is a test version for the flags in DGDecode (64 bit version). It works with DGMPGDec 2.0.0.6. If it works OK then I will release it with source code. Then Asd-g's life will be easier. ;)

Note that I also added a new property _FieldOrder, which is the display order and is distinct from _TFF.

http://rationalqm.us/misc/DGDecode_test.zip

Probably we should change _FO to _FieldOperation so it doesn't get confused with _FieldOrder, and people don't have to wonder what it means.

[realfinder]

thanks DG! but seems this https://github.com/Asd-g/MPEG2DecPlus/issues/8 still not fixed in your side, and yes it's better to change _FO to _FieldOperation

[realfinder]

with https://www.mediafire.com/file/5v5wopo7w28bwwm/INTRO.demuxed.m2v/file at least in FieldOperation=0 the _TFF is always 1, seems it bug?

[videoh]

Thank you for your testing, realfinder.

Regarding _TFF for Field Operation 0/1

TFF is defined per spec as which field to pulldown when doing pulldown. It is associated with the frame before pulldown, with 4 frames per cycle. After pulldown (FO=0/1) there are 5 frames, so the association is lost. Note that _TFF has nothing to do with the display field order (_FieldOrder). So I should set it to -1 to signal inapplicable. This would be explained in the documentation. In the test build I just repeated _FieldOrder, which is misleading. Meanwhile, of course, _RFF's interpretation depends on _FieldOperation, so it is applicable in all modes.

Regarding _FieldBased

The definition is:

"If the frame is composed of two independent fields (interlaced). 0=frame based (progressive), 1=bottom field first, 2=top field first"

This is ambiguous! There are 3 ways to know if the frame is progressive in content. 1) progressive_frame flag, 2) the GOP progressive flag, and 3) actually compare the top and bottom fields. Currently I use #2. But there is a problem with changing it to progressive_frame: again, it applies to the unpulled-down frames and association is lost after pulldown. Also, after pulldown, a frame may no longer be progressive! How would you like that handled? I'll think about it more too.

So far:

_FO -> _FieldOperation _TFF for FO=0/1 -> -1 _FieldBased -> still to discuss.

Awaiting your reply.

[realfinder]

_FieldBased determined by progressive_frame.

that fine, and it's same as this MPEG2DecPlus do now

_TTF for FO=0/1 -> -1

in this case, can it be done using _RFF, _EncodedFrameTop and _EncodedFrameBottom?