Incorrect Field Order

[Monkeylord]

Just uploading a fresh clean bit now.

[Monkeylord]

Ah... here we go. It has a montage with a decent array of motion.

http://www.mediafire.com/?039o9yve05n0b5u


I've DEFINITELY watched through this one all the way.

*EDIT*
Added a better clip... keep an eye on the log on a conveyor belt going into a chipper about halfway through. The problem gets really obvious there. Most of the other times it happens are when people are talking, which you asked me to avoid.

[Guest]

I'm not seeing any residual combing with this script (except for some mouth combing that can be attributed to match failure and which postprocessing will mitigate):

dgsource("Metalocalypse S3 Sample 1.dgi")
assumebff()
telecide(post=0) # Use version 5.2.4 with Avisynth 2.6
decimate()

I don't see anything I would attribute to incorrect field order. The animation is not completely smooth but that is due to the low animation rate, not any pathologies, as far as I can see. Please describe the problem that you see by referring to specific frame numbers in your sample.

There is a field order transition at the end of the sample, but that could be due to your cutting.

[Monkeylord]

Thanks... I'll check when I get home from work and get back to you.

With his previous clips there were tons of bad matches with tfm no matter which mode was being used. Maybe Telecide is matching fields better.

[Monkeylord]

I managed to have a quick look on my laptop, and it seems that if I set it to TFF then there's tons of bad matches, but if I set it to BFF then there's a tiny amount of bad matches.

The bad matches in BFF mode are correct in TFF, so there seems to be field order transition error happening.


Would it be an idea to set up 2 versions of the video, and where BFF produces a combed frame have avisynth replace it with the good version from a TFF file?



(I have no idea if what I just typed made any sense)


For example, using:

AssumeTFF()
Telecide(post=0)
Decimate()

In my sample, this causes frames 794, 798, 801, 804, 807, 811, 818, 821, 824, 827, 830 and 834 to have interlacing left behind, but:

AssumeBFF()
Telecide(post=0)
Decimate()

In the same range causes only frame 835 to have interlacing artifacts.

You could always use something like YATTA as well to generate an override file for tfm so you can control the matching.

[Guest]

The clip is BFF so the second script is appropriate. I can look again at frame 835 this evening.

The usual simple way out is to enable postprocessing, so that one bad match gets mitigated.

Okay, so that explains all the bad matches I was seeing when I ran it with tfm. I didn't think to switch the field order assumption.

[Monkeylord]

Originally Posted by paradoxical

You could always use something like YATTA as well to generate an override file for tfm so you can control the matching.

I shall have to look into it... never heard of YATTA before.

Originally Posted by neuron2

The clip is BFF so the second script is appropriate. I can look again at frame 835 this evening.

The usual simple way out is to enable postprocessing, so that one bad match gets mitigated.

Who wants a simple way out?!? lol

On a serious note though, you've helped me learn a lot over these past couple of days (previous clip content faux-pas, included!).

What I think I'll have to look into is how to generate a list of just the frames that need switching, and then how to switch the parity on just those ones. It's as much in the learning experience as it is the "getting it right" for me, at this stage.

[Guest]

Don't assume the parity is wrong for one frame! That's a leap you are making without cause. I'll look again this evening as I said.

A bad match just means that the matcher is not perfect, it doesn't mean that the frame has wrong parity. Have you tried pattern guidance?

[Monkeylord]

Originally Posted by neuron2

Have you tried pattern guidance?

I just tried Pattern Guidence, but if anything it made things worse.

[Guest]

Frame 835 looks clean to me with this script:

dgsource("Metalocalypse S3 Sample 1.dgi")
assumebff()
telecide(post=0)
decimate()

and with this one:

mpeg2source("Metalocalypse S3 Sample 1.d2v")
assumebff()
telecide(post=0)
decimate()

What source filter are you using?

[Guest]

Originally Posted by paradoxical

Maybe Telecide is matching fields better.

In some cases Telecide() does better and in some cases TFM() does better.

TFM/TDecimate have more features than Telecide/Decimate, but for what we do here they should be close in results.

[Monkeylord]

Originally Posted by neuron2

Frame 835 looks clean to me with this script:

dgsource("Metalocalypse S3 Sample 1.dgi")
assumebff()
telecide(post=0)
decimate()

and with this one:

mpeg2source("Metalocalypse S3 Sample 1.d2v")
assumebff()
telecide(post=0)
decimate()

What source filter are you using?

I made an error and it was frame 834, not 835. I feel a complete idiot.

Here's my exact script

mpeg2source("C:\Temp\Split\Metalocalypse S3 Sample 1.d2v")
AssumeBFF()
Telecide(post=0, show=true)
decimate()

Here's what I get when I run the avs in Virtualdub:



The interlacing is on the log. It's the only thing moving in the frame.

I used separatefields() earlier, and navigated to the fields for that frame and it gives the telltale forward/backward jerking of the wrong field order, wheras all the frames leading up to it show the log progressing smoothly along.

[Guest]

That frame for me is 959 after decimation, so I don't know how you get 834. And that frame is clean for me. Are you using the exact same sample you uploaded?

Anyway, I can't duplicate your result.

The only differences I see is that you have Decomb 5.2.3 and you use VirtualDubMod. Can you try Telecide 5.2.4 and use plain vanilla VirtualDub?

[Monkeylord]

Originally Posted by neuron2

That frame for me is 959 after decimation, so I don't know how you get 834. And that frame is clean for me. Are you using the exact same sample you uploaded?

Anyway, I can't duplicate your result.

The only differences I see is that you have Decomb 5.2.3 and you use VirtualDubMod. Can you try Telecide 5.2.4 and use plain vanilla VirtualDub?

Done. Updated to 5.2.4 and used vanilla VDub. Initially I still had the same result, but I think I found the problem. In DGIndex, I found it was set to "Ignore Pull Down Flags". Once I set it to honour them I achieved the same result as you. Frame 959 and clean.



Thanks so much for all the help. I've learned a lot through all this turmoil.

[Guest]

You should spend more time reading user manuals, thereby avoiding such self-inflicted turmoils.

[Monkeylord]

Probably more a case of double checking my settings before embarking on a project.


Thanks again. You've been a massive help.

[johnmeyer]

Originally Posted by Monkeylord

I found the problem. In DGIndex, I found it was set to "Ignore Pull Down Flags". Once I set it to honour them I achieved the same result as you. Frame 959 and clean.

Please note that this is what I recommended in my third post, using your original upload when I stated that there was no field reversal. Given the erratic nature of animation telecine, this setting is pretty much mandatory.