What kind of interlacing/telecine pattern is this?

[kuchikirukia]

I can't make heads or tails of it. It seems to be random interlacing with the chroma off doing its own thing.

http://s000.tinyupload.com/?file_id=...31634349333299

[johnmeyer]

This looks like silent film that was probably originally 16 fps.

It's six fields per frame, with a field reversal every frame. This leads to a field out of order every other frame.

You can simply decimate with this code:

separatefields()
selectevery(6,1,2)
weave()
assumefps(16)

However, because of the field reversal, the fields are out of order and you end up with fields from different points in time on some frames.

If you instead use IVTC, you can easily get everything looking OK, but I couldn't come up with the right settings to avoid dropping a frame when the fields are out of order, every other frame:

tfm()
tdecimate(cycle=6,cycleR=4)
assumefps(16)

The chroma issue is minor and if the decimation and field reversal can be fixed (it's beyond the time I have to play with it), you can simply make sure that the chroma problem, which happens on the first of two pairs of fields, gets decimated.

I think this is 100% fixable, but I just don't have the time to fiddle with the code.

[LemMotlow]

What I get is that this has a "top layer" of 3:2 pulldown. I don't see any field reversal. The movie is bottom field first.

TFM(pp=0).TDecimate()

After inverse telecine I get 23.976 with a few field blends but fairly smooth playback. S few occasional duplicate frames. Remove those and the field blends with Srestore, and you get very choppy motion at 16fps, unwatchable. Appears to be optically scanned from film.

The clip has illegal video levels and clipped brights. I'd inverse telecine with TIVTC and be done with it. Reducing contrast would help keep it from having that DV "cooked colors" look.

[johnmeyer]

Originally Posted by LemMotlow

What I get is that this has a "top layer" of 3:2 pulldown. I don't see any field reversal. The movie is bottom field first.

When I did a separatefields() on the video, I saw two matching field, followed by two more fields that matched. However, the next frame has a field from the initial frame combined with a field from the next frame. This effectively changes the field order. Then, to get things back on track, at the end of the second frame, the bottom field of the next frame is followed by the top field of the second frame, thus giving you the "forward-backward" motion characteristic of field reversal.

It actually is even more complicated than that because every few frames there is a full frame that has to be extracted from this field reversal mess.

This animated GIF shows what is going on. I have separated the video into fields. Pay attention to the slight up/down motion. Each time the picture moves up or down, that is a new field. If you count the number of up/downs until a new point in time is shown, that lets you count how many fields are repeated. Note the back/forward motion of the axe. That is due to the field being in the wrong moment in time. You can't simply switch it because you then get two bottom fields in a row or two top fields in a row. That is wrong. You can never have two top or two bottom fields in a row.

[LemMotlow]

Indeed, if I set the wrong field order (TFF) and use SeparateFields on telecined video I get the same thing (Does SeparateFields pull telecined fields apart properly? I don't recall it doing so very well). Try BFF and you won't see reverse motion. What you will see with SeparateFields on telecined video is what looks like field blending every few frames, plus duplicate frames periodically, followed by a dropped or missing field.

It's a mess. I'd find a better piece of video to work with.

[johnmeyer]

It is true that with interlaced video, setting the wrong field order will give you the "two steps forward, one step back" jitterbug when you view the video using bob() or separatefields(). However, I don't think that is what is going on here. The first thing I did was to try both AssumeTFF after I initially tried AssumeBFF. They both produced a similar problem because this is not a field dominance issue, but instead is caused by having fields weaved together in the wrong order.

If I get a few minutes tomorrow I'll take another look. As video screw ups go, this one is unusual, but I think it can actually be salvaged and made to look quite good. Of course the film transfer is pretty awful, with serious blown out highlights, but that's another story ...

[kuchikirukia]

Originally Posted by LemMotlow

It's a mess. I'd find a better piece of video to work with.

I just hit it with QTGMC and it watches just fine at 60fps. There's actually 60i video segments interspersed so it certainly works well for those portions. I'm just wondering if there's a better way, since there's definitely some progressive and some telecining that it's certainly not optimal to run through deinterlacing.

The cycle seems to walk (it goes though blending phases every so often), so my guess it would be difficult to get something that would work through all the the shifts, especially with the chroma on its own cycle.

[LemMotlow]

Originally Posted by kuchikirukia

I just hit it with QTGMC and it watches just fine at 60fps.

Your video will have duplicate, triplicate, and blended frames. Not the way to work with telecined source.

[kuchikirukia]

Originally Posted by LemMotlow

Your video will have duplicate, triplicate, and blended frames. Not the way to work with telecined source.

It works better than missing/duplicate frames at 30/24 and residual combing everywhere.

Deinterlacing to 60p is assured not to have lost any good fields and the bad ones go by too fast to notice. It's often the least worst choice for butchered sources.

[johnmeyer]

Originally Posted by kuchikirukia

Deinterlacing to 60p is assured not to have lost any good fields and the bad ones go by too fast to notice. It's often the least worst choice for butchered sources.

Having played with this clip, I really cannot agree. The last thing you want to do with this clip is to apply any sort of deinterlacing. Instead, this is almost entirely a decimation problem, with a small additional issue of the chroma on the first dup.

[kuchikirukia]

Originally Posted by johnmeyer

Instead, this is almost entirely a decimation problem, with a small additional issue of the chroma on the first dup.

Mhmm, but we don't yet have a decimation solution.

Added fun is that this is going to have to be VFR to deal with the 60i video.

[johnmeyer]

Originally Posted by kuchikirukia

Mhmm, but we don't yet have a decimation solution.

Added fun is that this is going to have to be VFR to deal with the 60i video.

What 60i video?? I know that someone posted this earlier in this thread, but I just went through the entire clip again, and I sure didn't find anything that looked like 60i video. For this to be the case, there would need to be a temporal shift between two fields of the same frame. While this does happen because of the misplaced fields, this is in no usual sense of the term "interlaced."

If I have time, I'll give you the decimation and field reweaving code needed to fix this. As I've said previously, this clip can be salvaged quite nicely by using both decimation (IVTC) along with something to better match the fields.

There is no interlaced video in this clip.

[kuchikirukia]

Originally Posted by johnmeyer

What 60i video?? I know that someone posted this earlier in this thread, but I just went through the entire clip again, and I sure didn't find anything that looked like 60i video.

It wasn't in the clip, but there's 60i video in this film.

http://s000.tinyupload.com/?file_id=...97613344818263

[LemMotlow]

That clip isn't 60i. It's the same telecine as the other clip.

Why do people insist on transferring VOB video to mkv containers? Don't you know how to do it properly with DGindex?

[johnmeyer]

I finally had a few minutes and devised a solution which works perfectly (although there are still a few minor chroma issues).

In doing this I realized something I didn't catch before: the first part of the clip and second part of the clip actually have a different cadence. For the first part, you use this code:

tfm(mode=5)
tdecimate(cycle=20,cycleR=14)
assumefps(16)

and for the second part (the axe-chopping) you use this:

tfm(mode=5)
tdecimate(cycle=20,cycleR=12)
assumefps(16)

I merged these two together into a single HuffYUV-encoded clip. I timed the playback for 16 fps for both clips. However, the axe chopping is probably closer to 15 fps and the man is probably closer to 18 fps. However, you can deal with that when you put back together these two 15 & 18 fps progressive silent film clips with the 60i portions that you say are later in this video file. For the film clips to match the video, you'll have to add pulldown using something like this:

ChangeFPS(60000,1001)
AssumeBFF() # or BFF, as required
SeparateFields()
SelectEvery(4, 0, 3)

That will get the film clips to play as 60i video.

Here's a link to the results of my work on the clip you posted:

Recovered Video

P.S. I hate posting big files like this, but I don't know what other option I should use that will preserve the original quality, make it easy to inspect individual fields, and be usable by the largest number of people who choose to download it.

[kuchikirukia]

Originally Posted by LemMotlow

That clip isn't 60i. It's the same telecine as the other clip.

Watch the whole thing.

[johnmeyer]

Originally Posted by kuchikirukia

Watch the whole thing.

Did you watch what I posted?? I spent quite a bit of time on this and would be interested in whether it does what you expected.

And yes, the later part of the second clip you posted is 60i, although it too has some field issues that will need to be fixed.

[LemMotlow]

Originally Posted by johnmeyer

I finally had a few minutes and devised a solution which works perfectly (although there are still a few minor chroma issues).

In doing this I realized something I didn't catch before: the first part of the clip and second part of the clip actually have a different cadence. For the first part, you use this code:

tfm(mode=5)
tdecimate(cycle=20,cycleR=14)
assumefps(16)

and for the second part (the axe-chopping) you use this:

tfm(mode=5)
tdecimate(cycle=20,cycleR=12)
assumefps(16)

I merged these two together into a single HuffYUV-encoded clip. I timed the playback for 16 fps for both clips. However, the axe chopping is probably closer to 15 fps and the man is probably closer to 18 fps. However, you can deal with that when you put back together these two 15 & 18 fps progressive silent film clips with the 60i portions that you say are later in this video file. For the film clips to match the video, you'll have to add pulldown using something like this:

ChangeFPS(60000,1001)
AssumeBFF() # or BFF, as required
SeparateFields()
SelectEvery(4, 0, 3)

That will get the film clips to play as 60i video.

Here's a link to the results of my work on the clip you posted:

Recovered Video

Yep, downloaded and ran the sc ript as ell. Man, some serious issues with discarded frames. I guess it doesn't matter. I still say the best thing to do is leave the damn original alone and play it as-is. Everything I've seen just makes it look worse and it already looks like sub-entry level plain vanilla bad video work.

[johnmeyer]

I don't know whether I'd agree that it has "serious issues" with discarded frames. There is a dropped frame around frame 15 in my uploaded video. There may also be a few on the axe chopping. I was trying to do this in the few minutes I had available, and didn't tune all the TFM and TDecimate parameters. I could probably get better results by using a longer cycle, and possibly a different mode. That is the usual "trick" that solves these problems. Also, I was in a hurry when I chose the CycleR value for the script for the axe chopping. I think that changing that by one would probably fix the problem in the second half of the clip.

[LemMotlow]

Really? I've learned a lot from you, john, but I know what I'm seeing. And it's pretty choppy in lots of places.