Automatically Detect & Correct Field Shifts

[johnmeyer]

I have several dozen football DVDs from a collector that all have intermittent field shift problems. He wants me to fix them (test clip link below).

I was easily able to fix one DVD that had this same problem through the entire disc. I used this simple field shift script to shift the even fields:

#Script to shift one field down

Hshift = 0
Vshift = 1

source = AVISource("e:\fs.avi").assumetff()

separatefields(source)
even = selecteven()
odd = selectodd()

even = crop(even,Hshift,Vshift,0,0)
even = addborders(even,0,0,Hshift,Vshift)

interleave(even,odd)
output = weave()
return output

The problem I now have is that these other discs have the problem in some places, but not others. Therefore, I need to detect the problem and only apply the fix when needed. I think I can do this using a conditional script by comparing YDifference values for the bobbed version of the original video and the bobbed version of the shifted video, and then taking the frame from the version that has a lower YDifference value. However, I'm afraid that I might get a lot of single frame spurious field shifts using this approach because YDifference may not be the best way to detect the spurious up/down motion you get on the bobbed version of video that has one field shifted to the wrong position.

Does anyone have a suggestion of a better way of detecting the shift?

Here is a sample file. The first half of the video (where you see the graphic overlay) has the field shift problem; the second half (with just the players) does not have the problem, and is normal NTSC video. I purposely created a clip that has very little movement because you can more easily see the problem on static video.

Field Shift Test Clip.avi (http://www.mediafire.com/download/bsbo3u87b1e8h8p/Field_Shift_Test_Clip.avi)

Thanks!!

[Guest]

If it is from DVDs, why are you giving us an AVI? Your sample should be a cut of the source VOB. Use DGSplit for example.

Otherwise, how can we know you did not create the issue when creating the AVI?

[johnmeyer]

If it is from DVDs, why are you giving us an AVI? Your sample should be a cut of the source VOB. Use DGSplit for example.

Otherwise, how can we know you did not create the issue when creating the AVI?OK. It was just a lot easier to do it that way because of my workflow. However, since you've asked, I'll post a lossless cut of the MPEG-2 source (using Womble's excellent MPEG-2 cutter), but it will exhibit exactly the same issue. I'll do that later today when I'm back at my editing machine. In the meantime, if anyone else is willing to offer some advice, I would still appreciate some help.

[johnmeyer]

Here's almost exactly the same two clips, merged together, but in the original MPEG-2 format, without any re-encoding. I used Womble's MEPG Video Wizard to do the cutting and joining:

Field Shift Test Clip.mpg (http://www.mediafire.com/?xhbtctmcpl0fhz0)

Personally, I prefer to not deal with MPEG-2 files in AVISynth because I prefer not to generate the intermediate d2v file. I never feel as though I have the same level of control and understanding of the source as I do when I frameserve out of Vegas, a process that in many ways is similar, but which "exposes" more of what is going on during the frameserving.

So, if anyone can provide some better ideas than using YDifference to detect the portions of the video that have the field shift, that would be great. You now have the choice of using either AVI or MPEG-2 files as the source.

[johnmeyer]

This is the prototype script for finding and fixing the field shift problem. I still need to convert the bobbed video back to interlaced. It appears to be working, but I'm not convinced that my detection logic -- which is based entirely on YDifference values -- is the best possible approach. So far, looking at dozens of randomly selected sections of the three hours of this first game, I haven't found any failures. However, I'd still appreciate any pointers or ideas.

Obviously the video is still going to need a lot of additional processing, including chroma denoising, grain denoising, and both gamma and color correction. I also wish that wonderful TBC script had worked out better, because this obviously got stored on a VHS tape at some point, and when captured from that tape, no time base corrector was used. Since it contains the overscan on both the left and right side, if that plugin worked, this could be corrected. But, that's a story for another time.

Thanks!

# Script to both detect, and then fix, video in which one field has been shifted up by one line.
# June 4, 2013

#loadPlugin("c:\Program Files\AviSynth 2.5\plugins\MPEGDecoder.dll")
#loadPlugin("c:\Program Files\AviSynth 2.5\plugins\GRunT.dll")

#source=mpegsource("E:\film\1974 Rams 49ers 01.mpg")\
source=AVISource("e:\fs.avi").killaudio().assumetff().bob(0,1).ConvertToYV12()

#Perform the shift on bobbed source by first cropping and then adding border
Hshift = 0
Vshift = 2
even = selecteven(source)
odd = selectodd (source)
even = crop(even,Hshift,Vshift,0,0)
even = addborders(even,0,0,Hshift,Vshift)
output = interleave(even,odd)

#The next two lines are used during debugging to make sure YDifference metrics
#really do detect field shift reliably
#script = """Subtitle("\nsource = " + String(YDifferenceFromPrevious(source)) + \
# "\noutput = " + String(YDifferenceFromPrevious(output)), lsp=0)"""
#Scriptclip(output, script)

final = output.scriptclip("""YDifferenceFromPrevious(source) > \
YDifferenceFromPrevious(output) ? output : source""")
return final

[ChiDragon]

It just randomly shifts during the middle of a shot? And then stays that way for a while, or changes all the time?

[johnmeyer]

It just randomly shifts during the middle of a shot? And then stays that way for a while, or changes all the time?It stays consistently wrong or consistently correct for long periods of time, usually 5-10 minutes at least before shifting again. The short clip I provided -- in both formats -- was actually created from two different sections of the three hour game. I actually haven't tried to find the specific frames where the transition occurs between normal video and shifted-field video.

This tape, like so many videos I get from collectors, was originally copied from a network source (i.e., the tape was not made from a re-broadcast of the original show). The problem is that the "food chain" from that point forward often gets lots of "hands" involved and often there are not only videotape generation issues, but also the kind of thing seen here. My guess is that when someone decided to transfer the LP VHS tape to DVD, they used a capture card that got screwed up by the frequent loss of sync (there are breakups on the original network master) and the capture software went berserk. However, even if that is the wrong scenario, it doesn't really matter. The video is what it is.

When it has been handled properly, the quality of much of this material is actually pretty amazing. I have been fortunate enough to get first-generation transfers from network Quadruplex originals, and the quality of those -- especially after proper help from various AVISynth scripts and plugins -- is remarkably good.

I'm letting the computer crank on the three hour show now. I'm using the following script (same as posted above, but with the re-interlacing added). I looked at about thirty points in the video, using a stackvertical between the original bobbed source and the bobbed output of the following script. Where the field order was initially correct, the field order appears to still be correct, and no "damage" has been done to the original video. Where the field order was incorrect, the field shifting worked, and the resulting video looks exactly the same quality as the portions of the video that didn't have a problem.

# Script to both detect, and then fix, video in which one field has been shifted up by one line.
# June 4, 2013

#loadPlugin("c:\Program Files\AviSynth 2.5\plugins\MPEGDecoder.dll")
#loadPlugin("c:\Program Files\AviSynth 2.5\plugins\GRunT.dll")

#source=mpegsource("E:\film\1974 Rams 49ers 01.mpg")\
source=AVISource("e:\fs.avi").killaudio().assumetff().bob(0,1).ConvertToYV12()

#Perform the shift on bobbed source by first cropping and then adding border
Hshift = 0
Vshift = 2
even = selecteven(source)
odd = selectodd (source)
even = crop(even,Hshift,Vshift,0,0)
even = addborders(even,0,0,Hshift,Vshift)
output = interleave(even,odd)

#The next two lines are used during debugging to make sure YDifference metrics
#really do detect field shift reliably
#script = """Subtitle("\nsource = " + String(YDifferenceFromPrevious(source)) + \
# "\noutput = " + String(YDifferenceFromPrevious(output)), lsp=0)"""
#Scriptclip(output, script)

fixed = output.scriptclip("""YDifferenceFromPrevious(source) > \
YDifferenceFromPrevious(output) ? output : source""")

#Convert back to interlaced
evenbob = selecteven(fixed)
oddbob = selectodd(fixed)
EvenOrig = separatefields(evenbob).selecteven()
OddOrig = separatefields(oddbob).selectodd()
interleave(EvenOrig,OddOrig)
weave()

[johnmeyer]

Final post on this. I completed the project and the script above fixed most of the problems. However, as expected, during high-motion scenes where both the players and the camera were moving, the YDifference values resulting from the movement were larger than what was caused by the up/down bobbing caused by the field misalignment and as a result, for a few frames during these scenes the field shift either didn't get detected and fixed, or was actually created by shifting fields that didn't need to be shifted.

So my original reason for posting here still stands unanswered: is there a better way to detect this problem than using YDifference values?