Entire frame occasionally drops down 1 line, interlacing/field order issue?

[Killer3737]

I have a selection of videos from a friend that were TV recordings to VHS digitized on a DVD Recorder. The quality is pretty good but there is an issue where every few seconds, the image seems to physically drop down by a line or two for a single frame, then back to normal. This happens on several files all from different days and VHS so it must have been an issue somewhere in the capture process rather than anything from broadcast but unfortunately the source tapes are all long gone, retransferring is impossible.

Looking at the MPEG-2 frame by frame in AvsPMod I first confirmed it is indeed interlaced, there is movement on every field via separatefields. I then looked to find the erroneous frames and there is an obvious difference, huge combing artifacts appear for that frame only so I assume it's an interlacing/field order issue of some sort?

Frame before:


[Attachment 90133 - Click to enlarge]

Erroneous frame:

[Attachment 90134 - Click to enlarge]

Another video with a logo also illustrates it well. Middle frame it drops by two lines, the frame before and after are both aligned.

[Attachment 90136 - Click to enlarge]

I have attached a short sample where it happens a few times. Some frames there is the drop, but no combing. Doesn't seem consistent either. On this particular video the first six are frames 25,94,125,161,192.

Anyone know what is going on here, and if a fix is possible?

[Sharc]

Field glitches, like breaks in the fields sequence (=broken field dominance), dropped or swapped fields.
You can try to mitigate with field matching

TFM(order=-1,mode=0,pp=0) # play with the settings

Frame 125: left original - right matched


[Attachment 90139 - Click to enlarge]

or maybe better just deinterlace using QTGMC() for some improvement.

For a better (more laborious) fix one would have to address these drops or swaps individually.

[lollo]

The problem is related to a defect in the tape that the TBC of the VCR is compensating. Most of them are happening across multiple captures, few are marginal and can be present or not.
The TBC while adjusting the fields is introducing a shift in one or bot of them. It can happen also with VCR without TBC, but the defect is present in a different way (bad frame) masking it.

To find them you can run a specific script a manually move frame by frame:

# defects
# 25 field even shifted down, field odd shifted down
# 94 field odd shifted down
# 125 field odd shifted down
# 161 field odd shifted down

video_org=FFmpegSource2("error-sample.demuxed.m2v")

# separate fields tff
video_org_sep_tff=video_org.AssumeTFF().separateFields()

# separate fields tff even
video_org_sep_tff_even=video_org_sep_tff.SelectEven()

# separate fields tff odd
video_org_sep_tff_odd=video_org_sep_tff.SelectOdd()

	# display frames and display fields separately (equivalent to VirtualDub plugin ViewFields)
stackhorizontal(\
subtitle(video_org,"video_org",size=28,align=2),\
stackvertical(\
subtitle(video_org_sep_tff_even,"video_org_sep_tff_even",size=28,align=2),\
subtitle(video_org_sep_tff_odd,"video_org_sep_tff_odd",size=28,align=2)\
)\
)

To fix them you can run a dedicated script:

video_org=FFmpegSource2("error-sample.demuxed.m2v").ConvertToYUY2()

# shift fields
video_org_rep=video_org\
.shift_fields(25,-1,-1)\
.shift_fields(94,0,-1)\
.shift_fields(125,0,-1)\
.shift_fields(161,0,-1)

stackhorizontal(subtitle(video_org,"video_org",size=28,align=2).showframenumber(), subtitle(video_org_rep,"video_org_rep",size=28,align=2))

#return(video_org_rep)


function shift_fields(clip c, int frame_number, line_shift_even, line_shift_odd)
{
# separate fields tff
c_tff_sep=c.AssumeTFF().separateFields()

# separate fields tff even
c_tff_sep_even=c_tff_sep.SelectEven()

# separate fields tff odd
c_tff_sep_odd=c_tff_sep.SelectOdd()

# shift field even
c_tff_sep_even_rep = (line_shift_even > 0) ?\
	c_tff_sep_even.trim(0,frame_number-1)\
	++c_tff_sep_even.trim(frame_number,frame_number).crop(0,0,0,-line_shift_even).addborders(0,line_shift_even,0,0)\
	++c_tff_sep_even.trim(frame_number+1,0)\
:\
	c_tff_sep_even.trim(0,frame_number-1)\
	++c_tff_sep_even.trim(frame_number,frame_number).crop(0,-line_shift_even,0,0).addborders(0,0,0,-line_shift_even)\
	++c_tff_sep_even.trim(frame_number+1,0)

# shift field odd
c_tff_sep_odd_rep = (line_shift_odd > 0) ?\
	c_tff_sep_odd.trim(0,frame_number-1)\
	++c_tff_sep_odd.trim(frame_number,frame_number).crop(0,0,0,-line_shift_odd).addborders(0,line_shift_odd,0,0)\
	++c_tff_sep_odd.trim(frame_number+1,0)\
:\
	c_tff_sep_odd.trim(0,frame_number-1)\
	++c_tff_sep_odd.trim(frame_number,frame_number).crop(0,-line_shift_odd,0,0).addborders(0,0,0,-line_shift_odd)\
	++c_tff_sep_odd.trim(frame_number+1,0)

# repaired video
c_rep=interleave(c_tff_sep_even_rep,c_tff_sep_odd_rep).Weave()

return(c_rep)
}

You can also notice that the defect at frame 161 triggers the AGC of the capture device, because the is a change in brigthness (sometimes it happens)







comparison: a_fix.avi

It is a long and boring processing!

[Sharc]

Here a different approach, based on substitution of the damaged frames by motion interpolated frames from healthy adjacent frames.
Note that below works well for single bad frames in a row only. In case of multiple bad frames in a row some of the artifacts would survive.
(Script was proposed by jagabo some time ago)

BSSource("error-sample.demuxed.m2v")
interpolate = Interpolate_RIFE() 
ReplaceFramesSimple(interpolate, Mappings="25 94 125 161") # list of frames to be replaced

function Interpolate_RIFE(clip source)
{
    source.z_ConvertFormat(pixel_type="RGBPS", colorspace_op="709:709:709:limited=>rgb:709:709:full")
    e = SelectEven().RIFE(gpu_thread=1, model=5).SelectOdd()
    o = SelectOdd().RIFE(gpu_thread=1, model=5).SelectOdd()
    Interleave(e,o)
    Loop(2,0,0)
    z_ConvertFormat(pixel_type=source.pixeltype, colorspace_op="rgb:709:709:full=>709:709:709:limited")
}

[Selur]

How about QTGMC+Stab?

[jagabo]

How about QTGMC+Stab?

That's what I was going to suggest.

[lollo]

How about QTGMC+Stab?

For field shifts higher than 1 pixel it never worked for me (I assume the reason being that with 1 pixel shift we are inside the "bobbing" architecture of the PsF fields). Look to the defects in the logo of the TV station.

Input file: a.avi

script:

video_org=AviSource("a.avi")

### crop pre stab, rimozione esatta del disturbo sotto 
	crop_bottom=12
video_org_crop=video_org.crop(0,0,0,-crop_bottom,align=true)

### stabilizing
stabilized=video_org_crop.ConvertToYV16().QTGMC(InputType=1).Stab().SelectEvery(2,0).ConvertToYUY2().addborders(0,0,0,crop_bottom)

stackhorizontal(\
subtitle(video_org,"video_org",size=28,align=2),\
subtitle(stabilized,"deint-stab-even",size=28,align=2)\
)

Comparison: a1.avi

edit: in addition, with QTGMC and Stab you are processing and filtering the original video altering its "quality" (and we know how impacting is QTGMC), while the fields shift does not impact at all the video (the added/shifted black lines on the bottom or top are corrupted anyhow) and leave you a pristine source to further process as you like.

[Sharc]

How about QTGMC+Stab?

That's what I was going to suggest.

Looks nice and clean. The wiki warns of an unsolved bug possibly causing random green tinting for Stab.
Not a problem in this case it seems ....

[Sharc]

edit: in addition, with QTGMC and Stab you are processing and filtering the original video altering its "quality" (and we know how impacting is QTGMC), while the fields shift does not impact at all the video (the added/shifted black lines on the bottom or top are corrupted anyhow) and leave you a pristine source to further process as you like.

Sure. Just proposing simpler alternatives for an 'acceptable' compromise
(The OP has never returned. Did we frighten him?).

[Selur]

really short sample,.. using StabilizeIT+Stab (=stab.mks) seems more pleasing,..
Personally, I would probably try stab or stabilize on the separated fields,...


Cu Selur

[Selur]

Looks nice and clean. The wiki warns of an unsolved bug possibly causing random green tinting for Stab.

Can't remember an instance where I have seen a green tint due to stab,...

[lollo]

Sure. Just proposing simpler alternatives for an 'acceptable' compromise

Which is a good alternative, because the individual field processing is a nightmare!

(The OP has never returned. Did we frighten him?).

I hope not

Can't remember an instance where I have seen a green tint due to stab,...

The "green tint" is generally caused by bad color space and/or dependancy filters not synchronized across different releases.