@trbarry: How to flask into progressive some *false* interlaced PAL movies? understand, especially, referring, because, several

andy

There are few PAL DVD titles, of course regularly at 25fps,
that have *SOME* parts (scenes) with frames shifted by one field.
This DVD mastering malpractice (IMHO) results in the most stupid and, in this case quot;wantedquot;, interlace effect.

Excuse me, I referring to you because you know well this matter and may understand me fast just after you read this post and especially by this post when I guess that a simple script can't solve *smartly* the interlace effect, because there are several entire scenes without interlaced frames (not even one, at all).

It shouldn't be intended as request , I'm curious if you already now this stupid problem (and if you maybe consider a problem as I do...).

Naturally, Anyone know or have solved this problem is welcome!!

Two of these titles are (that I remember):
- Indipendence Day
- Star Trek: The Motion Picture (partly rearranged, remastered, great great film )

unplugged -

I thought GreedyHMA (and Decomb too, without decimate) could already handle this situation. For instance:

GreedyHMA(1,0,2,0,0,0,0,0) will look at each top field and match it with either the bottom field of the current or prev frame, whichever matches best.

GreedyHMA(0,0,2,0,0,0,0,0) will look at each bottom field and match it with either the top field of the current or prev frame.

I think Decomb does something similar and even though I wrote GreedyHMA  I often use Decomb these days because I don't have to figure out what the stupid TopFirst parm should be.

I think for filters like this the only NTSC/PAL difference is for NTSC you also have to figure out which duplicates to drop. But the field matching and deinterlace is similar.

- Tom

I think Decomb does something similar and even though I wrote GreedyHMA I often use Decomb these days because I don't have to figure out what the stupid TopFirst parm should be.

Ah, that is music to my ears. I'm sure Tom remembers from our discussions that the field dominance immunity was a major design goal of Decomb. Of course, it costs something computationally.

To fix this, use Telecide() from the Decomb package. Don't use Decimate() unless you also need to drop duplicates, as Tom said.

Very Well!

I think also much other non-indepth guys like me will be pleased, thank you.
Never known that filters like GreedyHMA and Decomb could perform tasks (slightly) different from (de)interlacing or frame conversion.

Doh! I have underrated these!

About Graft's Decomb.dll documentation

Forcing Matching Reversal.  Some DVDs have been seen to output some out-of-order bottom fields, causing IVTC failure. This (and other similar situations) can sometimes be corrected by forcing Telecide to reverse the sense of its field matching (instead of matching on the second field, match on the first field). This is worth a try if you find that a lot of seriously interlaced frames are coming through Telecide. It may also be useful when there are a preponderance of blended fields limited to the second field.
LoadPlugin(quot;decomb.dllquot;) AVISource(quot;mixed.aviquot;) Telecide(reverse=true)

First of all, as I have understood:
First field = EVEN lines (field 0)
Second field = ODD lines (field 1)
Am I right?

Why, by default, is matching referred on second (ODD) field?

The only thing that I know is that *generally* the ODD field come before the EVEN in time-line (with full 50semifps interlaced content)

When in the middle of a scene change we just have a combined frame, why having a fixed point for comparison (second field or first field if reverse=true ) for progressive-frame reconstruction instead of looking back and ahead to find the best integral frame? (from scene A or scene B)
I mean the less worst couple of fields and choose it as dominant for frame reconstruction...

what to do with situations like this?

The fixed reference point (first field or second) maybe needed because if we dinamically choice the most integral frame we are going to stack positive or negative delay to the video time line...     ? ?

@unplugged

Allow me to expound first and then I will address your specific questions.

Here's what Telecide does by default. When it receives a request for a frame it gets access to the previous frame, the requested one (called the current frame), and the next frame. Here is what he sees (where P=previous, C=current, N=next, t=top field, b=bottom field):

Code:
Pt  Ct  Nt
Pb  Cb  Nb
Telecide makes 3 combinations of frames from the available fields (this is the big difference from GreedyHMA, which makes only 2 and is therefore sensitive to field dominance -- this should become clear as the explanation proceeds). Here are the combinations:

Code:
Pt
Cb

Ct
Cb

Nt
Cb
Now each of these frames is checked for combing. The least combed frame is the output frame (assuming no pattern guidance). It is that simple.

Now let's consider a 3:2 sequence:

Code:
At  Bt  Bt  Ct  Dt
Ab  Bb  Cb  Db  Db
Consider the matching of the third frame. Telecide matches Cb from the current frame with Ct of the next frame.

Now consider the same sequence with reversed field dominance:

Code:
Ab  Bb  Cb  Db  Db
At  Bt  Bt  Ct  Dt
Now Telecide matches Bt from the current frame with Bb from the previous frame. So, to be immune to field dominance, it is clear that both the previous and following frames must be checked.

The reverse option to Telecide just makes him reverse which field in the current frame is used to make the 3 combinations. So the 3 frames checked would be:

Code:
Ct
Pb

Ct
Cb

Ct
Nb
It doesn't much matter which way you set the reverse option because Telecide will find the progressive frames either way. When it does matter, however, is when you have some problem fields limited to one or the other of top or bottom. The classic example is blended fields. You may be able to find good matches without blends if the blends are in just the top or bottom fields. Beyond that the reverse option doesn't have much use. It doesn't reverse the field dominance of the output stream, for instance.

Now I can answer your questions.

First of all, as I have understood:
First field = EVEN lines (field 0)
Second field = ODD lines (field 1)
Am I right?

That opens a can of worms of field terminology. I don't worry about it because Telecide doesn't care anyway!

Why, by default, is matching referred on second (ODD) field?

The only thing that I know is that *generally* the ODD field come before the EVEN in time-line (with full 50semifps interlaced content)

I had to pick top or bottom and that's what I happened to pick. As I said it doesn't really matter.

If we KNEW the field order and that it wouldn't change during the clip, then we could center on the right one and do only two frame comparisons (that's what GreedyHMA does). But it was a design requirement of Telecide to not require specification of field order and to be adaptive to intra-clip changes in field order. Therefore, I just chose bottom and matched to the three possible tops.

When in the middle of a scene change we just have a combined frame, why having a fixed point for comparison (second field or first field if reverse=true ) for progressive-frame reconstruction instead of looking back and ahead to find the best integral frame? (from scene A or scene B)
I mean the less worst couple of fields and choose it as dominant for frame reconstruction...

Yes, we do want to check forward and backward, but there is no need to change the field we are matching on. See above. As long as we can check forward and backward, we are guaranteed to emit progressive frames.

what to do with situations like this?

Your example showed a case where the scene changed between fields of a frame. It looks like this:

Code:
?t  At  Bt
Ab  Bb  ?b
Telecide matches Bb with Bt. As long as there are no fields missing, the matching field will be there either before or after.

Hope that helps. Maybe I should add this to the documentation.

@unplugged

By the way, I really love your sig: quot;First of all the conceptquot;!

I also love unplugged´s sign. This I wanted to mention for quite some time, but never managed to ...

To the problematic fields:

Two days ago, I recorded quot;Welt am Drahtquot; from digital satellite (3h17min play time, PAL).
This is after the novell quot;Simulacron 3quot; from Daniel F. Galouye, FYI.

(I have waited 11 years for this movie to appear again on TV. I had a VCR recording, which my father deleted erraneously...   a big party is to come now!)

Well, there seems to have been some little mastering errors: I´ve capped with 0 drop frames, but there are a couple of missing fields.
Browsing through the source with a simple quot;ComplementParity.SeparateFields.trim(1,0).weavequot; shows quite some changes between sequences with correct progressive frames and sequences with combed ones.

First I tried several decomb functions, as well as TomsMoComp.
Both got the source cleaned, but ... somehow, the image quality was a little bit degraded. In some scenes, I got some quot;blockyquot; output, in others, there remained little combing artefacts. I can´t quite understand this, because, apart from the quot;lonely fieldsquot;, everything should fit perfect.
I tried all possibilities of the decomb package I can think of ... but I´ve not too much experience with deinterlacing up to now.

So I decided to take the long run and searched for all those culprit fields manually  
Now really all frames are perfect.

Did I miss something, to deal correctly with a source with missing fields?

[Just so happy to have this movie back, can´t tell ya. I´ll make a dozen backups!!!]

If there is a missing field, then Telecide cannot create a progressive frame for the partner field and emits a combed frame. If postprocessing is enabled, the combing will be removed by deinterlacing. Telecide will not degrade the progressive frames, and there is no way Telecide can cause blockiness!

Yes, that´s exactly what I expected telecide to deliver: build together what belongs, and deal somehow with the few single fields.
I can´t explain what exactly happend, but I definetly saw a (little) degration in image quality.
But don´t put any time in thinking about it for now - I´ll see if I can grab the time to take some screenshots over the weekend. If so, I´ll provide them along with the scripts.

But first comes the party

TomsMoComp is designed for pure video source and probably should not be used on telecined material. On telecined movies it won't give the detail of GreedyHMA or Decomb.

- Tom

Thanks for interest, this helped well.