Capture issues?

[SVAPrjm]

I captured the the linked video on an IO Data gvUSB2 capture card through Vdub64 and am getting this wobbly issue across the frame and I don't know where it's coming from. Captured through SVideo. Capture is weave(off) 29.97 to a lossless avi. Is there something in the settings that I might have missed that is causing this?

https://drive.google.com/drive/folders/17A173fHS4L1h-WL05dPgvpucnXtuKKuP?usp=drive_link

[Sharc]

I am not willing to download 600MB, but here some hints how to prevent wobbling:
- Use a decent VCR with internal TBC (Time Base Corrector)
- or use a DVD recorder in passthrough

Search the forum. Many posts dealing this this.

[dellsam34]

Those appear to be worse than line timing errors, The first test you do in the process of elimination is to pause the tape during playback, If the wiggle continues to move then it's line timing errors that your capture card is too sensitive to, in that case use a form of TBC correction. If the wiggle freezes or greatly reduced and wiggles less then the artifact is baked in the tape and there is nothing you can do about it.
Note: Some capture cards cannot show an image from the VCR if you hit pause and default to blue screen, so you may need to use a regular TV for that.

[SVAPrjm]

Cool thank you both. Is TBC in the capture program settings or in the VCR itself?

[Sharc]

Cool thank you both. Is TBC in the capture program settings or in the VCR itself?

It's a function/setting in the VCR. Usually only available with high-end S-VHS models.

[SVAPrjm]

Yeah, my VCR is SVHS, JVC HR3901. I just don't have a remote for it.

[jagabo]

A line time base corrector should take care of the horizontal wiggle. The top fields are all full of chroma noise. The two fields stacked rather than woven:


[Attachment 86717 - Click to enlarge]

[SVAPrjm]

A line time base corrector should take care of the horizontal wiggle. The top fields are all full of chroma noise. The two fields stacked rather than woven:


[Attachment 86717 - Click to enlarge]

Can anything be done about the top fields? Deinterlace TFF and drop those frames?

[Sharc]

You can in principle:
- Easiest: Apply a chroma denoising filter (interlace aware)
- Filter even and odd fields differently (cleaning the bad field) -> may cause flicker
- Base rate deinterlace, using the healthy field only for spatial interpolation -> Loosing motion fluidity.
- More complicated: Substitute the bad fields by temporal interpolated healthy fields -> May introduce interpolation artifacts.

All can be done in Avisynth, some in VirtualDub.
Choose your poison.

P.S. Checking the manual quickly: I don't think your VCR has TBC.

[jagabo]

I didn't see anything about time base correction in the manual either. Use a Panasonic DVD recorder, like the ES10 or ES15 in passthrough for horizontal time base correction.

The chroma noise is probably something wrong with one head of the VCR. It would be best to fix that first. But here it's fixed by replacing the top field's chroma with a motion interpolated version of the bottom field's chroma.

[SVAPrjm]

I didn't see anything about time base correction in the manual either. Use a Panasonic DVD recorder, like the ES10 or ES15 in passthrough for horizontal time base correction.

The chroma noise is probably something wrong with one head of the VCR. It would be best to fix that first. But here it's fixed by replacing the top field's chroma with a motion interpolated version of the bottom field's chroma.

what is the script you used to replace with a motion interpolated version of the bottom field?

[dellsam34]

One field being noisy is a good indication of bad video head of the recording machine or the playback machine.

[jagabo]

what is the script you used to replace with a motion interpolated version of the bottom field?

I used:

function DoubleFPS_RIFE(clip source)
{ 
    source.z_ConvertFormat(pixel_type="RGBPS", colorspace_op="709:709:709:l=>rgb:709:709:f")
    Rife(model=5, sc=false)
    z_ConvertFormat(pixel_type=source.pixeltype, colorspace_op="rgb:709:709:f=>709:709:709:l")
}

LWLibavVideoSource("Copy of input.avi") 
AssumeTFF()
ColorYUV(off_y=-20)
SeparateFields()
e = selectEven()
o = SelectOdd()
i = DoubleFPS_RIFE(o.AssumeFrameBased()).SelectOdd().Loop(2,0,0)
e = MergeChroma(e, i)
Interleave(e,o)
Weave()
QTGMC()
prefetch(8)

Instead of DoubleFPS_RIFE() you can use any other motion interpolating frame rate doubler. Like InterFrame(), FrameRateConverter(), SVPFlow(), etc. RIFE usually works best though.

[Sharc]

@jagabo: Nice, keeping the luma and substituting the bad chroma only.
Shouldn't the colorsapce_op=...... be 601 for the OP's SD video?

so something like:

function DoubleFPS_RIFE(clip source)
{ 
    source.z_ConvertFormat(pixel_type="RGBPS", colorspace_op="601:auto:auto:l=>rgb:same:same:f")
    Rife(model=5, sc=false)
    z_ConvertFormat(pixel_type=source.pixeltype, colorspace_op="rgb:auto:auto:f=>601:same:same:l")
}

[jagabo]

@jagabo: Nice, keeping the luma and substituting the bad chroma only.
Shouldn't the colorsapce_op=...... be 601 for the OP's SD video?

so something like:

function DoubleFPS_RIFE(clip source)
{ 
    source.z_ConvertFormat(pixel_type="RGBPS", colorspace_op="601:auto:auto:l=>rgb:same:same:f")
    Rife(model=5, sc=false)
    z_ConvertFormat(pixel_type=source.pixeltype, colorspace_op="rgb:auto:auto:f=>601:same:same:l")
}

Technically, yes. But it's a round trip form 601 to RGBPS and back so there's not much difference. The RGBPS colors will be wrong but the original 601 colors will be restored on the way back.