Automatic detection (and correction) of swapped fields?

[magiblot]

Related thread: https://forum.doom9.org/showthread.php?p=1802497#post1802497

I have a VHS rip which was encoded optimally (lossless codec, interlaced video). It contains an animation telecined with pulldown (not field blended), so I have been able to do field matching (check the related thread I linked above for more information).

Sample: https://drive.google.com/file/d/0B8YfT7N-cAzCYkl0UUdtdmM4TjA/view?usp=sharing (Note: x264 with "progressive" settings by mistake)
Lossless version of previous link (use this one): https://drive.google.com/uc?id=0B8YfT7N-cAzCU3dNYzdEM0ItR3c&export=download (1,2 GB)

However, because of VHS unstability, there are a few frames in which the fields are inverted. Example (notice the labels in top left corner):

http://i.imgur.com/H58SBJN.png
http://i.imgur.com/da1wCpW.png
http://i.imgur.com/e2X3oRH.png

If we invert the fields of f2, we get the proper frame (I let the "f2" string distort to show the field swap):

http://i.imgur.com/yrdPoWR.png



I wonder if there is any simple function which is able to find out if the fields are inverted and, if that's the case, swap them back to normal.

Many thanks.

[real.finder]

the .avi always Assume BFF, but your source is TFF (use avs bob() or SeparateFields() and see the moving scenes)

ffms2("E:\sample3.avi")
AssumeTFF()
AnimeIVTC(1,0,5,mi=50,blockx=8,blocky=8, ediandnn=3, repwithtdeint=true, tfmm=0, micmatching=0, autoAssuf=true, o3025cfr=true).TDecimate(1)

[Sharc]

You may also want to try
assumeTFF()
telecide(guide=1,post=2,vthresh=60).tdecimate()

[magiblot]

Script for comparing:

#Use SetMemoryMax if you need it
vint = ffms2("sample3.avi") #Same file I posted above

separated = vint.SeparateFields()
f0 = separated.selectevery(10,0,1).Weave().Subtitle("f0").Subtitle("f0",align=9)
f1 = separated.selectevery(10,2,3).Weave().Subtitle("f1").Subtitle("f1",align=9)
f2 = separated.selectevery(10,4,5).Weave().Subtitle("f2").Subtitle("f2",align=9)
f3 = separated.selectevery(10,6,9).Weave().Subtitle("f3").Subtitle("f3",align=9)
matched = Interleave(f0,f1,f2,f3) #Manual field matching and decimation

line = BlankClip(matched,width=2)

vint
assumeTFF()
telecide(guide=1,post=2,vthresh=60).tdecimate()
Sharc = last.Subtitle("Sharc").Subtitle("Sharc",align=9)

vint
AssumeTFF()
AnimeIVTC(1,0,5,mi=50,blockx=8,blocky=8, ediandnn=3, repwithtdeint=true, tfmm=0, micmatching=0, autoAssuf=true, o3025cfr=true).TDecimate(1)
real_finder = last.Subtitle("real_finder").Subtitle("real_finder",align=9)

#"Sharc" has one frame less in the beginning, thus "matched" is trimmed the first frame
comp_Sharc1 = StackHorizontal(matched.trim(1,0).crop(0,0,-360,0),line,Sharc.crop(360,0,0,0))
comp_Sharc2 = StackHorizontal(Sharc.crop(0,0,-360,0),line,matched.trim(1,0).crop(360,0,0,0))
comp_Sharc = Interleave(comp_Sharc1,comp_Sharc2)

comp_real1 = StackHorizontal(matched.crop(0,0,-360,0),line,real_finder.crop(360,0,0,0))
comp_real2 = StackHorizontal(real_finder.crop(0,0,-360,0),line,matched.crop(360,0,0,0))
comp_real = Interleave(comp_real1, comp_real2)

#Now, return either comp_Sharc or comp_real

real_finder's suggestion:

ffms2("E:\sample3.avi")
AssumeTFF()
AnimeIVTC(1,0,5,mi=50,blockx=8,blocky=8, ediandnn=3, repwithtdeint=true, tfmm=0, micmatching=0, autoAssuf=true, o3025cfr=true).TDecimate(1)

This is good, because it demonstrates the clip can be actually IVTC'ed with a current function. It looks exactly the same as "matched" (read my script) for most frames; however, there are some which have additional processing (check frames 56-57, 92-93, 112-113 of "comp_real" clip), but it actually seems to improve the quality (comparison of frames 112-113 here (http://diff.pics/Ha9AnTcX13J0/1)).
(Edit: I found one case in which AnimeIVTC result is worse, see comparison of frames 4524-4525 (http://diff.pics/ADSQRxHoHT37/1), look at the bottom right corner).
(Edit: similar results with TFM(order=1,pp=0)).
In frames 84-85 of my script the fields remain inverted, it isn't fixed.
Unfortunately, this AnimeIVTC call is much slower than the code for "matched" clip.

Sharc's suggestion:

assumeTFF()
telecide(guide=1,post=2,vthresh=60).tdecimate()

This solves the inverted fields problem (frames 82-83 of "comp_Sharc" clip), but it's not very accurate in scenes with motion. See the example in this link (http://diff.pics/dRaFHsJjS8Jk/1) (frames 76-77). In other parts of the video it looks the same as "matched", with some frame looking a bit processed, similarly to what I experienced in the previous case.

[real.finder]

your source need much work, look at ringing at right of any edges

[magiblot]

your source need much work, look at ringing at right of any edges

I know, I already requested the ripper to get another VCR and use S-Video cable.

[real.finder]

I know, I already requested the ripper to get another VCR and use S-Video cable.

that maybe make changes but there are some filters for this like LGhost, this filter work even before ivtc, so it can make the ivtc work better if you fix the ringing

[magiblot]

that maybe make changes but there are some filters for this like LGhost, this filter work even before ivtc, so it can make the ivtc work better if you fix the ringing

I'll give it a try, but the link in the wiki seems to be very old (2003). Am I missing any update?

Also, what I need to finish IVTC is just fixing these frames with swapped fields (I think they are caused by the ripper's VCR, since it also did that to other rips, in addition to causing strong noise). It's easy to see if a frame has its fields inverted, but I don't know how that can be programmed. Maybe, in the case of this clip, it's possible to find out by comparing with neighbour frames, since the frames with swapped fields are standalone.

[real.finder]

but the link in the wiki seems to be very old (2003). Am I missing any update?

you didn't, it's old filter but did the job

[magiblot]

Wow! LGhost sure is powerful! Sadly, I am not very sure of what I'm doing while changing the parameters XD. I managed to improve part of the ringing, but I also caused some of it to be more noticeable. What college degree do I study to dominate all the concepts surrounding this? (Seriously, I'm really interested in learning this stuff).

I don't think I can do it any better than this, at the moment:
http://diff.pics/eNhTyrlw7oVl/1

[Sharc]

Sharc's suggestion:
This solves the inverted fields problem (frames 82-83 of "comp_Sharc" clip), but it's not very accurate in scenes with motion. See the example in this link (http://diff.pics/dRaFHsJjS8Jk/1) (frames 76-77). In other parts of the video it looks the same as "matched", with some frame looking a bit processed, similarly to what I experienced in the previous case.
It "solves" the shifted field problem because the field shift happens only with top fields (just luck in your clip?), and telecide() chooses bottom fields and matches top fields.
For less post processing simply increase the vthresh value up to 255 (the threshold for triggering the deinterlacing of residual combed frames) or set post=0.
You may also want to add QTGMC(InputType=1) at the end of the script to clean it up. I didn't try this though.

[magiblot]

It "solves" the shifted field problem because the field shift happens only with top fields (just luck in your clip?), and telecide() chooses bottom fields and matches top fields.
For less post processing simply increase the vthresh value up to 255 (the threshold for triggering the deinterlacing of residual combed frames) or set post=0.

You are right, it seems to work well now, but telecide doesn't always choose the proper fields (which should be 0-1, 2-3, 4-5, 6-9; 7 is a copy of 5 and 8 is a copy of the next 0) (field numbers are in modulo 10). It makes other matchings, specially in still scenes, when it can't detect the pattern. Sometimes it gets them wrong and the frame looks aliased.

In fact, I have found it doesn't actually detect and fix the "fields swapped by error" problem. When it finds that situation, it might choose another pair of fields. Just by chance, the first time when this happens (which is a scene with movement), fields 4 and 5 are inverted, but telecide picks field 7 because it matches one of them. However, in another part of the original clip (which is not in the sample file) the swapped fields are 2 and 3, but there is no copy of them among the repeated fields, so it leaves them swapped. In still scenes it can take any other pair of fields, since they appear to match.

[Sharc]

Huuh... there are field shifts with the bottom fields as well?
The file seems to be somewhat pathological....

Out of curiosity:
How was the tape captured? It seems that a "Composite" video signal was in the loop. Still, it could be handled properly. What was the capturing/digitizing HW? How did it get converted to AVC/h.264 and packed into an .avi? The video which was scanned in progressive mode at 29.94 fps is quite unusual. The original interlaced structure got probably lost or damaged somewhere. Is the field shift caused by some pre-editing, or dropped frames/fields during capture?
I think you should revisit the capture process rather than trying to fix the current capture.

[magiblot]

Huuh... there are field shifts with the bottom fields as well?
The file seems to be somewhat pathological....

Out of curiosity:
How was the tape captured? It seems that a "Composite" video signal was in the loop. Still, it could be handled properly. What was the capturing/digitizing HW? How did it get converted to AVC/h.264 and packed into an .avi? The video which was scanned in progressive mode at 29.94 fps is quite unusual. The original interlaced structure got probably lost or damaged somewhere. Is the field shift caused by some pre-editing, or dropped frames/fields during capture?
I think you should revisit the capture process rather than trying to fix the current capture.

I'll check the capture card model later (although I think it's a good one); the bad device is the VCR the ripper used, which is very old and causes strong interference, and is probably related to the field swap problem. Indeed, composite video was used.

EDIT: Avermedia C027 PCIe HD Capture Device (http://www.avermedia.com/tv_more/product/streaming_capture/darkcrystal_hd_capture_pro)

Regarding the capture encoding, I told the ripper to use VirtualDub and encode with Lagarith in YUY2 colorspace. It's the best I could think of. If there are any problems with the sample I posted in this thread, it must be because I didn't compress to x264 properly, but there is no additional processing. You can find Lagarith samples in the related thread.

[Sharc]

I'll check the capture card model later (although I think it's a good one); the bad device is the VCR the ripper used, which is very old and causes strong interference, and is probably related to the field swap problem. Indeed, composite video was used.

Regarding the capture encoding, I told the ripper to use VirtualDub and encode with Lagarith in YUY2 colorspace. It's the best I could think of. If there are any problems with the sample I posted in this thread, it must be because I didn't compress to x264 properly, but there is no additional processing. You can find Lagarith samples in the related thread.
Just few comments.

Capturing:
Lagarith in YUY2 should be ok AFAIK (I usually use Huffyuv or UTVideo which is still actively maintained though).
Anyway, you may want to inspect the captured file in VDub for dropped frames (Menu: Go -> Mext dropped frame).

Encoding:
When looking at your .avi with MediaInfo it reports "Scan Type: progressive" and "interlaced=0".
You should encode the interlaced video source as interlaced. Means you should include --tff (for Top Field First) in the x264 commandline (directly or via GUI or whatever you used). Encoding an interlaced source as progressive is bad, unless you applied a script for bobbing or deinterlacing before frameserving the stream to x264 for compression. Did you apply such a script? I think not as you wrote there has been no additional processing, but maybe I am missing something.
A short uploaded sample of the the uncompressed captured video could also help to give better advice.

There are quite a few pitfalls possible with analog capturing.

[magiblot]

Just few comments.

Capturing:
Lagarith in YUY2 should be ok AFAIK (I usually use Huffyuv or UTVideo which is still actively maintained though).
Anyway, you may want to inspect the captured file in VDub for dropped frames (Menu: Go -> Mext dropped frame).

It's interesting, finds 17 dropped frames out of ~50000. They somehow follow a pattern: the second key frame before the dropped one (there are actually two consecutive dropped frames) has its fields swapped. This happens three or four times, but not always. Luckily, most dropped frames belong to static scenes.

I suspect this is the VCR's fault, since we did a previous test with a tape in bad conditions, and it caused several frame drops and field swaps (in such a way that some scene would always cause dropped frames, and the following one played flawlessly).

You can find these tests in the following links to see what I mean:

http://kiddocabbusses.tryhappy.net/TestCapture.avi
http://kiddocabbusses.tryhappy.net/TestCapture2.avi

Encoding:
When looking at your .avi with MediaInfo it reports "Scan Type: progressive" and "interlaced=0".
You should encode the interlaced video source as interlaced. Means you should include --tff (for Top Field First) in the x264 commandline (directly or via GUI or whatever you used). Encoding an interlaced source as progressive is bad, unless you applied a script for bobbing or deinterlacing before frameserving the stream to x264 for compression. Did you apply such a script? I think not as you wrote there has been no additional processing, but maybe I am missing something.
A short uploaded sample of the the uncompressed captured video could also help to give better advice.

There are quite a few pitfalls possible with analog capturing.
Thanks a lot! That's just what I was missing. I am still not used to command-line encoding. I encoded with MeGUI, and since it doesn't provide *I could not find an option for interlaced video in the x264 configuration window it provides, I though it didn't matter.

I posted lossless samples in the related thread, but I'll bring these links here too. Check first post.

EDIT: Added the name of the capture card to my previous reply.

[Taurus]

I encoded with MeGUI, and since it doesn't provide an option for interlaced video in the x264 configuration window it provides, I though it didn't matter.

Sure, MeGui shows the interlace modus.
On the second tab of the encoder settings just set tff or bff on the rider "Interlaced Mode"amd your done.
You should really make yourself more familiar with the tools you are playing :D.

[magiblot]

Sure, MeGui shows the interlace modus.
On the second tab of the encoder settings just set tff or bff on the rider "Interlaced Mode"amd your done.
You should really make yourself more familiar with the tools you are playing :D.
Aaaah... you are right :o

[LemMotlow]

Capturing:
Lagarith in YUY2 should be ok AFAIK (I usually use Huffyuv or UTVideo which is still actively maintained though).
Anyway, you may want to inspect the captured file in VDub for dropped frames (Menu: Go -> Mext dropped frame).

Encoding:
When looking at your .avi with MediaInfo it reports "Scan Type: progressive" and "interlaced=0".
You should encode the interlaced video source as interlaced. Means you should include --tff (for Top Field First) in the x264 commandline (directly or via GUI
or whatever you used). Encoding an interlaced source as progressive is bad, unless you applied a script for bobbing or deinterlacing before frameserving the stream
to x264 for compression. Did you apply such a script? I think not as you wrote there has been no additional processing, but maybe I am missing something.
A short uploaded sample of the the uncompressed captured video could also help to give better advice.

There are quite a few pitfalls possible with analog capturing.Agreed 1000%
A line tbc that works would help, too.

I spent two cups of coffee on a rework and did what I could. Still a lot of work left, so don't bother with the details but you haven't set legal levels for capture.
And where did all that skittish RF noise come from? Anyway, for what it's worth....
sample3_rework.mp4 (~80MB) https://www.mediafire.com/?8d8g8hkad4s9e7s

[magiblot]

Lossless version of "sample3.avi" added to first post!

EDIT:
Agreed 1000%
A line tbc that works would help, too.

I spent two cups of coffee on a rework and did what I could. Still a lot of work left, so don't bother with the details but you haven't set legal levels for capture.
And where did all that skittish RF noise come from? Anyway, for what it's worth....
sample3_rework.mp4 (~80MB) https://www.mediafire.com/?8d8g8hkad4s9e7s

The RF noise seems to be the VCR's fault. It did the same to previous captures from the ripper, although he was using the composite video cable, not RF. As I said before, I told him to get a new one. If we are lucky enough, we'll overcome most of the noise with that.

Regarding your rework, I liked what I whatched, looks very neat. You were able to remove a big amount of noise, even if you losed sharpeness, but I guess it can't be helped given the conditions of the source.

I just would like to suggest being careful with IVTC filters. From my experience, most of them get the wrong field pattern. Then, the decimation fails occasionally. It's simplier and faster to use SelectEvery instead, I haven't had any field match problem with it:

http://i.imgur.com/eVrbk2J.gif

And I don't know if this is also because of the IVTC filter, but be careful, since it can be avoided. Look at the "aliasing" in the small wings:

http://i.imgur.com/WTHWZP2.gif

This is the script for the last comparison (if it might help you):

vint =AviSource(..).ConvertToYV12(interlaced=true)
matched = vint.SeparateFields.SelectEvery(10,0,1,2,3,4,5,6,9).Weave.trim(1,0).daa3mod()
LemMotlow = ffms2("C:\Users\magiblot\Videos\Conan\sample3__rework.mp4")
comp1 = StackHorizontal(matched.crop(0,0,-300,0),LemMotlow.crop(420,0,0,0))
comp2 = StackHorizontal(LemMotlow.crop(0,0,-300,0),matched.crop(420,0,0,0))
ConditionalFilter(comp1,comp1,comp2,"(current_frame/8)%2","==","0")

Thanks for helping.

PS: Gifs created with https://ezgif.com/video-to-gif/

[Sharc]

@magiblot
There's probably not much you can do for automating the field shift correction.
Some ideas and a "semi-automatic" approach has been discussed here (see very last post with the .txt file pointing to the fields to be shifted).
http://forum.doom9.org/showthread.php?p=1379653#post1379653

Edit:
And when you have found the solution you could reply to this guy as well. He's waiting for a reply since a year ..... ;)
http://originaltrilogy.com/topic/Shifting-interlaced-field-updown-in-After-Effects/id/48703

[StainlessS]

I have not been tracking this thread, however,
Rather than using Conditional Reader or RemapFrameSimple, you could try SawBones/FrameSurgeon combo, you can create the frames file
in VirtualDub with Sawbones running, on a particular key press will enter frame number / range (as eg 'FX1 n' or 'FX1 s,e') into a frames file, easier than creating frame file by hand. (CTRL/1 = frame number, (CTRL/SHIFT/1 = range).
Do a field shifted version of clip called eg FX1,


Last=Whateversource()
FX1=FunctionToShiftFields()
Cmd="FramesFile.txt"

return FrameSurgeon(Last, Cmd=Cmd,fx1=FX1)


https://forum.doom9.org/showthread.php?t=173158&highlight=sawbones

[magiblot]

Edit:
And when you have found the solution you could reply to this guy as well. He's waiting for a reply since a year ..... ;)
http://originaltrilogy.com/topic/Shifting-interlaced-field-updown-in-After-Effects/id/48703

Well, his problem seems to be that all fields are swapped. Then that wouldn't be very difficult to fix.

I have not been tracking this thread, however,
Rather than using Conditional Reader or RemapFrameSimple, you could try SawBones/FrameSurgeon combo, you can create the frames file
in VirtualDub with Sawbones running, on a particular key press will enter frame number / range (as eg 'FX1 n' or 'FX1 s,e') into a frames file, easier than creating frame file by hand. (CTRL/1 = frame number, (CTRL/SHIFT/1 = range).

In accordance with both of your replies, a semi-automatic solution is probably the most accurate for this clip since frames with swapped fields seem to be only a few (as I said in #16).
However, does AviSynth count dropped frames?

Thanks!

EDIT: Is there a compiled version of SawBones in your MediaFire? You say you're sharing the compiled program but I can't find it. I would like to avoid installing AutoIt.

[LemMotlow]

The problem is compounded, IMO, by either no line tbc or one that isn't doing very much. There are notched and wrinkled borders, ripples, and subtle object shifting left to right in many frames.

Is a line tbc in use, or is this a multigeneration tape source?

[magiblot]

The problem is compounded, IMO, by either no line tbc or one that isn't doing very much. There are notched and wrinkled borders, ripples, and subtle object shifting left to right in many frames.

Is a line tbc in use, or is this a multigeneration tape source?

No TBC was used, and here (https://translate.google.com/translate?sl=es&tl=en&js=y&prev=_t&hl=es&ie=UTF-8&u=http%3A%2F%2Fwww.ociotakus.com%2Fterebikko-una-video-consola-facil-de-utilizar%2F&edit-text=&act=url) you can find some information about the tape's origins (I don't know very much about it).

You can also check the links in post #16 (https://forum.doom9.org/showthread.php?p=1802923#post1802923)and compare which of these problems still persist when playing another tape.

[StainlessS]

Is there a compiled version of SawBones in your MediaFire? You say you're sharing the compiled program but I can't find it. I would like to avoid installing AutoIt.

Oops, think someone musta eaten it, Up on MediaFire and SendSpace now. (AutoIt not needed).

[magiblot]

Oops, think someone musta eaten it, Up on MediaFire and SendSpace now. (AutoIt not needed).

Haha, thanks.

[LemMotlow]

No TBC was used, and here (https://translate.google.com/translate?sl=es&tl=en&js=y&prev=_t&hl=es&ie=UTF-8&u=http%3A%2F%2Fwww.ociotakus.com%2Fterebikko-una-video-consola-facil-de-utilizar%2F&edit-text=&act=url) you can find some information about the tape's origins (I don't know very much about it).
'Nuff said. You appear to be working against yourself.

[magiblot]

'Nuff said. You appear to be working against yourself.

I knew from the beginning this source couldn't be denoised optimally. In fact, my purpose was to fix the IVTC problem and wait for a new rip if there was any chance. I wasn't expecting some of you trying to do a serious restoration. I am very grateful for that, though.

StainlesS, your script works like a charm.

[LemMotlow]

The RF noise seems to be the VCR's fault. It did the same to previous captures from the ripper, although he was using the composite video cable, not RF. You can pick up RF noise thru any cable or electronic device, not just RF wire. I don't know if hat's really RF noise (looks like it) or just bad moire from junk hardware.

I just would like to suggest being careful with IVTC filters. From my experience, most of them get the wrong field pattern. Then, the decimation fails occasionally. It's simplier and faster to use SelectEvery instead, I haven't had any field match problem with it:You will. And plenty. Odd, the only time I've ever had a problem with IVTC that you describe is with your sample.

But since it's an improper capture with poor gear to begin with, I don't see any point in wasting more time with it. A learning experience, though, so thanks for the input, and yet another good case for doing it right or not bothering.

[Sharc]

....I just would like to suggest being careful with IVTC filters. From my experience, most of them get the wrong field pattern. Then, the decimation fails occasionally. It's simplier and faster to use SelectEvery instead, I haven't had any field match problem with it .......
I would have to disagree. If IVTC fails it's always due to butchered sources, means broken sequences due to dropped frames or bad edits leaving orphaned fields etc., or wrong encoding. Selectevery() is a manual workaround trying to fix what has been broken before.

I am not fully convinced that the dropped frames which you got are due to the tape or VCR. Maybe, but more often I have found the cause being on the PC side: Temporary CPU overload due to some background processes (e.g. ambitious virus scanners) or a congestion in the data transfer to the HardDisk. Other typical reasons are desynched voice and video which the capturing software tries to correct by inserting (duplicating) or dropping video frames. It is normally better to dynamically adjust the audio sampling rate. VDub has a setting for this. So keep an eye on the capturing process.

You may also want to re-capture the broken sections only and see whether the flaw is systematic for the particular frames (indicating a source or VCR problem), otherwise replace the faulted frames by healthy ones e.g. using stainless's script and be careful not to break the telecine pattern.

At the end, if nothing helps use a good bobber (e.g. QTGCM) and be done with it, or if you want 23.976fps and like this better, try
QTGMC().srestore(frate=24/1.001)

[magiblot]

I would have to disagree. If IVTC fails it's always due to butchered sources, means broken sequences due to dropped frames or bad edits leaving orphaned fields etc., or wrong encoding. Selectevery() is a manual workaround trying to fix what has been broken before.

I am not fully convinced that the dropped frames which you got are due to the tape or VCR. Maybe, but more often I have found the cause being on the PC side: Temporary CPU overload due to some background processes (e.g. ambitious virus scanners) or a congestion in the data transfer to the HardDisk. Other typical reasons are desynched voice and video which the capturing software tries to correct by inserting (duplicating) or dropping video frames. It is normally better to dynamically adjust the audio sampling rate. VDub has a setting for this. So keep an eye on the capturing process.

You may also want to re-capture the broken sections only and see whether the flaw is systematic for the particular frames (indicating a source or VCR problem), otherwise replace the faulted frames by healthy ones e.g. using stainless's script and be careful not to break the telecine pattern.

At the end, if nothing helps use a good bobber (e.g. QTGCM) and be done with it, or if you want 23.976fps and like this better, try
QTGMC().srestore(frate=24/1.001)

Now that you mention bobbing, I tried that before field matching, and I found srestore would not work well either. So, you must be right, the source is somehow butchered. Is it the encoding's fault? I can't tell, I thought Lagarith was good for this. But I didn't know about dynamic audio sampling rate, so I'll use it from now on.

Appearently, the ripper's computer is good, and the capture card too. However, his hard drive is filled to the top. I'll warn him next time.
There are lots of dropped frames at the beginning of this sample (http://kiddocabbusses.tryhappy.net/TestCapture2.avi), which was recorded before the animation I have been treating in this thread. He told me that they would drop at the same time whenever he re-recorded that scene. If we consider the strong noise in the animation is caused by the VCR, and then what happened in this experience, it can be supposed that its circuitry has problems and is probably messing fields and outputting invalid signal at times, which the capture card refuses. I could be wrong.

Thanks for your advice.

[TheFluff]

Please don't backseat moderate. If you think it's a rule violation, report the post and move on.

[magiblot]

Agreed 1000%
A line tbc that works would help, too.

I spent two cups of coffee on a rework and did what I could. Still a lot of work left, so don't bother with the details but you haven't set legal levels for capture.
And where did all that skittish RF noise come from? Anyway, for what it's worth....
sample3_rework.mp4 (~80MB) https://www.mediafire.com/?8d8g8hkad4s9e7s

Lem, what did you use to correct chroma bleeding?

[LemMotlow]

Lem, what did you use to correct chroma bleeding?A very old oldie: FixChromaBleeding()
http://avisynth.nl/index.php/FixChromaBleeding

Followed by old standbys MergeChroma(awarpSharp2(depth=20)) and ChromaShift.
I followed those with a very light increase in overall re-saturation with SmoothTweak.

Never did clear the edge ghosts entirely. I used FixVHSOverSharp (http://avisynth.nl/index.php/External_filters#Ghost_Removal) followed by two layers of VirtualDub's exorcist filter,
one dark, one light. I don't think there's a really neat de-ghost filter these days.

Big mistake was adding NeatVideo as the last step. Did more harm than good. Dfttest should have been enough.
But you don't notice that sort of thing until you go back to it 2 days later. Staring for a long time plays tricks on you.

[magiblot]

A very old oldie: FixChromaBleeding()
http://avisynth.nl/index.php/FixChromaBleeding

Followed by old standbys MergeChroma(awarpSharp2(depth=20)) and ChromaShift.
I followed those with a very light increase in overall re-saturation with SmoothTweak.

Never did clear the edge ghosts entirely. I used FixVHSOverSharp (http://avisynth.nl/index.php/External_filters#Ghost_Removal) followed by two layers of VirtualDub's exorcist filter,
one dark, one light. I don't think there's a really neat de-ghost filter these days.

Big mistake was adding NeatVideo as the last step. Did more harm than good. Dfttest should have been enough.
But you don't notice that sort of thing until you go back to it 2 days later. Staring for a long time plays tricks on you.

Hahaha, you are right. Thanks for the explanation.

[magiblot]

Chroma looks plenty of horizontal lines after field matching. Am I doing something wrong? (Colorspace is YUY2)

http://i.imgur.com/lgtGEnI.png