Forced film decimation algorithm?

[Katie Boundary]

What decimation algorithm do DVD2AVI/DGIndex use when processing 30fps content in Forced Film mode?

[Sharc]

From the manual:
Force Film - This option is intended for the special case of film content encoded at 23.976 fps but pulled down for display at 29.97 fps, i.e., 3:2 pulldown. This option will restore the 23.976 fps film rate while keeping audio and video in sync throughout the clip. This option works by ignoring pulldown flags and inserting/removing frames to maintain a constant and sync'ed output stream. Do not use this option on non-3:2 pulled-down material, and, therefore, never use it on PAL or MPEG1. Also do not use this option on streams containing frame repeats.
Don't know whether this answers your question.

[Katie Boundary]

It doesn't.

[StainlessS]

Basically it just switches off the soft pulldown (does not insert extra frames made up from 2 repeat fields from different frames).
Why it says "inserting/removing", I dont know (so far as I know, it just does not insert extra ones, and only plays the
frames/fields from the original source).
Perhaps someone can clarify the 'insert' of "inserting/removing frames" thing.

[Sharc]

"insertion" as a last resort for badly edited sources with broken pulldown patterns? Just guessing.
The source code which is available for download would probably clarify this, if somebody has the skills and patience ....

[StainlessS]

That sounds like good a guess to me :)

[Katie Boundary]

Basically it just switches off the soft pulldown

There is no soft pulldown in the 30fps parts.

[StainlessS]

Forced Film should not be used on hybrid source, which if it contained '30fps parts' and telecine film parts, it would be (hybrid).

EDIT:
DGIndex, does not support output of Variable Frame Rate, dont know about DVD2AVI but suspect also not.
Using ForcedFilm, is saying that the entire clip is soft telecine, what result you would get from hybrid is to me a mystery.

EDIT:
Force Film - This option is intended for the special case of film content encoded at 23.976 fps but pulled down for display at 29.97 fps, i.e., 3:2 pulldown. This option will restore the 23.976 fps film rate while keeping audio and video in sync throughout the clip. This option works by ignoring pulldown flags and inserting/removing frames to maintain a constant and sync'ed output stream. Do not use this option on non-3:2 pulled-down material, and, therefore, never use it on PAL or MPEG1. Also do not use this option on streams containing frame repeats.

So for hybrid;- Soft Telecine parts, will output the encoded frames, 30fps parts will have fields thrown away to achieve 23.976 output in sync with the audio.

[videoh]

That's correct.

A running tally is kept of the output rate versus 23.976 (after ignoring soft pulldown). If it exceeds that rate then fields are dropped. If it falls short, fields are added. It's reminiscent of Bresenham's algorithm for line drawing. It was conceived originally by jackei, of course. It's generally useful only for relatively small deviations from pure 3:2 pulldown, e.g., when the main movie is 3:2 but intros and credits are not. That is the reason for the conventional wisdom of when to use force film (90-100% film).

[Katie Boundary]

Forced Film should not be used on hybrid source, which if it contained '30fps parts' and telecine film parts, it would be (hybrid).

Yes, I know. However, there are a LOT of discs out there that are almost but not quite pure film - they'll be 99.78% film or 99.12% film or whatever, and I'd like to know just what kind of butchery might be performed on the video if I run such content through forced film.

A running tally is kept of the output rate versus 23.976 (after ignoring soft pulldown). If it exceeds that rate then fields are dropped.

Yes but I'm asking how it chooses which frames to drop.

[hello_hello]

Yes, I know. However, there are a LOT of discs out there that are almost but not quite pure film - they'll be 99.78% film or 99.12% film or whatever, and I'd like to know just what kind of butchery might be performed on the video if I run such content through forced film.

You'll have frames with combing.

Yes but I'm asking how it chooses which frames to drop.

I only tried this because the question was asked and I was curious and thought I might learn something. Katie will probably still be too busy ignoring.

I indexed an NTSC DVD for a look. It was actually PAL converted to NTSC using field blending, but it was handy and that should mean it's 100% video (no pulldown flags) so I created a d2v file using force film and again without it. The d2v files declared it to be 100% video.
I compared the two by opening them with Avisynth and stepped through the frames. The 23.976fps (force film) version obviously had every fifth frame missing relative to the 29.97fps version. It doesn't seem any more clever than that.

I've never been a fan of force film myself. I recall having problems when I was quite an NTSC novice with a particular DVD because it had a few small sections with hard-coded pulldown while the majority used pulldown flags and there was combing in the sections with hard-coded pulldown. Since then I've always honoured pulldown flags and taken the TFM().TDecimate() route and more recently, for hybrid sources, I've been using TIVTC for VFR encoding. x264 is VFR aware if you give it a timecodes file so it's not that hard. Harder for mpeg2/Xvid. Not VCD compatible.

[manono]

However, there are a LOT of discs out there that are almost but not quite pure film - they'll be 99.78% film or 99.12% film or whatever, and I'd like to know just what kind of butchery might be performed on the video if I run such content through forced film.
If you're lucky the video portions will be some black frames at the beginning or end or perhaps some black during a fade and nothing bad happens.

However, there are a lot of cases where a DVD might drop to video briefly during some live action and in such cases you'll get some brief interlacing. For example, the Criterion DVDs drop to video around chapter points often, and they'll give you a couple of very noticeable interlaced frames.

To be safe, it's not a good idea to use Forced Film unless the D2V shows it to be 100% Film.

[StainlessS]

Yes but I'm asking how it chooses which frames to drop.

Each field will have a time stamp (I think), and the ones that are closest to the required output time (@23.976) will be kept, and the ones furthest from req time will be dumped. (methinks)

NOTE, fields (top and bottom) dropped rather than frames.

[videoh]

Each field will have a time stamp (I think), and the ones that are closest to the required output time (@23.976) will be kept, and the ones furthest from req time will be dumped. (methinks) That is not true. The source code is available if anyone wants to understand the algorithm.

[Katie Boundary]

To be safe, it's not a good idea to...

Well, that just guarantees that I'll try to do it.

That is not true. The source code is available if anyone wants to understand the algorithm.

Perhaps you could be kind enough to explain it to those of us who don't speak C++?

[videoh]

For 3:2 pulldown you expect as you traverse the stream to see a certain rate of RFF flags. If the rate falls below, then you mark the current field to be repeated. If the rate gets too high, then you mark a field to be discarded. As I mentioned earlier, it is reminiscent of Bresenham's line drawing algorithm. MPEG2Source() creates a table this way and then uses it to decide what to return based on the requested frame number. Most of the magic is in the table and how you actually implement pulling down or deleting fields to generate the output frames.

https://www.cs.helsinki.fi/group/goa/mallinnus/lines/bresenh.html

Typically, the RFF rate gets too low, e.g., where you have a video section, or where you have hard pulldown instead of soft. But it is possible to have a too-high RFF rate, and that is why the algorithm allows for it.

[Katie Boundary]

Does this mean that, if a source was originally 100% film but it gets transferred to DVD as a mix of "hard" and "soft" telecine, Forced Film will deduce the correct fields to drop based purely on the disruptions in the pulldown pattern?

[manono]

Does this mean that, if a source was originally 100% film but it gets transferred to DVD as a mix of "hard" and "soft" telecine, Forced Film will deduce the correct fields to drop based purely on the disruptions in the pulldown pattern?
No, it means no such thing. That kind of source is where you find film percentages of less than 100% in the D2V. And if the film percentage is less than the 95% often given as the point below which you shouldn't use 'Forced Film' (although I think it's an arbitrary and misleading figure), you're almost guaranteed to wind up with some interlaced frames and some jerky-playing places.

What's the big deal? Just make the D2V using 'Honor Pulldown Flags' and IVTC it if it's a mix of hard and soft telecine, no matter the percentage. That's much better than going through the whole conversion process and later noticing a few interlaced frames here and there.

[Katie Boundary]

What's the big deal?

* no field-matching filter is perfect.
* decimation filters are even less perfect
* Some TV shows on DVD will be encoded in an odd way wherein some episodes will be pure film and others will be 98%-99.99% film, and it's annoying to have to check DGindex results to see which field operation I should have used and which avisynth scripts need the extra TFM(mode=0,pp=0,micmatching=0).tdecimate() and which ones don't.

As my sig says... "Katie reasons"

[manono]

* no field-matching filter is perfect.

They can be tweaked in those rare instances when the defaults don't work perfectly. It's still way better than using Forced Film when you shouldn't have and only finding out later after having done all the work. And you can parse the D2V to find out where the video portions are and decide if you should handle it differently (if, for example, the little bit of video is during harmless black frames and not some active video).
* decimation filters are even less perfect
Same as before.
...and it's annoying to have to check DGindex results to see which field operation I should have used...
The D2V is easily edited so you don't have to run the whole thing all over again.
As my sig says... "Katie reasons"
And that justifies your sometime irrationality?

With 'quirky' sources, yes, deciding what to do can be a pain in the ass. Sometimes there's no 'right' way. You've fooled with enough of the space shows with the CGI that messes everything up to know this already.

[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]

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]

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]

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]

....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]

stuff

more stuff

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

[Sharc]

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]

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]

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

<the exact same off-topic stuff>

Like I said, that's a different discussion

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-Language-Brian-W-Kernighan/dp/0131103628

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

http://net.pku.edu.cn/~course/cs101/2008/resource/The_C_Programming_Language.pdf?utm_source=twitterfeed&utm_medium=twitter

[hello_hello]

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]

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.

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-Language-Brian-W-Kernighan/dp/0131103628

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

http://net.pku.edu.cn/~course/cs101/2008/resource/The_C_Programming_Language.pdf?utm_source=twitterfeed&utm_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.

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.

[videoh]

Obviously I was talking about the spatial placement as that was the point raised by hello_hello. B and b are the top and bottom fields of a single progressive frame, so it doesn't matter what order they are displayed in. They don't have to be displayed together in the same frame as you claim; indeed that is why you see 3 interlaced frames followed by two progressive when stepping by frames. 3:2 pulldown was designed to put film on interlaced 29.97fps (NTSC). If all this were not the case then 3:2 pulldown would not work and would be useless. And applying pulldown to non-progressive frames is stupid. So many pedants and quibblers at this forum!

Sorry to hear about your learning limitations. It explains a lot.

[StainlessS]

Katie, this intended more for those who already have some coding experience, but maybe of some use (at least to get the gist of it).

https://learnxinyminutes.com/docs/c++/

Was brought to my attention as link (to Python I think) in Vapoursynth docs.
(Lots more Learn X in Y minutes, from the home page).

Not interactive.
EDIT: Took me way more than 2 days to learn C.

EDIT: Actually, above was for CPP, here for C:- https://learnxinyminutes.com/docs/c/

And the parent page with bucket loads more subjects:- https://learnxinyminutes.com/

[videoh]

IMO, any book can be made "interactive" by simply typing the examples into a compiler and running them, single-stepping them, looking at the variables, trying out small modifications, etc.

[Groucho2004]

Katie, this intended more for those who already have some coding experience, but maybe of some use (at least to get the gist of it).

https://learnxinyminutes.com/docs/c++/
That's just horrible.

It used to be "Learn C/C++ in 7 days", then 24 hours, now it's minutes (WTF?). These things always fall short, mainly because they tell you what do to but not why.
Kernighan and Ritchie is hard to beat for plain C.

[StainlessS]

I took copies of about 10 or 12 pages from that site, when trying to figure out what a python script was doing and why it did not work for me.
(called something like "Avisynth Trackin", or similar, track moving objects frame by frame).

With help of the XinYmins thing, was quickly able to figure out that it was because I had Phython 3 installed, and Trackin thing required v2.???.
(I got it workin OK, IIRC, Print works different for v2.0 and v3.0, Function(v3) instead of Subroutine, I think)

Handy to have if you just want to get at something quick.

Worst part for me learning C was figuring out where all of them there damn Semi Colons (';') went, seemed like you just liberally scattered
them wherever there seemed to be too much white space.
(K&R for me too, I remember studying for days, the Bachus Naur notation [or something like that] at the back of the book).

EDIT: Backus–Naur,
https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_form

EDIT: Search Google C interpreter for do it yourself, interactive play time:- https://www.google.co.uk/search?site=&source=hp&q=C+interpreter&oq=C+interpreter&gs_l=hp.3..0l10.2049.4681.0.4909.13.13.0.0.0.0.137.1172.9j3.12.0....0...1.1.64.hp..1.12.1166...0i131k1.6UXaWXRe-F0

[flossy_cake]

This thread was very informative, thank you.

There is however one problem still: my Sony DVD player, when playing soft telecine content which contains 95% film, is able to do something DVD2AVI's "force film" cannot do: detect those 5% combed frames by looking at frame flags. I believe our current tools only allow this to be done by analysing pixels for combing patterns. Obviously it would be better to use the frame flags since that is more reliable (well, assuming the post company or software they used didn't muck it up :rolleyes:)

It appears that LWlibavVideoSource(repeat=false) is able to get those frame flags in real time as it updates the _FieldBased frame property every frame. But LWLibAVVideoSource is bugged and cannot play back the video at correct speed when doing this - it's some sort of bug, it plays 23.976 at around 24.1. I have mentioned it on the git issues thread here (https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/issues/24#issuecomment-1336262493).

DirectShowSource has a similar problem - it gets it right for a while, but then after a while audio sync goes out (or it just randomly starts stuttering really badly, depending on convertfps=true/false setting).

So for now the only 2 real-time options for handling soft telecine seem to be:

Option 1: use FFmpegSource2(rffmode=2) which uses DVD2AVI's "force film" mode which outputs 95% progressive frames (23p) at the correct speed. Then for the 5% combed frames, manually detect & deint them with IsCombedTIVC (or whatever your preferred filter is for detecting combed frames).

Option 2: use LWlibavVideoSource(repeat=true) or FFmpegSource2(rffmode=1) , which will convert it to hard telecine (29i). Then use TFM.TDecimate to convert it back to 23p.

Here is a test clip recommended as short clips I find tend to have broken frame flags and led me to numerous false conclusions https://drive.google.com/file/d/1xz_WEX36iv8tpC18zR8e8-etGwtqfuVb/view?usp=share_link . This is MPEG2 remux from the NTSC DVD and hasn't been clipped or altered in any way apart from putting it inside a mkv container.