Extremely weird field orders

[Katie Boundary]

I've recently noticed a phenomenon in hybrid content that I don't know how to deal with. Fields will sometimes be arranged in a pattern that looks perfectly fine when viewed on an interlaced display, and doesn't look the least bit odd when run through separatefields and doubleweave, but yields jerkiness when bob-deinterlaced regardless of what field order is used. Examples include:

The Robocop: Prime Directives movies
Gargoyles opening credits
Stargate SG-1

Most recently, I caught a quick example in the episode "Ouroboros" of Gene Roddenberry's Andromeda

Does anyone know what the hell this is, why it's done, and how to fix it?

[Sharc]

Maybe the frames are flagged TFF/BFF but your bobber ignores the flags?
A sample of few seconds would help.

[ndjamena]

As for Gargoyles, the oddest thing about the opening credits is that objects move on different frames, that's actually normal for animation, you wind up with 24 frames of movement, with each object being animated at 12fps. Other than that the only problem is with the animation. The sun goes back a step every time the background moves. Goliaths toes are quivering while they move.

But there's a more important question to be asked here. Gargoyles is animated at 24p, what the hell are you passing it through a bobbing filter for?

NTSC Season 1 actually comes pre-detelecined, you can see that each episodes is almost 100% film if you look at the d2v. If you used MPEG2Source you could probably get away with forced film, otherwise feeding the d2v file into TFM should give perfect results.

Season 2 is hard telecined. Still, TFM should make short work of it. If you do that then THERE WILL NOT BE ANY PROBLEMS WITH THE RESULTING FRAMES. At least not ones that are the deinterlacers fault.

[Katie Boundary]

Maybe the frames are flagged TFF/BFF but your bobber ignores the flags?

DGIndex did not report any illegal field order transitions, except for some of the Prime Directives movies.

A sample of few seconds would help.

I'd post one, but then people would bitch about Facebook's JPEG compression as if that somehow affected the field order. I'm no eager to start another one of those arguments.

Gargoyles is animated at 24p

Not the opening credits.

NTSC Season 1 actually comes pre-detelecined

You mean it's natively film with soft pulldown flags, or at least that's what it switches to when the credits are done.

you can see that each episodes is almost 100% film if you look at the d2v. If you used MPEG2Source you could probably get away with forced film, otherwise feeding the d2v file into TFM should give perfect results.

Nope, the opening credits are full of orphaned fields. The title card at the end of the opening credits (the one where the letters look like they're reflecting light from a fire) is an even more unique situation because all of the top fields form one perfectly smooth 30 hz sequence and all of the bottom fields form another, so bob-deinterlacing creates a strobing effect.

[Groucho2004]

A sample of few seconds would help.
I'd post one, but then people would bitch about Facebook's JPEG compression as if that somehow affected the field order. I'm no eager to start another one of those arguments.
How is Facebook's JPEG compression related to a video sample?

[Overdrive80]

You can try complementparity function before of IVTC or deinterlacer.

[ndjamena]

The sun is badly animated. The logo is done like that to make it look like fire (there's something similar in the Jimmy Neutron opening sequence where the colours are inverted each field, otherwise except for fades JN is 29.97p).

The way to fix the logo is to convert it to 24fps by selecting frames alternately derived from top a bottom fields, the solution for the sun would be something similar.

There's no actual problems with the field orders and nothing odd.

[Katie Boundary]

How is Facebook's JPEG compression related to a video sample?

I have no idea, but people kept bringing it up anyway!

You can try complementparity function before of IVTC or deinterlacer.

And screw up the 99.999% of the video that does not suffer from this problem? I don't think that's a good idea.

The way to fix the logo is to convert it to 24fps by selecting frames alternately derived from top a bottom fields, the solution for the sun would be something similar.

LOLno, that absolutely will not work.

[Groucho2004]

I have no idea, but people kept bringing it up anyway!
Not in this context. It was explained to you how to create a video sample here (https://forum.doom9.org/showthread.php?p=1776197#post1776197). I find it hard to believe that you can't follow these instructions so one has to assume that you simply don't want to post a sample for whatever reason.

[hello_hello]

How is Facebook's JPEG compression related to a video sample?

Apparently she doesn't know how to upload a sample anywhere else even though she's been given a list of upload sites before.

Not in this context. It was explained to you how to create a video sample here (https://forum.doom9.org/showthread.php?p=1776197#post1776197). I find it hard to believe that you can't follow these instructions so one has to assume that you simply don't want to post a sample for whatever reason.

You're making yourself a candidate for Katie's ignore list there. Second thread today, same old story.
https://forum.doom9.org/showthread.php?p=1792931#post1792931

[Katie Boundary]

Not in this context. It was explained to you how to create a video sample here (https://forum.doom9.org/showthread.php?p=1776197#post1776197). I find it hard to believe that you can't follow these instructions so one has to assume that you simply don't want to post a sample for whatever reason.

Oh, the [] thing. Yes, creating those files was the easy part. Finding a place to upload them, less so. But this isn't the thread to discuss file-hosting. This is the thread to discuss fields being encoded in the wrong order, or footage being generated in such a way that there can be no correct field order. If you've never heard of this kind of problem before, then you're in the wrong thread.

[wonkey_monkey]

This is the thread to discuss fields being encoded in the wrong order, or footage being generated in such a way that there can be no correct field order.

We can't know for sure whether that really is what's being talked about until we see a sample, can we? It wouldn't be the first time you've strung us along with your miscontrued descriptions only for the reality to turn out to be different.

No-one else seems to have a problem uploading samples.

[StainlessS]

A picture says a thousand words, however, the real experts here need a bit more, stop prevaricating and produce some kind of clip
for the guys to work their magic on, otherwise, stop posting.

[johnmeyer]

I agree with davidhorman's last post: a sample is essential.

When I try to extract the original progressive film from what gets captured from an NTSC camera "filming" the output of a 16mm projector from which the shutter has been removed, I have to recombine fields from adjacent frames, while deleting both redundant fields as well as fields that capture the "pulldown" frame (which "pulldown" is used in its original film context, where the actual film is being pulled down into the gate, creating a totally blurred frame, even when the camera shutter speed is set to 1/1000 second).

I mention this, because some of what I needed to do for that is similar to what, perhaps, needs to be done here.

The only way I was able to achieve what I wanted was by exporting all the TFM metrics (including the MIC matching parameters) and feeding them into a spreadsheet. In that spreadsheet, I created logic which looks backwards and forwards in time, using all the metrics, and which produces a perfect matching and decimation result. The output of that spreadsheet is then fed into Pass 2 of Multidecimate which does the actual decimation as well as the recombination of fields, even if they were originally in different frames. This is another way of saying the same thing as (I think) Katie was saying, although maybe it was in the other thread he started which appears to be, more or less, the same subject.

[Sharc]

Okay, I ran one of the sources through Separatefields and nothing else, just to check field parity, and... there ARE field order transitions that DGIndex isn't detecting. How fix?
Which source filter did you use for stepping through the fields? Do different source filters produce identical results?

[Katie Boundary]

I think that, at least in some cases, the idea is that the image is supposed to look blended when played back...

Which source filter did you use for stepping through the fields? Do different source filters produce identical results?

Mpeg2source/mpeg2dec3.dll (DGdecode). I'm not aware of any others that can read d2v files.

[Sharc]

So as you found your file seems to have inconsistent field orders (field order transitions). Does it also have repeated frames/fields? Are any RFF flags present?
If the TFF and RFF flags are set correctly your clip will normally playback correctly. That's apparently what you get when you play the clip as is.
However, if you apply deinterlacers (or bobbers) the result may be different: Some deinterlacers/bobbers don't require consistent field orders, some do and will otherwise produce jerky streams.

[Ghitulescu]

It's incredible how many people actually continue to reply to this thread, given the bad attitude the OP displays.

[johnmeyer]

It's incredible how many people actually continue to reply to this thread, given the bad attitude the OP displays.Totally agree, but since I'm one of those who has responded, let the record show that I've tried to help the OP, both here and in other threads. He never once, in any of his posts, ever seems to solve any problem, never posts the results and, of course, never once posts any actual footage that would make it extremely easy to provide a solution.

To repeat my request: post a clip, post a clip, post a clip.

I want to help, which is why I sometimes post, but I have learned that he doesn't really want to solve his/her "problem" but instead just wants to keep the thread going, probably in order to have someone to "talk" to.

[Katie Boundary]

https://www.sendspace.com/file/74oau3

Look at the spinning radar-like displays in the background. When bob-deinterlaced, they normally move clockwise, but sometimes jerk counter-clockwise for 1 or 2 fields.

I'll have to re-rip Gargoyles, Prime Directives, and Stargate if you want clips from those too.

[Overdrive80]

DGDecode_mpeg2source("C:\Users\Isra\Desktop\212 - Ouroboros.demuxed.d2v", info=3)

ColorMatrix(hints=true, threads=0, interlaced=true)

assumebff()

animeivtc(mode=2)#mode=3 works fine too.

[ndjamena]

I told you there is something wrong with the Gargoyles credits. The sun jumps back a bit as the background moves, but it's not something a filter can fix. The sun is at one position before the background shifts, then it moves a little further forward, then the background shifts and the sun moves back to it's previous position.

The fact is those moments in time are incompatible. That little bit of forward movement before the background shifts can't exist in any sane timestream, since the sun exists in it's previous position AFTER the background has moved, it CAN'T exist in the next position BEFORE it moves.

Or are you referring to something else in the credits?

[hello_hello]

https://www.sendspace.com/file/74oau3

Look at the spinning radar-like displays in the background. When bob-deinterlaced, they normally move clockwise, but sometimes jerk counter-clockwise for 1 or 2 fields.

If the video itself is 29.970fps progressive, TFM() works. I think the CGI stuff is telecined so with TFM() the CGI will end up 29.970fps progressive with one in five frames repeated.

Or TFM().TDecimate will make the CGI stuff progressive at 23.976fps, but with or without TDecimate(), if the "video" is 29.970fps progressive that'll make motion jittery. It's hard to tell from the sample as there's no background movement, so TFM() only has to field match the CGI. If there was lots of background movement I doubt it'd be fixable that way.

The closest compromise you'll probably get is QTGMC as it won't do much damage to progressive video, but you'll still need SelectEven() to delete the frames where the CGI moves in the wrong direction. I can't see converting that to 59.940fps short of QTGMC().SelectEven(),ChangeFPS(60000,1001), or adding motion interpolated frames, but that'd probably be pointless.

[johnmeyer]

It sure is helpful to have a clip to look at.

First of all, I doubt very much this is simply a "rip" of the original material. If you put the clip into a simple script containing only "separatefields()", you find all sorts of retrograde field behavior (i.e., where the movement stutters backwards and forwards) no matter whether you add an AssumeTFF() or AssumeBFF() before the separatefields statement. Also, at the very beginning of the clip, the figure in the center of the screen has totally different luma/chroma values for one field than in the other field, and this persists for several frames.

Thus, I must conclude that this clip has already undergone some sort of processing prior to being uploaded and that this processing has significantly altered the clip.

The field matching solutions offered in the parallel (redundant?) thread started by the OP at about the same time as this thread seem to sort out the field order issues, so all you need to do is figure out the correct decimate logic.

[wonkey_monkey]

Thus, I must conclude that this clip has already undergone some sort of processing prior to being uploaded and that this processing has significantly altered the clip.

It's got a 30fps (ostensibly; yet it also shows occasional signs of interlacing) video effect overlaid on 3:2 pulled down 24p. Anything could have happened to it in that process. On the basis of that, by itself, I'd give anyone but Katie the benefit of the doubt, and assume it might just be badly edited video (let's face it, Andromeda wasn't exactly big budget).

But then I see the two shot changes - the first one is BFF and the second is TFF. So who the hell knows.

A longer clip with more action would have been useful. If this is the only problem bit I'd say it's just shoddy work at the studio.

[Katie Boundary]

DGDecode_mpeg2source("C:\Users\Isra\Desktop\212 - Ouroboros.demuxed.d2v", info=3)

ColorMatrix(hints=true, threads=0, interlaced=true)

assumebff()

animeivtc(mode=2)#mode=3 works fine too.

What the hell is Colormatrix? Can you explain your thought process or how this is supposed to work?

I told you there is something wrong with the Gargoyles credits.

I told you first.

Or are you referring to something else in the credits?

I'm talking about everything, but especially the TITLE CARD:

https://scontent.fsnc1-1.fna.fbcdn.net/v/t1.0-9/15977474_1793736627557458_3132624787439033672_n.jpg?oh=2712a5049cc8a63950dd1bf54590faa1&oe=591298A3

First of all, I doubt very much this is simply a "rip" of the original material.

Too bad for you.

If you put the clip into a simple script containing only "separatefields()", you find all sorts of retrograde field behavior (i.e., where the movement stutters backwards and forwards) no matter whether you add an AssumeTFF() or AssumeBFF() before the separatefields statement.

THAT'S WHAT I SAID!!!!! Hello and welcome to the very first post of this thread. Jesus Christ.

Thus, I must conclude that this clip has already undergone some sort of processing prior to being uploaded and that this processing has significantly altered the clip.

Wrong. Go ahead and rent or buy Andromeda Season 2 Collection 3, rip the episode "Ouroboros", and see for yourself. Or did I alter those too?

The field matching solutions offered in the parallel (redundant?) thread started by the OP at about the same time as this thread seem to sort out the field order issues

No, that only HIDES the field order issues, and it does so at the price of interlacing every place where there's an orphaned field.

And no, the threads aren't redundant or even related. One thread is about fields being encoded into the video stream in an incorrect order. The other is about double-rate field-matching.

[johnmeyer]

THAT'S WHAT I SAID!!!!! Hello and welcome to the very first post of this thread. Jesus Christ.I really did try to help, but that sort of language, and that nasty, snarky response means that you are a person who doesn't deserve any help from me, or anyone else.

[Sharc]

It's got a 30fps (ostensibly; yet it also shows occasional signs of interlacing) video effect overlaid on 3:2 pulled down 24p. Anything could have happened to it in that process.... .

But then I see the two shot changes - the first one is BFF and the second is TFF. So who the hell knows.

Yes; from the flags:
Frame 0 to 13: Interlaced, BFF
Frame 14 to 146: progressive film with 3:2 pulldown (+ video overlay with messy field sequence)
Frame 147 to 149: Progressive, TFF
Frame 150 to 153: Interlaced, TFF
Frame 154 to 155 (end): progressive film with 3:2 pulldown (probably, sequence too short)

[wonkey_monkey]

Oh, it's actually flagged like that? Bonkers. Or KB's now taken to inventing problems just so there's something to talk about.

[ndjamena]

Being deliberately vague at what the hell you're talking about then throwing tantrums when people don't automatically get it really doesn't help progress the thread along.

Other than that they've switched to 60i in order to produce a flickering effect on the logo and the sun is animated wrong, what exactly do you think is wrong it the credits?

What are we supposed to be fixing?

[ndjamena]

According to dgindex the flags in Gargoyles 1x2 and 2x1 are all fine.

I even loaded the d2v files into TFM, if there was any problems with the flags TFM would have created a "-Fixed" d2v file.

Are we complaining about the animation? The bad frames with the sun should probably be removed, and unless you want 60p output or VFR video you should probably convert both the sun and the logo to 24p anyway.

It you don't want to do that then that's your call, but encoding a 20 minute file as 60p just for the sake of a few seconds of minor effects seems overkill, and VFR can be problematic for some players.

Of course I have no idea what kind of output you want so there's no point in continuing until you explain what's going on.

[Katie Boundary]

I really did try to help, but that sort of language, and that nasty, snarky response means that you are a person who doesn't deserve any help from me, or anyone else.

What it means is that you should read posts before replying to them.

Being deliberately vague at what the hell you're talking about

I wasn't vague at all. I was EXTREMELY specific. It's not my fault if you and John are illiterate.

Other than that they've switched to 60i in order to produce a flickering effect on the logo and the sun is animated wrong, what exactly do you think is wrong it the credits?

Those two things should be enough, but if you want a third example, the fades are also done incorrectly.

[ndjamena]

And you didn't answer what you expect us to do about it.

We all come across this kind of crap on pretty much a daily basis, and we don't feel the need to blurt it all over the forum.

As far as I can tell, the top fields and bottom fields of the 60i sections were animated in separate streams, and as you can tell from the sun in the beginning the result actually makes no sense whatsoever. There's nothing you or anyone else can do about that unless you plan on reanimating the frames.

Other than that, video special effects plastered over telecined film elements is actually so common as to be meaningless as far as this forum is concerned.

If it's so obvious where this thread is supposed to be going, maybe someone other than Katie can explain it to me, since all she's capable of doing is claiming how obvious it is?

[Sharc]

And you didn't answer what you expect us to do about it.
Speculating that she wants a smooth playback at 23.976 fps progressive, one could try as follows:
1. Remove the pulldown flags from the stream
2. then deinterlace


1. Pulldown flags can be removed with the DGPulldown tool. Select the custom framerate option, and select source and destination equal to 23.976
2. deinterlace e.g. with
QTGMC(preset="fast").selecteven()
It should give a progressive 23.976 stream.

[ndjamena]

I suggested she convert to 24p, she said, no.

LOLno, that absolutely will not work.

[ndjamena]

I've recently noticed a phenomenon in hybrid content that I don't know how to deal with. Fields will sometimes be arranged in a pattern that looks perfectly fine when viewed on an interlaced display, and doesn't look the least bit odd when run through separatefields and doubleweave, but yields jerkiness when bob-deinterlaced regardless of what field order is used. Examples include:


Does anyone know what the hell this is, why it's done, and how to fix it?


By the way, Gargoyles in no way fits the description in the initial post.

The fields orders are 100% correct and it DOES NOT look fine using separate fields.

It's an animation error, pure and simple. The only way to deal with it is to remove the illogical frames and deal with the rest to your own personal taste (and there's no right way of choosing that).

It's not something that needs to be discussed, other than as a curiosity or an FYI.

[ndjamena]

Here:

http://www.mediafire.com/file/4dv0788q0v0a7u4/Wolf.m2v

Weird random crap from a DVD if anyone wants to ogle.

[hello_hello]

Speculating that she wants a smooth playback at 23.976 fps progressive, one could try as follows.....

I'm fairly sure she's currently in 60fps mode. The previously impenetrable barrier of field separation, decimation and resizing collapsed on 19th April 2016, or as it's more commonly referred to, Bob Tuesday (https://forum.doom9.org/showthread.php?p=1765073#post1765073).

A new thread was created to mark the commencement of the post Bob Tuesday reality, which I remember fondly, as after being insulted for days (https://forum.doom9.org/showthread.php?p=1764655#post1764655) for trying to explain NTSC is an 59.94i interlaced format, I discovered in the newly created timeline that didn't happen and I'd really been denying 59.94i NTSC existed (https://forum.doom9.org/showthread.php?p=1765114#post1765114).

Within days of Bob Tuesday and the end of the previous "separate fields" reality, where 60fps and VFR video weren't very useful (https://forum.doom9.org/showthread.php?p=1764491#post1764491), Katie thought of an idea for 60fps & VBR encoding (https://forum.doom9.org/showthread.php?p=1792906#post1792906), an attempt was made to re-invent Bob (https://forum.doom9.org/showthread.php?t=174015), and orphaned fields became a protected species in an attempt to deter the use of automated, more intelligent tools, especially de-interlacers. ;)

[Katie Boundary]

Other than that, video special effects plastered over telecined film elements is actually so common as to be meaningless as far as this forum is concerned.

Okay but that has nothing to do with this thread, which is about incorrect field orders.

Speculating that she wants a smooth playback at 23.976 fps progressive

That is literally not possible with this content. Not without dropping distinguishable images.

By the way, Gargoyles in no way fits the description in the initial post.

The fields orders are 100% correct and it DOES NOT look fine using separate fields.

Did you forget to add Doubleweave? I bet you forgot to add Doubleweave.

[manono]

Unless you upload an untouched sample showing the problem you claim exists, I'll close this thread to save others from wasting their time trying to help you.

You have a couple of days.

[Katie Boundary]

Unless you upload an untouched sample showing the problem you claim exists

I DID! It's post #20!!

[manono]

I DID! It's post #20!!
So you did, and I apologize. However, one screwy section of a badly created opening sequence isn't fodder for this forum, I don't think. Fix it if it bothers you. Edit frames, use frame interpolation, delete the screwy frames or replace them with identical copies, whatever. That sample isn't typical of the entire episode, I don't think.

Okay but that has nothing to do with this thread, which is about incorrect field orders.


You entitled this thread 'Extremely Weird Field Orders' and said DGIndex didn't spot the illegal field order transitions when there are no odd field order changes to begin with. Sharc showed that conclusively earlier. The thread could have ended at that point, a few posts after you produced a sample. Yes, there's some things screwy about the sample, but it has nothing to do with field order changes. And it's not unusual for opening credits to be different from the main body of a episode and sometimes so much different as to mess up trying to do the entire episode the same way. It can be maddening and sometimes compromises have to be made.

Anyway, thanks for pointing out a sample had already been submitted. I had only been following the thread periodically.

[Katie Boundary]

So you did, and I apologize. However, one screwy section of a badly created opening sequence

But it's NOT just that one screwy section. I gave three other examples.

You entitled this thread 'Extremely Weird Field Orders' and said DGIndex didn't spot the illegal field order transitions when there are no odd field order changes to begin with. Sharc showed that conclusively earlier. The thread could have ended at that point, a few posts after you produced a sample. Yes, there's some things screwy about the sample, but it has nothing to do with field order changes.

There ARE field order changes in Andromeda. They're just not illegal ones. It remains to be seen whether they are or aren't related to the "retrograde field behavior" in that episode. They're definitely not related to similar behavior in completely different examples.

I'll attach some Robocop in case anyone cares.


EDIT: Here, the first chapter of the first Prime Directives movie, in raw VOB form. I didn't even bother renaming it, much less do whatever nefarious things John thinks I did to the Andromeda clip: https://www.sendspace.com/file/0wyf40

[johnmeyer]

EDIT: Here, the first chapter of the first Prime Directives movie, in raw VOB form. I didn't even bother renaming it, much less do whatever nefarious things John thinks I did to the Andromeda clip: https://www.sendspace.com/file/0wyf40I added the emphasis to the quote.

To the forum admin: please lock this thread. I really did try to help this person and, except for one sentence where I surmised that the clip that was finally presented might not be directly from the DVD, I didn't do anything else to antagonize this person. Please note that almost EVERYONE who has tried to help has gotten sucked into this person's negativity.

All of his threads are the same way.

Because of him, I feel less inclined to spend my time helping other people. I've been on this forum for fifteen years, and have, I think, generally been helpful, so I do not appreciate -- at all -- this person's treatment of people who try to help him and also do not appreciate the rancor that he manages to stir up in every single thread he starts.

[Katie Boundary]

That last sample is just mixed hard and soft 3:2 pulldown. You have to make your project with honor pulldown flags and then apply an inverse telecine operation, for example with Telecide/Decimate or TFM/TDecimate, like this:

loadplugin("D:\Don\Programming\C++\Avisynth Filters\Decomb\Release\decomb.dll")
loadplugin("D:\Don\Programming\C++\DGDecNV\DGDecodeNV\x32\Release\dgdecodenv.dll")

dgsource("C:\Users\Don\Downloads\PD01ch01_1.dgi")
telecide()
decimate()

Did no one ever tell you that it's a bad idea to apply IVTC to natively 60hz material?

except for one sentence where I surmised that the clip that was finally presented might not be directly from the DVD, I didn't do anything else to antagonize this person.

You also assume that I'm male, but I let that slide because I'm not willing to post my tits just to prove you wrong.

Also, you're one of several people on this forum who have a habit of ruining threads by making them about me rather than about video.

[johnmeyer]

Hey John, you being disinclined to help doesn't mean the thread must be closed. You can look at some other threads for amusement if this one offends you.Fair enough. Good point. I usually ignore threads started by people like this. However, his problem happens to be something that I've worked with a lot and, with a proper clip that actually shows movement, I'm pretty certain I can fix it almost perfectly.

It probably seems like my last post was a little bit of an over-reaction, but the reaction was cumulative, and started with his post in this thread a few days ago where he takes four different shots at me:

http://forum.doom9.org/showpost.php?p=1793304&postcount=26

This guy reminds me of a friend's cat who always comes over purring, and when you pet him he seems to initially like it. But then, without warning, he turns on you and bites and scratches. You think I'm ever going to pet that cat again?

[edit]I just saw Katie's last post. Yes, I did assume the person is a male. Her charming rejoinder has set me straight on that subject.

[Katie Boundary]

John, either say something about field orders or STFU. If you want to bitch about me and use the wrong pronouns while doing it, start a separate thread in the off-topic section.

Monono, if you could split off all of John's irrelevant personal nonsense into a separate thread and move that thread to the off-topic section, that would be great. Thanks.

[Katie Boundary]

You know what's actually rude? Deliberately derailing threads.

Fix it if it bothers you. Edit frames, use frame interpolation, delete the screwy frames or replace them with identical copies, whatever.

I'd settle for an explanation of why anyone in their right mind would produce a video stream like this to begin with. As for fixing the Andromeda episode, I switched from Premiere to AVIsynth when I realized that fixing chroma ghosting was easier in AVIsynth, and now my script looks like the tenth circle of tedious autistic hell:

mpeg2source("212.d2v")

A=Tfm(field=1,pp=0,micmatching=0)
B=Tfm(field=0,pp=0,micmatching=0)
C=Interleave(A,B)
D=Tdeint(mode=1,full=false)


trim(D,0,685)
+trim(C,686,1010)
+mergechroma(D.trim(1011,1011),C.trim(1010,1010))
+mergechroma(D.trim(1012,1012),C.trim(1013,1013))
+trim(C,1013,1021)
+trim(D,1022,1516)
+mergechroma(D.trim(1517,1517),D.trim(1516,1516))
+mergechroma(D.trim(1518,1518),D.trim(1520,1520))
+trim(D,1520,1520)
+trim(D,1519,1519)
+trim(C,1521,1528)
+trim(D,1530,1530)
+trim(D,1529,1529)
+trim(D,1532,1532)
+trim(D,1531,1531)
+trim(D,1533,1533)
+trim(C,1534,1540)
+trim(D,1542,1542)
+trim(D,1541,1541)
+trim(D,1543,1545)
+trim(C,1546,1553)
+trim(D,1554,1556)
+trim(C,1557,1557)
+trim(D,1557,1557)
+trim(C,1559,1565)
+trim(D,1566,1566)
+trim(C,1567,1567)
+trim(D,1567,1567)
+trim(D,1570,1570)
+trim(D,1569,1569)
+trim(C,1571,1578)
+trim(D,1580,1580)
+trim(D,1579,1579)
+trim(D,1582,1582)
+trim(C,1582,1582)
+trim(D,1581,1581)
+trim(C,1584,1590)
+trim(D,1592,1592)
+trim(C,1592,1592)
+trim(D,1593,1593)
+trim(D,1594,1595)
+trim(C,1596,1603)
+trim(D,1604,1605)
+trim(D,1606,1606)
+trim(C,1607,1607)
+trim(D,1607,1607)
+trim(C,1609,1615)
+trim(D,1616,1616)
+trim(C,1617,1617)
+trim(D,1617,1617)
+trim(D,1620,1620)
+trim(D,1619,1619)
+trim(C,1621,1628)
+trim(D,1630,1630)
+trim(D,1629,1629)
+trim(D,1632,1632)
+trim(c,1632,1632)
+trim(D,1633,1633)
+trim(C,1634,1640)
+trim(D,1642,1642)
+trim(C,1642,1642)
+trim(D,1643,1645)
+trim(C,1646,1653)
+trim(D,1654,1656)
+trim(C,1657,1657)
+trim(D,1657,1657)
+trim(C,1659,1665)
+trim(D,1666,1666)
+trim(C,1667,1667)
+trim(D,1667,1667)
+trim(D,1670,1670)
+trim(D,1669,1669)
+trim(C,1671,1678)
+trim(D,1680,1680)
+trim(D,1679,1679)
+trim(D,1682,1682)
+trim(C,1682,1682)
+trim(D,1683,1683)
+trim(C,1684,1690)
+trim(D,1692,1692)
+trim(C,1692,1692)
+trim(D,1693,1695)
+trim(C,1696,1703)
+trim(D,1704,1706)
+trim(C,1707,1707)
+trim(D,1707,1707)
+trim(C,1709,1715)
+trim(D,1716,1716)
+trim(C,1717,1717)
+trim(D,1717,1717)
+trim(D,1720,1720)
+trim(D,1719,1719)
+trim(C,1721,1728)
+trim(D,1730,1730)
+trim(D,1729,1729)
+trim(D,1732,1732)
+trim(C,1732,1732)
+trim(D,1733,1733)
+trim(C,1734,1740)
+trim(D,1742,1742)
+trim(C,1742,1742)
+trim(D,1743,1745)
+trim(C,1746,1753)
+trim(D,1754,1756)
+trim(C,1757,1757)
+trim(D,1757,1757)
+trim(C,1759,1765)
+trim(D,1766,1766)
+trim(D,1768,1768)
+trim(D,1767,1767)
+trim(D,1770,1770)
+trim(D,1769,1769)
+trim(C,1771,1778)
+trim(D,1780,1780)
+trim(D,1779,1779)
+trim(D,1782,1782)
+trim(C,1782,1782)
+trim(D,1783,1783)
+trim(C,1784,1790)
+trim(D,1792,1792)
+trim(C,1792,1792)
+trim(D,1793,1795)
+trim(C,1796,1803)
+trim(D,1804,1806)
+trim(C,1807,1807)
+trim(D,1807,1807)
+trim(C,1809,1815)
+trim(D,1816,1816)
+trim(C,1817,1817)
+trim(D,1817,1817)
+trim(D,1820,1820)
+trim(D,1819,1819)
+trim(C,1821,1828)
+trim(D,1830,1830)
+trim(D,1829,1829)
+trim(D,1832,1832)
+trim(C,1832,1832)
+trim(D,1833,1833)
+trim(C,1834,1840)
+trim(D,1842,1842)
+trim(C,1842,1842)
+trim(D,1843,1845)
+trim(C,1846,1853)
+trim(D,1854,1856)
+trim(C,1857,1857)
+trim(D,1857,1857)
+trim(C,1859,2211)

This is obviously not an approach that I intent to use every time I come across this sort of material.

[TheFluff]

if you want to fix individual frames, yatta (http://ivtc.org/) is right there, you know (edit: the only reasonable guide to it that has ever been written - it's hardly user-friendly (http://web.archive.org/web/20160610125626/https://warpsharp.info/yatta.txt))

like, you can replace individual frames with like three keystrokes or change field matches with one keystroke, and you have full control over exactly how the ivtc/deinterlacing is done down to individual fields and can visualize it directly, so it's exactly what you want and autogenerates these insane scripts/override files for you

then again you don't seem to be in the habit of taking advice, so I'm kinda wondering why you're even asking questions

[Katie Boundary]

In the absence of any serious, competent attempts to explain why anyone would do this, much less how to fix it, I've been forced to develop my own workarounds. The best overall solution is usually to just grab all the top fields or all the bottom fields, find matches for the ones that have matches, bob any orphaned fields that you're trying to match from, and discard the remaining orphaned fields, converting to 30 hz in the process (which is what a single application of TFM at standard settings would do). However, for the user who demands that every field appear at least once in the final stream, my standard approach for dealing with mixed content can be adapted as follows:

mpeg2source("pd01p1.d2v")

A=TFM(mode=0,field=0,cthresh=2,mthresh=2,pp=5,micmatching=0)
B=TFM(mode=0,field=1,cthresh=2,mthresh=2,pp=5,micmatching=0)

interleave(A,B)

(this was for a BFF source)

The big disadvantage of this method is that most 60 hz content is effectively reduced to 30 hz anyway, but with more jerkiness and frame-blending than if you had just used the first method.