Where is the "swap field order" option?

[numaios]

Hello!

I was trying to encode some episodes of Twin Peaks (PAL DVDs). When I'm creating the DVD2AVI project file, I press F5 for preview and some episodes look good but others look interlaced.

Some time ago, when they looked interlaced, I selected "Swap field order" and then the problem got solved.

But with the version of DGIndex included in Gordian Knot 0.35.0, I can't find this option. I've read something about using a filter that changes the field dominance, but I've read also that it isn't equal to swap field order.

What can I do to get the same result as selecting "swap field order" in older versions?

Thank you very much.

P.S.: With older versions, is it necessary to set something up in the Avisynth script file if "swap field order" is checked?

[GodofaGap]

Whatever you did, that setting cannot have affected the content in the way you are describing. Field order only tells a deinterlacer which field is first. You can imagine that bobbing with the wrong field order would give very weird results (jumpy video). However, the frame consisting out of the two fields will look the same wether it is considered bff or tff.

[numaios]

In the old GK guide:

Frame Rate = 25.000 fps: your source is PAL. If the frame type is Interlaced, start the preview again and watch closely if you see no horizontal black lines going thru the picture then the frames are actually progressive and you're already done here. If there are such black lines, try changing the field order by selecting Video - Field Operation - Swap Field Order and run the preview again. If you can still see horizontal lines reset the Field Operation to None, otherwise leave it as it is.

And it worked!

[GodofaGap]

What is written there doesn't make any sense at all. Or 'swap field older' did something else than swapping the field order, or you did something different. :)

[edit]I guess if you are doing an IVTC changing field order could have an effect. But I can't imagine there is a DVD that would have the field order signalled wrongly.

[numaios]

I don't know what "swap field order" does, but whatever it is, I'd like to know what can I do to get the same effect now that I can't select that option in DGIndex.

[Guest]

Actually, swapping fields *can* cause an artifact that looks similar to interlacing. And some capture cards are brain-dead and need this operation to be applied.

To achieve the same effect as the old DVD2AVI option, add this to your Avisynth script:

SwapFields()

But I would guess you really need a one-field phase shift. Can you post a link to a short VOB fragment so that we may tell you what is really required?

[numaios]

To achieve the same effect as the old DVD2AVI option, add this to your Avisynth script:

SwapFields()
OK! Where should I add it? Before the crop/resize lines? Does the position really matter?

But I would guess you really need a one-field phase shift. Can you post a link to a short VOB fragment so that we may tell you what is really required?
Thank you, neuron2. But I don't know how to cut a fragment of a VOB file, can you tell me how?

What does "phase shift" mean? That some frames are interlaced and others aren't?

Edit: I've used the option "Save project and demux video" and I've got a *.m2v file with the fragment where the interlacing effect is very obvious. Is that OK for you to test the vob file?

[Wilbert]

What does "phase shift" mean? That some frames are interlaced and others aren't?
Progressive content looks like this:

1t 2t 3t 4t ...
1b 2b 3b 4b ...

where t is the top field, b the bottom field, 1t and 1b are two fields from the same time instant (forming one frame), 2t and 2b two fields from the next time instant, etc ...

For phase shifted content, one of the fields is shifted on period:

xx 1t 2t 3t 4t ...
1b 2b 3b 4b 5b ...

so it *looks* like combing (interlaced content) because two fields from different time instants are forming one frame, while the content is actually progressive.

[Guest]

OK! Where should I add it? Before the crop/resize lines? Does the position really matter? Yes, it matters. To simulate the DVD2AVI result, put it directly after mpeg2source().

But I don't know how to cut a fragment of a VOB file, can you tell me how? http://www.digital-miner.com/chopperxp.html

What does "phase shift" mean? That some frames are interlaced and others aren't? Please see Wilbert's post.

Edit: I've used the option "Save project and demux video" and I've got a *.m2v file with the fragment where the interlacing effect is very obvious. Is that OK for you to test the vob file? Yes, that is good.

[numaios]

OK! Thank you very much for your explanations, Wilbert and neuron2.

[Guest]

Did you plan to upload a stream?

[numaios]

Of course!

I am uploading a fragment. It's only 12,5 Mb. Isn't that enough? Since you told me not to exceed 500 Mb...

If you need a bigger fragment, I will upload it.

Thanks again.

[EDIT] File already uploaded (in the directory \FromNumaios)

[Guest]

Yes, it's phase-shifted progressive PAL. You can prove it with this script:

loadplugin("c:\dgmpgdec\dgdecode.dll")
mpeg2source("C:\tmp\Numaios\TwinPeaks.d2v")
assumetff()
separatefields()
trim(1,0) # delete first field
assumebff() # the trim makes it BFF
weave()

You can also use a field matcher such as Telecide() or TFM().

[numaios]

OK! Thanks a lot! I'll give it a try.

0) Do I have to load "decomb.dll" in the script?

1) What is the difference between the script and the field matchers? You mean using the field matchers in addition to that script?

2) What does TFM mean?

3) BTW, what did you do with the fragment to know it was a phase shift? The next time I get a interlaced-looking video I'll be able to find out by myself :)

4) I've read in other posts that there is a problem if the phase changes along the video. Can this script [assumetff() - separatefields() - trim(1,0) - assumebff() - weave()] detect if the phase changes? Or this is why is better to use Telecide()?

[Guest]

0) Do I have to load "decomb.dll" in the script? No. I had it there because I tried IVTCing it.

1) What is the difference between the script and the field matchers? You mean using the field matchers in addition to that script? That script just blindly rematches. But your stream might have parts where there is a phase shift and parts where there is not. A good field matcher will automatically adapt to that.

2) What does TFM mean? It means "tritical's field matcher". It's an Avisynth filter you can find in the TIVTC package available here:

http://bengal.missouri.edu/~kes25c/

Use one method or the other. The dumb script I gave may work for the whole movie but it depends on the movie.

3) BTW, what did you do with the fragment to know it was a phase shift? The next time I get a interlaced-looking video I'll be able to find out by myself You separate the fields using SeparateFields() and then step through. Denote a unique field picture by a letter and frame boundaries by []. Then if you see this, it is shifted:

... [x a] [a b] [b c] [c d] ...

You know the boundaries by the "frame" numbering after SeparateFields. E.g., frames (really fields) numbered 0 and 1 are together, 2 and 3 are together, etc.

If we chop away field x, then we recombine as follows:

... [a a] [b b] [c c] ...

But that changes the field order, so the script adjusts that before the weave.

Or you can just try the shift correction and see if that removes the combing. :)

4) I've read in other posts that there is a problem if the phase changes along the video. Can this script detect if the phase changes? Or this is why is better to use Telecide()? See above.

[numaios]

Thanks again for your patience...

That script just blindly rematches. But your stream might have parts where there is a phase shift and parts where there is not. A good field matcher will automatically adapt to that.
So, it is more safe to use Telecide() than the script? (Without any parameters?)

[Guest]

So, it is more safe to use Telecide() than the script? Field matchers are not perfect. If your movie has the phase shift throughout, then the script is safer. If the shift comes and goes, then a field matcher is safer.

Another observation: Your clip is very noisy. That makes life very hard for field matchers, because field differences due to noise can swamp field picture differences. An alternative for such clips is to use the fixed phase adjustment, but apply it or not as needed for different sections of your video. You have to decide whether this material is important enough to justify such a manual approach. The quick and dirty solution is to use field matching with postprocessing to clean up any bad matches.

[numaios]

I've tested another fragment of the same episode and it looks combed using the script, so the phase is not constant, so I should use a field matcher. Then,

The quick and dirty solution is to use field matching with postprocessing to clean up any bad matches.
OK, if I don't choose the manual method, would this be a good solution? (Because I don't understand the Telecide parameters very well)

loadplugin("c:\dgmpgdec\dgdecode.dll")
mpeg2source("C:\tmp\Numaios\TwinPeaks.d2v")
assumetff()
Telecide(order=1,guide=2,post=2,vthresh=25)

[EDIT1] When is the field order set? When you write "AssumeTFF()" or when you write "(order=1)"? Why does VDubMod tell me to set the parameter "order"?

[EDIT2] There's something I don't understand. If Telecide() is a field matcher, after field matching, deinterlacing wouldn't be necessary since actually they are progressive frames. I say this because I've tried with post=0 and I get a few combed frames (the bird's beack for example), so they need to be deinterlaced, whereas using the "phase shift" script, the frames look perfect without deinterlacing.
I mean, using Telecide without post-processing is better than using nothing, but worse than the phase-shift script.

[Guest]

Telecide() version 5.2.1 uses the order parameter. Telecide() 5.2.2 uses the AssumeXXX() call.

I already explained the rest. No field matcher is perfect, and your clip is very noisy, which exacerbates that. If you want to do things manually with the phase shifting approach, fine, go for it. If you want to write a better field matcher, fine too, go for it.

[numaios]

Telecide() version 5.2.1 uses the order parameter. Telecide() 5.2.2 uses the AssumeXXX() call.
OK, so the phase-shift script for 5.2.1 would be this?

separatefields(order=1)
trim(1,0) # delete first field
weave(order=0)

instead of:
assumetff()
separatefields()
trim(1,0) # delete first field
assumebff() # the trim makes it BFF
weave()

I'm sorry, maybe I hadn't understood the first time because I hadn't seen the difference for myself already. And after testing, I wrote my conclusions without reading again what you told me before.

[medp7060]

Well, since we are discussing field order, I wonder if resize filter will swap field order? The reason why I ask this is as follows:

I have a MPEG2 clip test.mpg, which is top field first (it says so when I load this MPEG2 with TMPGenc Plus).

When I use this script
mpeg2source("test.d2v")
FieldDeinterlace()TMPGenc plus reports it as top field first.


But after I add a resize filter to this script
mpeg2source("test.d2v")
FieldDeinterlace()
LanczosResize(704,528)TMPGenc plus reports it as bottom field first.

[Guest]

OK, so the phase-shift script for 5.2.1 would be this? No. The phase shift method does not use Telecide() so the Telecide() version is irrelevant.

SeparateFields() and Weave() do not take an order parameter.

[Guest]

But after I add a resize filter...TMPGenc plus reports it as bottom field first. TMPGEnc uses heuristics to guess the field order. It is not always correct.

[numaios]

No. The phase shift method does not use Telecide() so the Telecide() version is irrelevant.

SeparateFields() and Weave() do not take an order parameter.
OK! Thank you for all your help, neuron2.

[medp7060]

Thanks, neuron2.