digitalFAQ.com Forum - Field order fix?

digitalFAQ.com Forum (https://www.digitalfaq.com/forum/)

- Capture, Record, Transfer (https://www.digitalfaq.com/forum/video-capture/)

- - Field order fix? (https://www.digitalfaq.com/forum/video-capture/10421-field-order-fix.html)

Field order fix?

Sometimes I have this weird error when transferring tapes. I'm recording top field first because my capture device (IO-DATA GV-USB2) records TFF. I'm playing tapes on my 30000u D-VHS deck. Every once in a while it looks like the field order gets all messed up, it ends up being jumpy in some parts and it plays back normal on most parts. It's probably hard to explain, it's kind of like a field order change in on DVD?

Example vid is attached.

I can change AssumeTFF to AssumeBFF in Avisynth but then most of the video gets jumpy because of the wrong field order (the parts that were jumpy before played back fine though).

Is there any easy way to fix this in Avisynth? Before I was able to trim and group stuff but that takes way too much time.

Hi not sure if this works but i did work for me on Pal vhs tape

Code:

AssumeTFF().TFM(1,mode=0,pp=0,micmatching=0)

ops sorry nevermind i was to fast to post it was not the same thing that i did have on my vhs tape

Quote:

Originally Posted by jjdd (Post 67214)

Hi not sure if this works but i did work for me on Pal vhs tape

Code:

AssumeTFF().TFM(1,mode=0,pp=0,micmatching=0)

thanks but it made it worse lol

edit: changing the first 1 to 0 did help a little, but it hasn't gotten rid of it completely

yes sorry about that i don't know what i was thinking hehe

Was not able to load the h264 encoded .mkv file in my Avisynth setup with a DirectShowSource call, so cannot analyze it frame by frame to see if it is what I think it might be. But I'll proceed anyway, and maybe this helps...

I think I see some jump/jitter of frames around the 15 second mark. It could be what I often experience even with or without both kinds of TBC and even after playing with tracking adjustments, just plain old timing glitches on the tape that are not perfectly undone in hardware.

I've written an Avisynth function to help undo effects of a frame (both even and odd fields together) and/or a field (even or odd) jittering by one or more rows. I think a post from sanlyn provided most of the idea, and I just found it so useful I had to keep it in my toolbox. Perhaps it can be applied in your case. The only caveat is that it is time intensive. If you have a lot of frames, this will be slow going, and maybe time/cost prohibitive at some point. It also leaves some blank rows at the top or bottom of the frame. Of course, you can mask the frame borders to hide this, if you chose. Or use some clever copying of select rows and columns in Avisynth to cover them up with a prior or later frame's rows/columns from the same area if there is no motion.

Here's a link to a prior post with the function. Read from second paragraph onward. http://www.digitalfaq.com/forum/vide...html#post64626

Or if you think that using the AssumeTFF and AssumeBFF would fix things, I think you could combine blocks of frames together with something like AssumeTFF(trim(0,100)) ++ AssumeBFF(trim(101,110)) ++ AssumeTFF(trim(111,0)). Untested code, just thinking in avisynth. Hopefully enough to get the idea across.

Or there are posts on the forum you can search for and read about an avisynth plugin named stabmod that tries to stabilize shaky video.

Not sure if this is your problem, just taking a shot in the dark. :)

Quote:

Originally Posted by keaton (Post 67230)

Try loading it in FFMpegSource.

Quote:

Originally Posted by keaton (Post 67230)

I think I see some jump/jitter of frames around the 15 second mark. It could be what I often experience even with or without both kinds of TBC and even after playing with tracking adjustments, just plain old timing glitches on the tape that are not perfectly undone in hardware.

I've never had this problem with my old standard Quasar.

Quote:

Originally Posted by keaton (Post 67230)

I've written an Avisynth function to help undo effects of a frame (both even and odd fields together) and/or a field (even or odd) jittering by one or more rows. I think a post from sanlyn provided most of the idea, and I just found it so useful I had to keep it in my toolbox. Perhaps it can be applied in your case. The only caveat is that it is time intensive. If you have a lot of frames, this will be slow going, and maybe time/cost prohibitive at some point. It also leaves some blank rows at the top or bottom of the frame. Of course, you can mask the frame borders to hide this, if you chose. Or use some clever copying of select rows and columns in Avisynth to cover them up with a prior or later frame's rows/columns from the same area if there is no motion.

Here's a link to a prior post with the function. Read from second paragraph onward. http://www.digitalfaq.com/forum/vide...html#post64626

Or if you think that using the AssumeTFF and AssumeBFF would fix things, I think you could combine blocks of frames together with something like AssumeTFF(trim(0,100)) ++ AssumeBFF(trim(101,110)) ++ AssumeTFF(trim(111,0)). Untested code, just thinking in avisynth. Hopefully enough to get the idea across.

Or there are posts on the forum you can search for and read about an avisynth plugin named stabmod that tries to stabilize shaky video.

Not sure if this is your problem, just taking a shot in the dark. :)

Yeah, that's really time intensive. :hmm:

Need a sample of the capture, not the deinterlaced & upscaled version.

My guess is that when this happens, 1 field is being Dropped or Inserted, but I don't know what the cause would be.

Quote:

Originally Posted by msgohan (Post 67268)

Need a sample of the capture, not the deinterlaced & upscaled version.

Attached.

Quote:

Originally Posted by msgohan (Post 67268)

My guess is that when this happens, 1 field is being Dropped or Inserted, but I don't know what the cause would be.

In my opinion, I don't think so. I remember having this problem before and it showed up when it was outputting component as well, through my TV.

When this sample switches back from wrong field order to correct, there is always a Near Dupe that serves as a "catch-up" to bring the fields back in order. You need to compare Evens to Evens to see this, since there is a non-dupe Odd in between.

Because these are Near Dupes and not Perfect Dupes, the problem is occurring prior to the capture device. (If the capture device were to blame, the dupes should be 1:1 copies with 0 noise.) You basically already confirmed that the VCR's internal digitization is to blame, so this is just more evidence. I have no idea why it would do this.

The presence of these field dupes suggests corresponding field drops when the sample switches to wrong field order, but this can't really be demonstrated without a corresponding correct reference capture.

Code:

AVISource("weird error segment-2.avi")



AssumeTFF().SeparateFields()



SelectEven().TDecimate(mode=4,display=true)

I also checked with SelectOdd; there are no Near Dupes among the Odds.

JPEGs showing TDecimate difference measurements under 0.5:
Attachment 11465
Attachment 11466
Attachment 11467
Attachment 11468

PNGs of fields 464 & 466 (equivalent to Even Field 233 above):
Attachment 11469
Attachment 11470

Even Field 162 (the first image in this post) is actually during a still frame, but the difference between the intentionally-duplicated fields coming from the tape and the wrongly-duplicated Near Dupe is obvious nevertheless. If you look closely enough at your video sample, you can see tape noise, head-switching noise, imperfect line TBC, etc. and this causes the other still fields' metrics to measure above 1.5.

All times are GMT -5. The time now is 08:15 PM