Quantcast Field order fix? - digitalFAQ Forum
  #1  
03-09-2020, 05:11 PM
ENunn ENunn is offline
Free Member
 
Join Date: May 2018
Location: Henderson, KY
Posts: 42
Thanked 2 Times in 2 Posts
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.


Attached Files
File Type: mkv example3920-1.mkv (35.20 MB, 14 downloads)
Reply With Quote
Someday, 12:01 PM
admin's Avatar
Ads / Sponsors
 
Join Date: ∞
Posts: 42
Thanks: ∞
Thanked 42 Times in 42 Posts
  #2  
03-09-2020, 05:27 PM
jjdd jjdd is offline
Free Member
 
Join Date: Jul 2012
Posts: 137
Thanked 6 Times in 6 Posts
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
Reply With Quote
  #3  
03-09-2020, 05:29 PM
ENunn ENunn is offline
Free Member
 
Join Date: May 2018
Location: Henderson, KY
Posts: 42
Thanked 2 Times in 2 Posts
Quote:
Originally Posted by jjdd View Post
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
Reply With Quote
  #4  
03-09-2020, 06:02 PM
jjdd jjdd is offline
Free Member
 
Join Date: Jul 2012
Posts: 137
Thanked 6 Times in 6 Posts
yes sorry about that i don't know what i was thinking hehe
Reply With Quote
  #5  
03-10-2020, 07:38 PM
keaton keaton is offline
Premium Member
 
Join Date: Jan 2017
Location: USA
Posts: 160
Thanked 77 Times in 54 Posts
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. Questions regarding TBC, audio/video sync drift and software

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.
Reply With Quote
  #6  
03-10-2020, 08:14 PM
ENunn ENunn is offline
Free Member
 
Join Date: May 2018
Location: Henderson, KY
Posts: 42
Thanked 2 Times in 2 Posts
Quote:
Originally Posted by keaton View Post
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...
Try loading it in FFMpegSource.

Quote:
Originally Posted by keaton View Post
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 View Post
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. Questions regarding TBC, audio/video sync drift and software

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.
Reply With Quote
  #7  
03-12-2020, 11:45 PM
msgohan msgohan is offline
Free Member
 
Join Date: Feb 2011
Location: Vancouver, Canada
Posts: 1,323
Thanked 329 Times in 274 Posts
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.
Reply With Quote
  #8  
03-13-2020, 12:47 AM
ENunn ENunn is offline
Free Member
 
Join Date: May 2018
Location: Henderson, KY
Posts: 42
Thanked 2 Times in 2 Posts
Quote:
Originally Posted by msgohan View Post
Need a sample of the capture, not the deinterlaced & upscaled version.
Attached.

Quote:
Originally Posted by msgohan View Post
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.


Attached Files
File Type: avi weird error segment-2.avi (75.02 MB, 4 downloads)
Reply With Quote
  #9  
03-17-2020, 12:17 AM
msgohan msgohan is offline
Free Member
 
Join Date: Feb 2011
Location: Vancouver, Canada
Posts: 1,323
Thanked 329 Times in 274 Posts
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:
weird error segment-2 EvenFields f162.jpg
You must be logged in to view this content; either login or register for the forum. The attached screen shots, before/after images, photos and graphics are created/posted for the benefit of site members. And you are invited to join our digital media community.

weird error segment-2 EvenFields f233.jpg
You must be logged in to view this content; either login or register for the forum. The attached screen shots, before/after images, photos and graphics are created/posted for the benefit of site members. And you are invited to join our digital media community.


PNGs of fields 464 & 466 (equivalent to Even Field 233 above):
weird error segment-2 EvenFields f249.jpg
You must be logged in to view this content; either login or register for the forum. The attached screen shots, before/after images, photos and graphics are created/posted for the benefit of site members. And you are invited to join our digital media community.


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.


Reply With Quote
Reply




Similar Threads
Thread Thread Starter Forum Replies Last Post
New discovery in video capture field? latreche34 General Discussion 11 07-10-2019 02:15 PM
Determining field order of captured HuffYUV AVI? nicholasserra Capture, Record, Transfer 18 02-04-2018 12:04 AM
Trouble with Premiere Elements widescreen interlace field order - TFF or BFF? GreenAcres Edit Video, Audio 4 07-25-2014 07:40 AM
Please help to persuade VLC to fix field order metaleonid General Discussion 2 10-02-2013 05:33 PM
Field Dominance / Field Order (Top or Bottom) deter Encode, Convert for discs 1 12-18-2011 10:35 PM

Thread Tools



 
All times are GMT -5. The time now is 03:54 AM