Forced film decimation algorithm?

[hello_hello]

Pity Katie is still too childish to read post #11 otherwise she wouldn't have needed to ask a question that'd already been answered.

Has anyone ever used "honour pulldown flags" for a 100% film source and then applied TIVTC only to find didn't do a perfect job? Surely that must be extremely rare. If fields are simply being duplicated on playback and IVTC can't easily reverse the process, something must be wrong. Same with decimation when there's a nice consistent pattern.
I work with PAL a lot more than NTSC but I don't think I've ever seen field matching/decimation get it wrong when the pulldown is being applied by honouring pulldown flags.

[Katie Boundary]

Originally Posted by manono

And that justifies your sometime irrationality?

Yes. My obsessive-compulsive demons make strange demands.

[manono]

As you may or may not know (although you should), the TIVTC filter has the capability of treating soft telecine as if it was Forced Film and only IVTC the hard telecine. This greatly lessens the chances of the IVTC making wrong decisions. Although, as hello_hello mentioned in his previous post, it hardly ever makes mistakes anyway, when IVTCing soft telecine.

You just make the D2V using 'Honor Pulldown Flags' and set up the IVTC something like this:

TFM(D2V="Movie.d2v")

It's all explained in the doc. This removes almost all uncertainty when running one of those 99.50% Film D2Vs through an IVTC,

And in cases when some frames just have to be post-processed (deinterlaced) when no matches can be found, you can have it use something other than its own TDeint, the much better QTGMC, for example.

[Katie Boundary]

Yes, the d2v parameter is extremely useful for sorting out the 99.97% of the file that's soft-telecined. I'm curious as to whether it triggers off of "progressive" flags or the "0-1-2-3" pulldown flag pattern, seeing as how some DVD authors are incompetent and don't line the two up, and that could cause problems for the remaining 0.3%, but that's a totally different discussion.

Also, my preferred pp/Clip2 parameter is yadif, but there's already a thread about that. And TFM doesn't use Tdeint as its default post-processor. The default is motion-adaptive cubic, presumably with values of b=0 and c=1 because it leaves the original scanlines untouched (I checked).

[hello_hello]

Originally Posted by Katie Boundary

Also, my preferred pp/Clip2 parameter is yadif, but there's already a thread about that. And TFM doesn't use Tdeint as its default post-processor. The default is motion-adaptive cubic, presumably with values of b=0 and c=1 because it leaves the original scanlines untouched (I checked).

TDeint(type=0)?

[manono]

Originally Posted by Katie Boundary

I'm curious as to whether it triggers off of "progressive" flags or the "0-1-2-3" pulldown flag pattern...

It's all explained in the readme. Because, as you say, it happens sometimes that hard telecined (or pure video) material is encoded as progressive (although very rarely), it has that base covered. It reads off of the TFF/RFF flags shown in the D2V:

flags -
Controls how much of the info from the d2v file is used when the "d2v" parameter is set.
Possible options:
0 - 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.
1 - Same as 0, plus use the trf flags for field matching in film sections (sections where the trf flags follow the 012301... pattern)
4 - Same as 1, but d2v matches are checked for being combed. If a d2v match is detected as combed then tfm uses its own matching routine for that frame.

4 is the default. So, even if there are interlaced frames when there shouldn't be, it'll still be IVTC'd.

And TFM doesn't use Tdeint as its default post-processor.

As hello_hello mentioned in the previous post (which you don't see, right?), the 'motion-adaptive cubic' to which you referred (from the TFM manual) would be TDeint's Type 0. Because TDeint slightly predates TIVTC, I suppose there's a chance tritical slightly improved on it to be used as the TFM deinterlacer, but they'd be pretty much the same thing.

[Sharc]

Originally Posted by manono

....As hello_hello mentioned in the previous post (which you don't see, right?), the 'motion-adaptive cubic' to which you referred (from the TFM manual) would be TDeint's Type 0. Because TDeint slightly predates TIVTC, I suppose there's a chance tritical slightly improved on it to be used as the TFM deinterlacer, but they'd be pretty much the same thing.

By the way I found TDeint(type=1) to perform very well in some cases where other deinterlacers/bobbers (except QTGMC) produced more artifacts, even for "natural" video.

[Katie Boundary]

Originally Posted by manono

stuff

Originally Posted by Sharc

more stuff

Like I said, that's a different discussion, for a different thread, if you want to start one.

[Sharc]

Originally Posted by Katie Boundary

Like I said, that's a different discussion, for a different thread, if you want to start one.

I added this "stuff" because some people seem to have problems with making QTGMC work on their system but are not satisfied with default TDeint or similar

[hello_hello]

Only Katie could be ungrateful enough to tell people what they can post when replying to a question she asked or a topic she raised. Maybe it's an automatic defence mechanism because she was wrong about something again and would never acknowledge it.

[manono]

Originally Posted by hello_hello

Only Katie could be ungrateful enough to tell people what they can post when replying to a question she asked or a topic she raised. Maybe it's an automatic defence mechanism because she was wrong about something again and would never acknowledge it.

I'm quoting you in my post because she's blocked you, hasn't she? Yes, I was a little bit irritated at her post because I was directly replying to a question she asked. Nothing irrelevant. Maybe she didn't understand the reply and thought it off topic? Who knows?

[Katie Boundary]

Originally Posted by Katie

I'm curious as to <off-topic stuff>, but that's a totally different discussion.

Originally Posted by manono

<the exact same off-topic stuff>

Originally Posted by Katie

Like I said, that's a different discussion

Originally Posted by manono

Maybe she didn't understand the reply and thought it off topic?

This is why people start using heroin.

[Sharc]

Some prefer Vodka, I learned ......

[Katie Boundary]

The original question remains: what are the algorithm details? Does DGIndex drop the 3rd field in a non-progressive frame and then every 5th field in a non-progressive frame afterward? Or what?

[StainlessS]

I think that you already got the answer from VideoH, you want details,
"Read The Source".

[videoh]

DGMPGDec (an evolution of jackei's original DVD2AVI) is written in functional style using C-language constructs. The required C can be learned very quickly. I taught myself C in 2 days using the first edition of the K&R book from zero knowledge of programming and computers; I was a philosopher at that time (later went on for an MSc). I venture to say many of the developers here have a similar history. So the OP should not feel intimidated by C code, and given the logical thinking and analytic mind she has already demonstrated she should be able to master C in hours. Perhaps then the OP would be empowered to contribute useful code to the community, to augment her penetrating questions.

The C Programming Language, 2nd Ed.
Kernighan and Ritchie
https://www.amazon.com/Programming-L.../dp/0131103628

Here is the second edition on-line. It is a true classic in computer science.

http://net.pku.edu.cn/~course/cs101/...medium=twitter

[hello_hello]

Originally Posted by Katie Boundary

The original question remains: what are the algorithm details? Does DGIndex drop the 3rd field in a non-progressive frame and then every 5th field in a non-progressive frame afterward? Or what?

As I said in post #11 two weeks ago, when I tried force film on interlaced content it dropped every fifth frame. Why don't you try it?

If alternate fields consist of odd and even scan lines, and if you removed every fifth field and replaced it with the following one... effectively:
SeparateFields().SelectEvery(5,0,1,2,3).Weave()
wouldn't fields end up on the wrong scan lines?
A deinterlacer could probably still produce progressive frames if the section was interlaced and it could cope with the constant alternating between top field first and bottom field first, but "force film" is generally used under the assumption no deinterlacing is required.

Maybe I'm looking at it the wrong way but I'm not sure dropping fields makes sense.

[videoh]

A field can be dropped by simply ignoring a repeat flag.

[Aa][Ab][Bc][Cd]...

Drop a field:

[Aa][Bb][Cc]...

Fields remain in the proper places.

If there are no repeats then frames can be dropped.

The beauty of jackei's algorithm is that it brilliantly manages the complexity and thereby forces film rate output, regardless of the actual repeat flags present. The way I figured it out was to compare the input fields to the table created in mpeg2source(). As I mentioned earlier, the magic is in the table.

[hello_hello]

I see what you're saying.... if there's switching back and forth between soft pulldown and interlaced, it'd be handled in a clever enough way to ensure a constant 23.976fps, but I had assumed the question was more general in respect to how "video" would be decimated.... in isolation, so to speak.... which is why I tried applying force film to an interlaced source earlier in the thread, and from that perspective it'd be... repeat field flags are ignored for the film sections and any video sections are decimated by dropping frames.

[Katie Boundary]

Originally Posted by StainlessS

I think that you already got the answer from VideoH, you want details,
"Read The Source".

I would if I could find a competently written interactive C/C++ tutorial. Codecademy has a great one for Python and I wish they'd make one for C/C++ as well.

Originally Posted by videoh

I taught myself C in 2 days using the first edition of the K&R book from zero knowledge of programming and computers; I was a philosopher at that time (later went on for an MSc). I venture to say many of the developers here have a similar history. So the OP should not feel intimidated by C code, and given the logical thinking and analytic mind she has already demonstrated she should be able to master C in hours. Perhaps then the OP would be empowered to contribute useful code to the community, to augment her penetrating questions.

The C Programming Language, 2nd Ed.
Kernighan and Ritchie
https://www.amazon.com/Programming-L.../dp/0131103628

Here is the second edition on-line. It is a true classic in computer science.

http://net.pku.edu.cn/~course/cs101/...medium=twitter

I learn best by doing, rather than by reading or by watching videos, which is why I've mucked around with sites like http://www.learn-c.org and http://www.tutorialspoint.com/cplusplus; unfortunately, both of those tutorials have major flaws.

Originally Posted by videoh

A field can be dropped by simply ignoring a repeat flag.

[Aa][Ab][Bc][Cd]...

Drop a field:

[Aa][Bb][Cc]...

Fields remain in the proper places.

Kind of, except that the field order is different. The stream above puts field b before field B; the bottom stream puts B before b. This obviously doesn't matter if B and b were, in fact, from the same original frame and the frames are being displayed progressively.