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=65317131634349333299

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

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.

http://i177.photobucket.com/albums/w208/johnmeyer/Separate%20Fields%20from%20Frameserved%20Video2_zps5ne6q6ur.gif

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

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]

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]

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]

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]

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]

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]

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=00340397613344818263

[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 (https://www.mediafire.com/?1lg4py1k9bv7s3c)

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]

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

Watch the whole thing.

[johnmeyer]

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]

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 (https://www.mediafire.com/?1lg4py1k9bv7s3c)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.

[johnmeyer]

It's choppy because it is a low frame-rate film. At 16 fps, video/film looks really choppy because there is a big temporal difference between each frame.

To see if there are jumps you have to look at it frame-by-frame. The only drop I detected was the one I already mentioned in my last post.

[johnmeyer]

P.S. The other way to look for drops is to compare the original with the "fixed" version and see if there are any frames/fields in the original that are not represented in the final version. I did this with my initial attempt that I posted a few days ago, and there were definitely drops.

[LemMotlow]

Cut the b.s., man. Your script chopped the hell out of some segments. It's crap video and probably scanned at the wrong shutter speed, but don't push the b.s past credulity.

[johnmeyer]

Cut the b.s., man ... don't push the b.s past credulity.

My oh my, what kind words. It makes my heart sing to hear my work called "b.s." (and what an articulate way of putting it). It makes me realize that my time was well spent. :angry:

In that first half of the video (the man's head), every frame from the original film is intact, other than frame 15. I've already described how to fix that one, very minor problem. I also described how to fix the axe chopping video by using a higher CycleR value.

If you can find any other frames from the first half of the original film clip that are not in the "fixed" version, please let us all know. I don't think there are any.

So, the script worked, and did what it was supposed to do.

It appears that you have seldom had to deal with low frame-rate film, and therefore have very little basis of comparison. Yes, the "fixed" clip is "choppy" but that is because it has only 20% of the temporal information of modern video.

I deal with 100-year old film all the time, much of it hand-cranked so that it runs at only 12 fps, like this transfer I did six years ago:

1928 Backyard Football (https://www.youtube.com/watch?v=1YekFxBYKNM&t=3s)

What you see in this YouTube video is the result of a transfer I did myself from the original 90-year-old film, using a frame-accurate transfer system. Therefore I know -- with 100% certainty -- that there are no missing or dropped frames.

But despite being a "perfect" transfer, as you will see, it too is "choppy." That's the nature of old amateur silent film.

And that ain't "b.s."

[LemMotlow]

I'm with johnmeyer, the two parts of the clip were processed differently, then combined. I took another route and tried to imagine (!) how the hell the maker made this piece of crap in the first place, and tried to reverse the process. I guess there's more than one way to do it.

I couldn't stand watching all that DV noise, red push, and hot highlights. I cut the clip into parts A and B, then joined them. The linked mp4 is 19.98fps. The linked m2v is DGPulldown from 19.98 to 29.97fps NTSC. I see a couple of frames of stutter in the first shot of the results, which look like duplicate frames. Likely what johnmeyer referred to as a few misplaced (out of order) fields. In the original those spots are around frames 274 and 320, they affect frames 219 and 250-256 or thereabouts in the linked samples. I got tired of fooling with it.

Part A:
Trim(0,406)
ColorYUV(cont_y=-35)
TFM(pp=0).TDecimate()
QTGMC(preset="very fast",EZDenoise=8,denoiser="dfttest")
sRestore(frate=23.976)
AssumeFPS(20000/1001)

Part B:
Trim(407,0)
ColorYUV(cont_y=-35)
QTGMC(preset="very fast",EZDenoise=8,denoiser="dfttest")
sRestore(frate=19.980)
AssumeFPS(20000/1001)

VTS01_19.98fps.mp4, ~14MB https://www.mediafire.com/?8369n9bdelupt7d
VTS01_DGpulldown_29.97fps.m2v, ~14MB https://www.mediafire.com/?fibuuegk32f7fd2