GV-USB2 reports more dropped and inserted frames than the DVC100 and VC500

[Bwaak]

I am playing a tape on a camcorder with built-in TBC. The left edge is rock solid, the right edge is ever slightly jittery. Capturing with the VDub2 (if you are going to suggest to use 1.9.11 then explain, how exactly this is going to help).

With the DVC100 I easily get zero dropped or inserted frames, but I see that the Resample number (what does it mean?) is within ±0.00005 from 1, audio sync error is ±20 ms for composite, ±5 for SVideo, no audible A/V desync.

With the VC500 I have 2 frames inserted in the beginning, and no new dropped or inserted frames.

With the GV-USB2 I have 3 frames inserted in the beginning, then frames are dropped and inserted almost in equal numbers, about one per second (one dropped and one inserted).

How exactly the card determines a dropped frame? I assume, it expects video to come regularly, and if the video is slightly off compared to the built-in clock, then the card registers a dropped or an inserted frame? Mind you, the built-in TBC is on, and the picture looks quite stable. I'll post samples later, I am just wondering about how dropped and inserted frames are generated/counted.

Does anyone have similar experience?

After playing the same segment several times and capturing it with the GV-USB2, I managed to get just 4 dropped frames in a 3-minute capture (3 dropped at the beginning, and 1 dropped sometime in the middle). So, it looks like this is related to the playback machine/tape, and I think it confirms my suspicion that the GV-USB2 is too strict regarding timing errors and is not as tolerant to timing errors as the other two dongles. So, it needs to be fronted with a very high-quality TBC?

[Sharc]

How do you check for dropped/inserted frames? Frames can get dropped outside of the capture card/SW which would not be noticed/reported by the capture device.
Use AmarecTV for capturing rather than Vdub2 which is notorious for frame dropping. The log of AmarecTV helps to identify glitches.
Secondly, with VHS analog technology you will never get 2 identical captures with different test runs, not even with the same setup. The analog tape playback process is not reproducible.
For a more reliable comparison the 2 devices would have to be fed simultaneously from the same signal, e.g. by splitting the analog signal into 2 paths and feeding the 2 capture devices simultaneously, means from the same VHS playback run.

[lollo]

Secondly, with VHS analog technology you will never get 2 identical captures with different test runs, not even with the same setup. The analog tape playback process is not reproducible.

While true in general, about overall number of frames captures I experienced that if the tape is in pristine conditions (no defects, no drop-outs, nothing) I obtain exactely the same frames (with 0 inserted and 0 dropped) across 6 captures. I run 6 captures of the same tape to perform "median" processing (x3) with 2 different VCR settings (x2). In addition, for many of my tapes I a have a reference, being a digital dump of the same program, to which I can easily compare for other test purposes, but that's another story.
(BTW, the median processing approach is not effective in the above case, an example here: https://www.youtube.com/watch?v=8NJrxD0I_tU, but even this is another story)

[lordsmurf]

but I see that the Resample number (what does it mean?)

It means your dropping frames, without it being reported as drops. The audio attenuates (chipmunk, Barry White) to adjust to the missing frames. When audio attenuates, it's essentially speeding up then slowing down. Lots of software does this, which is why it's not good for capture.

Dropped frames is not a simple counter in software. There are multiple ways to detect drops, and few users actually understand it. This is why most simple answers to "use this instead" is just nonsense, it's not magic to avoid drops. It's threads/questions like this that reveal user video knowledge.

Mind you, the built-in TBC is on, and the picture looks quite stable.

The line TBC makes it pretty. But the signal can still be unstable. That's what frame TBC ("external" TBC) is for. Line is not frame.

So, it looks like this is related to the playback machine/tape, and I think it confirms my suspicion that the GV-USB2 is too strict regarding timing errors and is not as tolerant to timing errors as the other two dongles. So, it needs to be fronted with a very high-quality TBC?

It's really not any more or less strict, and this is why TBCs are required for quality capturing.

[Sharc]

Dropped frames is not a simple counter in software. There are multiple ways to detect drops, and few users actually understand it. This is why most simple answers to "use this instead" is just nonsense, it's not magic to avoid drops.

Agree. No one expects any magic here. Differences exist though for whatever reason w.r.t frame dropping between various capture SW (Vdub2 vs Vdub 1.9.11 vs AmarecTV vs VirtualVCR ......). The OP was using Vdub2 for his tests as I understood.

[Bwaak]

How do you check for dropped/inserted frames? Frames can get dropped outside of the capture card/SW which would not be noticed/reported by the capture device. Use AmarecTV for capturing rather than Vdub2 which is notorious for frame dropping. The log of AmarecTV helps to identify glitches.

I check the number of dropped and inserted frames, reported by VDub, also I can observe glitches when the video plays.

I wonder why AmarecTV produces fewer dropped frames - any technical reasons for that? Also, am I right in my understanding how VDub counts dropped and inserted frames? Basically, a card expects V-Sync timed to its internal clock. It would report a dropped frame if it does not get a pulse in time, and would report an inserted frame if the pulse comes earlier. Seeing both dropped and inserted frames indicates that V-Sync is not rock stable, right? Since the clock is in the card, not in the software, this count should be produced by the card and the driver, not the capture software. So, how AmarecTV is better?

It seems that the DVC100 allows for some leeway. It seems that the DVC100 - or the combination of the DVC100 with VDub2 - results in the least number of dropped frames - reported as well as noticed visually, while the audio never drifts far away.

For the VC500, no drift is reported, it is always 0, which is suspicious. I think, the card just does not report it. Same for the GV-USB2.

[Sharc]

I check the number of dropped and inserted frames, reported by VDub, ...

These are only those which the the tool detects, and which are normally compensated by inserting a duplicate or by temporarily 'accelerating' the audio in order to keep audio and video in sync. There can be more drops which happen before the signal enters the capture card. The capture tools like Vdub won't report these.

I wonder why AmarecTV produces fewer dropped frames - any technical reasons for that?

We would probably have to ask this question to the designers of the capture SW and the device drivers. It may be related to the 'efficiency' of the drivers and SW, its interaction with the OS and HW. I don't know, maybe someone else has more details. Members here have made their individual experience with their systems and eventually picked the solution which delivered best results. AmarecTV has in general received a high rating (which I can confirm), similar or better than the original Vdub. You may want to try.

[Sharc]

@Bwaak: Any success? Feedback?

[Bwaak]

@Bwaak: Any success? Feedback?

Capturing via VDub2 is unstable. Can be 0 or 4 or 7 or more than a 100 drops/inserts for a four-minute video. Drops/inserts usually come in pairs, which to me indicates tiny inconsistency of V-Sync. AmarecTV consistently reports 0 drops. VDub2 reports zero drops on the same tape using Dazzle DVC 100. Go figure.

I am capturing into Cineform despite having issues with Cineform in Vegas. I am using native Cineform with VDub2. V9.2.1 crashes it. OTOH, I am using V9.2.1 with AmarecTV. There are settings for AR and interlacing, but when I set interlaced to true, AmarecTV crashes. So, I capture as progressive, but then handle it as interlaced, it works.

[APP]
iVersion=300
pcVersion="3.10"
pcBuildDate="Jun 24 2014"
iMemMByte=32653
pcOS="Windows 7 x64"
iProcessorArchitecture=9

[DEVICE]
iUseClock.200=1
pcDevice="GV-USB2, Analog Capture"
pcCrossbar="SVideo"
pcCrossbarAudio="(Link)"
pcTuner=""
pcFormat="*w= 720, h= 480, fps=29.97,  fcc=YUY2, bit=16"
pcDeviceAudio="GV-USB2, Analog Capture"
pcAudioInput=""
pcFormatAudio="*sample= 48000, bit=16, ch= 2"

--------------------------------- Encode  Result ---------------------------------
Compression        : FourCC=CFHD, Description=GoPro CineForm Codec v9.2.1
Setting            : 720*480, 29.97fps
Original Video Size:  4816MByte
Compress video Size:  1230MByte(25%, 1/3.915), 5157KB/s(41262kbps)
Frame count= 7307f, Drp=  0f, Avg Enc=3.955ms, Avg Cmp= 25%

[Sharc]

OK. Thanks. As expected drop Vdub2 for capturing. Maybe too much functionalities and options inherited from the past when audio and video had individual and independent master clocks.

[Skiller]

My understanding is that an inserted frame means a frame could not be digitized by the capture hardware (most often because of a glitch on the tape and a lack of a TBC) and thus the frame right before is repeated by the capture software to fill the gap. The repeated frame is called inserted frame.

A dropped frame on the other hand is a frame which is actually there (was digitized) but gets discarded by the capture software on purpose to keep the audio in sync with the video.

Because it is also possible to deal with both by adjusting the speed of the audio, rather than dropping or inserting a frame, each capture software may handle this differently.

[Bwaak]

My understanding is that an inserted frame means a frame could not be digitized by the capture hardware (most often because of a glitch on the tape and a lack of a TBC) and thus the frame right before is repeated by the capture software to fill the gap. The repeated frame is called inserted frame.

A dropped frame on the other hand is a frame which is actually there (was digitized) but gets discarded by the capture software on purpose to keep the audio in sync with the video.

Because it is also possible to deal with both by adjusting the speed of the audio, rather than dropping or inserting a frame, each capture software may handle this differently.

My understanding is that the capture device has a built-in clock and expects frames to arrive at precise intervals from a VCR. If the frame does not arrive, a frame is generated (inserted) in its place, I suppose it is copied the prior frame... if that happens, this means the converter has a full-frame buffer? If the frame arrives earlier, it is dropped. I am not sure what is the software's role in this, or maybe it is the software that uses the computer's clock and expects timed frames from the converter?

After all, with the GV-USB2 I see no audio drift and no resample in VDub2, but sometimes lots of dropped and inserted frames. With the DVC100 I see minor audio de-sync, but it always returns back to zero, it fluctuates around zero and never increases, I get 2-hour tapes that are sync'd well enough to not being objectionable. With the GV-USB2 and AmarecTV I see frame rate in the bottom of the app fluctuating between 29.xx and 30.xx, which to me indicates uneven rate coming from the device. Why then VDub cannot handle it, but can handle DVC 100? Are DVC 100 fluctuations actually smaller, than the GV-USB2 fluctuations? But for the GV-USB2, VDub reports zero A/V desync and resample value is always 1. I guess, I need to dig deeper.

In any case, for practical purposes, AmarecTV reports zero drops. I need to rewatch the captured samples and visually check the frame consistency.

[Bwaak]

I googled around a bit. Most current info is about smoothing out video for streaming TV and Zoom sessions, as well as about detecting video forgery, not about capturing of analog video. This research paper describes a digital video transmission system, which "typically includes a source encoder, transmission channel and a decoder on the reception side".

Sometimes, the received video contains repeated or frozen frames which are actually the dropped frames. The primary reason for these dropped frames is that sometimes the source encoder reduces the frame rate of the original video in order to save the bandwidth e.g. a video with a frame rate of 25 frames per second (fps) can be downsized to 10 fps. Another reason for this can be that the decoder at the reception side freezes the last correctly received frame until next correct frame is received. The decoder keeps dropping the frames until it receives a correct frame thus creating a series of repeated frames also known as a freeze event. Many network operators use this frame repetition method in the decoders as an error concealment technique.

Translating this for the A/D use case, the encoder can drop frames if they come too quickly. Also, bad frames can be dropped, freezing the prior frame. When they say, "freezing a frame", does this mean repeating a frame, or does it mean that a frame can have individual duration? I guess in case of VFR each frame can have its own duration, but in case of CFR is it possible to freeze a frame for two or three frames by doubling or tripling its duration, sort of like specifying pulldown pattern? Does it depend on a container?

On a VDub2 SourceForge page I found the dev's comments, like:

Inserted frames are the way to fix timing error.
...
I experimented withUScreenCapture and in some conditions got similar behavior:
Requested frequency is 60, but the actual is ~38. Missing frames are compensated with inserted null frames.

I wonder whether these null frames are shown as black frames, or whether there is a convention that the player would sort of extend the prior frame if the current frame is null. In this case the A/D converter would not need to have a full frame buffer.

[oln]

AVI files can have "null/drop" frames as well, not sure if that's what he means though. Modern containers like mkv, mp4 and such have timestamps on each frame and can support variable frame rates depending on codec but not sure if any capture app supports it.

I don't think any of the mentioned dongles have a frame buffer, they don't have any memory chips on them or significant amount of memory buffer built into any of them or the video decoder or usb bridge chips as far as I know. Any insertion of frames would be done by something on the computer side, either the driver or the capture app. Virtualdub allows you to turn on/off insertion and dropping of frames from it's side at least, I don't know to what extent it picks up data loss from the driver side though it seems there is some sort of data dropping happening on either the chip or driver end when the signal is bad as well compared to what happens when the similar video decoder chips (like the SAA7113 in the DVC100) are used in different devices.