03-09-2020, 05:11 PM
|
|
Free Member
|
|
Join Date: May 2018
Location: Henderson, KY
Posts: 52
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.
|
Someday, 12:01 PM
|
|
Ads / Sponsors
|
|
Join Date: ∞
Posts: 42
Thanks: ∞
Thanked 42 Times in 42 Posts
|
|
|
03-09-2020, 05:27 PM
|
|
Free Member
|
|
Join Date: Jul 2012
Posts: 159
Thanked 15 Times in 15 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
|
03-09-2020, 05:29 PM
|
|
Free Member
|
|
Join Date: May 2018
Location: Henderson, KY
Posts: 52
Thanked 2 Times in 2 Posts
|
|
Quote:
Originally Posted by jjdd
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
|
03-09-2020, 06:02 PM
|
|
Free Member
|
|
Join Date: Jul 2012
Posts: 159
Thanked 15 Times in 15 Posts
|
|
yes sorry about that i don't know what i was thinking hehe
|
03-10-2020, 07:38 PM
|
|
Premium Member
|
|
Join Date: Jan 2017
Location: USA
Posts: 184
Thanked 85 Times in 60 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. 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.
|
03-10-2020, 08:14 PM
|
|
Free Member
|
|
Join Date: May 2018
Location: Henderson, KY
Posts: 52
Thanked 2 Times in 2 Posts
|
|
Quote:
Originally Posted by keaton
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
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
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.
|
03-12-2020, 11:45 PM
|
|
Free Member
|
|
Join Date: Feb 2011
Location: Vancouver, Canada
Posts: 1,323
Thanked 334 Times in 276 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.
|
03-13-2020, 12:47 AM
|
|
Free Member
|
|
Join Date: May 2018
Location: Henderson, KY
Posts: 52
Thanked 2 Times in 2 Posts
|
|
Quote:
Originally Posted by msgohan
Need a sample of the capture, not the deinterlaced & upscaled version.
|
Attached.
Quote:
Originally Posted by msgohan
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.
|
03-17-2020, 12:17 AM
|
|
Free Member
|
|
Join Date: Feb 2011
Location: Vancouver, Canada
Posts: 1,323
Thanked 334 Times in 276 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.
|
All times are GMT -5. The time now is 08:09 PM
|