IO Data GV-USB2 + Panasonic ES15 sample

[boolian2]

Compressed with Handbrake NVENC H265, Decomb deinterlace filter

[jagabo]

The display aspect ratio is wrong. It should be 4:3. Levels are bad. Saturation is probably wrong, though it's hard to tell since it's only a night shot. Every 5th frame is a duplicate -- you should have inverse telecined rather than deinterlacing. At least the horizontal time base is clean.

This is a little closer to what the video should have looked like:

[Sharc]

@boolean2
This has all been discussed and explained to you in your other threads (IVTC, Aspect Ratio, Levels ....). Just take a look there.

[boolian2]

@boolean2
This has all been discussed and explained to you in your other threads (IVTC, Aspect Ratio, Levels ....). Just take a look there.

Ok thanks I just wanted to post another sample capture. The ES15 really cleans up the signal. Still learning about how to process the capture and what software/filters to use. Big learning curve. Also I thought IVTC didn't need to be used on animation

Is this ghosting when paused normal?


[Attachment 65646 - Click to enlarge]

[jagabo]

Still learning about how to process the capture and what software/filters to use. Big learning curve.

Which is why you need to start at the beginning -- getting good captures. Posting highly processed clips makes it impossible to tell what problems are in the source, what problems are due to a bad cap, and what problems are due to your processing of the video. Upload samples compressed with a lossless codec like Lagarith or UT Video Codec. Include medium speed panning shots and a variety of dark and bright frames with good color saturation.

Also I thought IVTC didn't need to be used on animation

Like movies, almost all animation starts out as 24p. To be broadcast as interlaced video it has to be telecined to 59.94 fields per second (usually captured as 29.97 interlaced frames per second). In the optimal case you can restore the 24p frames from the telecined video.

Is this ghosting when paused normal?

Paused by what? The VCR? The capture program? In a mediaplayer or editor before processing? After your processing? I suspect you have a PAL to NTSC conversion with blended fields. Blending is "normal" with those but can often be eliminated with the proper processing. The ES15's noise reduction feature can cause that type of blending too (turn it off). But your sample is too far divorced from the NTSC tape to say for sure where the problem lies.

[davexnet]

Depends what you mean by normal. It's obviously two frames blended, and a look at the capture source
should provide some clues about what can be done.

NTSC (29.97 fps) can certainly be telecined from 24 frames per second, it goes through the 3:2 pulldown,
just like regular Hollywood movies shot on film

[boolian2]

Here's an original unprocessed capture of the scene from AmarecTV

[boolian2]

Still learning about how to process the capture and what software/filters to use. Big learning curve.

Which is why you need to start at the beginning -- getting good captures. Posting highly processed clips makes it impossible to tell what problems are in the source, what problems are due to a bad cap, and what problems are due to your processing of the video. Upload samples compressed with a lossless codec like Lagarith or UT Video Codec. Include medium speed panning shots and a variety of dark and bright frames with good color saturation.

Also I thought IVTC didn't need to be used on animation

Like movies, almost all animation starts out as 24p. To be broadcast as interlaced video it has to be telecined to 59.94 fields per second (usually captured as 29.97 interlaced frames per second). In the optimal case you can restore the 24p frames from the telecined video.

Is this ghosting when paused normal?

Paused by what? The VCR? The capture program? In a mediaplayer or editor before processing? After your processing? I suspect you have a PAL to NTSC conversion with blended fields. Blending is "normal" with those but can often be eliminated with the proper processing. The ES15's noise reduction feature can cause that type of blending too (turn it off). But your sample is too far divorced from the NTSC tape to say for sure where the problem lies.

Paused in Media Player Classic. All my tapes and my VCR/ES15 are NTSC, no PAL. The IO DATA is set to NTSC.

update: I found the DNR setting and turned it Off. It was set to Automatic.

[boolian2]

Here is an unprocessed capture with ES15's noise reduction turned Off.

And also the capture IVTC'd with avisynth.

Just noticed something weird, it looks like it's still interlaced in one spot on the IVTC'd version

[Attachment 65650 - Click to enlarge]

[Sharc]

The regular 2-3 telecine pattern is partially broken in your .avi capture. I don't know at which stage this happened (source editing or capture process ....)
It may be better (?) to just deinterlace this source

assumeTFF()
QTGMC()
crop(8,0,-8,-0)
bilinearresize(640,480)  #for square pixels

[jagabo]

The amarec cap in post #9 is getting better. Chroma blending in the earlier posts was caused by the ES15's NR filter. The luma blending was caused by bad post processing. Levels are still bad. The picture is stuck on one frame for the first ~4 seconds (was the VCR paused?).

The problem Sharc saw is that the video swaps field positions every now and then. The top drops below the bottom field. I believe this is an issue with the capture device, not the tape or ES15. I've seen other caps with that device with the same problem. It's only in the first 8 seconds or so -- so maybe it just takes that long for the capture device to lock onto the signal.

I've only addressed the IVTC here...

LWLibavVideoSource("amarec(20220629-2054).avi", format="YUY2") 
AssumeTFF()

n = TFM(clip2=QTGMC(FPSDivisor=2)) # normal field matching
s = TFM(Crop(0,0,-0,-1).AddBorders(0,1,0,0).AssumeBFF().SwapFields(), clip2=QTGMC(FPSDivisor=2)) # field matching after swapping field positions

ncombs = n.Crop(8,8,-8,-8).ConvertToYV12().FindCombing(0) # look for combing in n
scombs = s.Crop(8,8,-8,-8).ConvertToYV12().FindCombing(0) # look for combing in s
morecombs = Subtract(scombs, ncombs) # which has more combing?
ConditionalFilter(morecombs, s.Subtitle("s"), n.Subtitle("n"), "AverageLuma()", "LessThan", "126.0") # pick the frame with the least combing
TDecimate()

You would remove the Subtitle() calls in your final video, of course. But it's instructive to see them here.

[Alwyn]

Chroma blending in the earlier posts was caused by the ES15's NR filter.

Without intending to go off-topic, in your experience Jagabo, is it better to leave this off for all captures (I have a PAL version)?

[jagabo]

Chroma blending in the earlier posts was caused by the ES15's NR filter.

Without intending to go off-topic, in your experience Jagabo, is it better to leave this off for all captures (I have a PAL version)?

Yes, leave it off. You can get much better noise reduction in software, especially with AviSynth or VapourSynth (though I can't help you with the latter).

[Sharc]

The problem Sharc saw is that the video swaps field positions every now and then. The top drops below the bottom field. I believe this is an issue with the capture device, not the tape or ES15. I've seen other caps with that device with the same problem. It's only in the first 8 seconds or so -- so maybe it just takes that long for the capture device to lock onto the signal.

Ah yes, the darn fields position swapping. Ugly, if this is a problem which pertains to this capture device.
@boolian2: Did you capture via S-video or Composite? Is the problem repeatable? I am also wondering about the initial stucking of the video.

[boolian2]

The problem Sharc saw is that the video swaps field positions every now and then. The top drops below the bottom field. I believe this is an issue with the capture device, not the tape or ES15. I've seen other caps with that device with the same problem. It's only in the first 8 seconds or so -- so maybe it just takes that long for the capture device to lock onto the signal.

Ah yes, the darn fields position swapping. Ugly, if this is a problem which pertains to this capture device.
@boolian2: Did you capture via S-video or Composite? Is the problem repeatable? I am also wondering about the initial stucking of the video.

S-Video. No composite. I will do some more tests.

[DB83]

I have been away for some days.But why do we need yet another topic about this ? (true that the previous one drifted somewhat but once we have several topics one never really knows which one to reply to)

[boolian2]

S-video capture

vdubbed version also attached

[jagabo]

I didn't notice any field flips in the 1026 video. A simple TFM().TDecimate() should work.

But why are there dot crawl artifacts all over the video if you're using s-video?

[boolian2]

I didn't notice any field flips in the 1026 video. A simple TFM().TDecimate() should work.

But why are there dot crawl artifacts all over the video if you're using s-video?

I think that's just part of the animation? Not sure, I haven't seen it on any other tape so far. Maybe the tape is damaged

[Sharc]

@boolian2: Same doubt here about the dotcrawl which you didn't have in your previous captures. Has anything changed in your configuration? Are you using S-Video throughout, i.e. from VCR to ES15 and from ES15 to the GV-USB2 dongle? Did you disconnect all Composite cables?
Any sharpeners ON in the VCR or ES15? Is your source an original tape or a dubbed version?

[boolian2]

@boolian2: Same doubt here about the dotcrawl which you didn't have in your previous captures. Has anything changed in your configuration? Are you using S-Video throughout, i.e. from VCR to ES15 and from ES15 to the GV-USB2 dongle? Did you disconnect all Composite cables?
Any sharpeners ON in the VCR or ES15?

All S-Video. VCR -svideo- ES15 -svideo- GVUSB2 - computer. Composite isn't connected to anything. Could an old Monster S-Video cable be causing any issues? I bought it brand new, unopened but I think it was made over a decade ago. The other S-Video cable is new. I will double check later but VCR is set to Normal, not Sharp. Tape is original.

[Sharc]

Could an old Monster S-Video cable be causing any issues?

Poor or missing wire screens could produce crosstalk between the luma and chroma wires (capacitive Y-C coupling). Cheap S-Video cables with poor shielding do have crosstalk problems. Just wondering why it didn't materialize for the other tapes. Maybe just less saturated colors. Weird.

[jagabo]

The chroma carrier is a high frequency sinusoidal wave. The phase of the wave determines the hue, the amplitude of the wave is the saturation. So the more saturated the colors the higher the amplitude of the carrier and the more crosstalk you can get. The brghtness of the picture also makes a difference. The earlier caps uploaded here had very subdued color and very dark pictures so they didn't show much leakage.

[DB83]

I am probably way off the scale here but vdub2 reports the OP's UT captures as Rec 709. Surely they should be Rec 601 ?

[davexnet]

Some noise reduction using checkmate and temporaldegrain (Avisynth)

[boolian2]

Here are my VCR settings

[Attachment 65666 - Click to enlarge]

[Attachment 65667 - Click to enlarge]

[Sharc]

I am probably way off the scale here but vdub2 reports the OP's UT captures as Rec 709. Surely they should be Rec 601 ?

Yes, the wrong codec was selected for SD video. Should be the 'UTVideo YUV422 BT.601' variant of the UTVideo codec suite, with the FOURCC code ULY2 instead of ULH2.
(This applies to the OP's previous captures as well, b.t.w.)

[DB83]

Yes. I did notice. But just wondered if that had an influence in the final output. There appeared a change when I forced vdub2 output preview to Rec 601 (not for the better I might add)

Maybe the OP needs to do another live-action sample, but this time with more day-light (even from TSOM) to see if the cross-talk is then present. I previoulsy had some with my usb-live which 'suddenly' vanished and with no correction on my part.


'Old man' comment coming up. Surely there have to be composite connections for the audio regardless of the s-video ?

[boolian2]

I am probably way off the scale here but vdub2 reports the OP's UT captures as Rec 709. Surely they should be Rec 601 ?

Yes, the wrong codec was selected for SD video. Should be the 'UTVideo YUV422 BT.601' variant of the UTVideo codec suite, with the FOURCC code ULY2 instead of ULH2.
(This applies to the OP's previous captures as well, b.t.w.)

My bad. I changed it to ULY2. Here is a new capture using ULY2.

[DB83]

Is it my eyes but those artifacts are not present in the later sample.

But something, as I suggested, in good day-light may provide better analysis.