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.

[Katie Boundary]

Originally Posted by Sharc

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.

Originally Posted by Sharc

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.

Originally Posted by ndjamena

Gargoyles is animated at 24p

Not the opening credits.

Originally Posted by ndjamena

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.

Originally Posted by ndjamena

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]

Originally Posted by Sharc

A sample of few seconds would help.

Originally Posted by Katie Boundary

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?

[hello_hello]

Originally Posted by Groucho2004

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.

Originally Posted by Groucho2004

Not in this context. It was explained to you how to create a video sample here. 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.p...31#post1792931

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

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

Originally Posted by Groucho2004

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

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

Originally Posted by Overdrive80

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.

Originally Posted by ndjamena

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]

Originally Posted by Katie Boundary

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

[Katie Boundary]

Originally Posted by Groucho2004

Not in this context. It was explained to you how to create a video sample here. 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.

[Sharc]

Originally Posted by Katie Boundary

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?

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

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

[hello_hello]

Originally Posted by 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.

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.

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

[Katie Boundary]

Originally Posted by 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.

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

Originally Posted by ndjamena

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

I told you first.

Originally Posted by ndjamena

Or are you referring to something else in the credits?

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

Originally Posted by johnmeyer

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

Too bad for you.

Originally Posted by johnmeyer

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.

Originally Posted by johnmeyer

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?

Originally Posted by johnmeyer

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.