Dropped frames vs VCR

[miamicanes]

Last night, I made what might be a significant observation regarding dropped frames when capturing with my new Pyro -- when frames drop, they seem to drop EXACTLY 36 at a time. In other words, if I'm capturing with WinDV, I'll see the "dropped frames" counter go 0->36->72->108->etc. I'm not sure whether that's good, bad, or indicates some specific problem that can be addressed in a straightforward manner, but I thought I should mention it since it might be noteworthy.

If my JVC HR-S7800U's built-in TBC has any real use or does anything when active besides light up a green LED next to its button on the front panel, I have yet to see evidence of it.

I'm beginning to wonder whether my VCR itself has mechanical problems. Among other things, its auto-tracking seems to work about as well as its built-in TBC. Most of the tapes I've tried to play with auto-tracking either produced unstable pictures that couldn't be captured, or had screwed-up Hi-Fi audio and had to be put into 'mono/normal' mode to get acceptable sound. It's almost like it's hunting for the ideal value, finding it, then adding some constant offset to it to get a value that doesn't work. The audio itself warbles on many of them (think: soundrack from 16mm projector).

I've also seen fairly direct evidence that the mechanical build quality of VCRs & tapes has steadily gone down the toilet over the past 25 years:

When I did a test capture of an old tape recorded from channel 3 tuned to the cable box tuned to HBO back in 1988, in 6-hour mode, the picture had poor dynamic range, smeared color, and low audio fidelity... but it had almost NO dropped frames at all. The VCR used to record it was a $900 Canon VHS VCR I bought sometime in 1987 that was LITERALLY one of the first post-Beta VHS VCRs made that incorporated Sony's Beta IP into it (helical scan, HQ, hi-fi, 6 heads). It served me well for over a decade before a drunk friend accidentally destroyed it

When I did a test capture from a tape recorded sometime around 1997 on a $150 White Westinghouse VCR, in SP, its picture quality was almost as bad as the first tape's SLP-quality, and had at least one chunk of dropped frames every 3-5 minutes.

Attempting to capture ANYTHING recorded by the bottom-of-the-line crap 2-head VCR that was provided with the furnished corporate apartment I lived in for 3 months during summer 2000 was an act of unwatchable futility. Constant, nonstop dropped frames. A complete lost cause.

Tapes recorded by my HR-S7800U in SP mode as pseudo-SVHS (on non-SVHS tapes) had MUCH better picture and sound quality than the other tapes... but had slightly more dropped frames than my tape from ~19 years ago.

The tapes themselves became dramatically cheaper over the years, too. If you dropped my 1988 tape on somebody's head from 3 or 4 stories up, it would probably give them a concussion and leave them unconscious & bleeding from a nasty head wound. And it wasn't even a high-end tape... I think I paid something like $20 for a 6-pack back then. In contrast, my newest tape was so light, I think 3-6 helium balloons would probably be enough to lift it up.

Sigh. I wish I'd spent $200 getting my Canon VCR repaired instead of buying the new one for $150. In hindsight, I had no real appreciation for just how good it was compared to the build quality of newer VCRs

[JohnnyMalaria]

The 36 frame chunks suggests to me that it could be a PC related thing - i.e., some other piece of hardware frequently doing something that interferes with the FireWire card. Try unplugging any hardware that you can esp. external USB things.

BTW, how often to the 36 frame chunks get dropped and is it repetitive - e.g., every 20 seconds or every now and then without a pattern

Other troubleshooting options:

Generate a live signal from the troublesome VCR - e.g., bring up a menu page and/or pick up a broadcast signal. Capture this instead. If you still get the same pattern of dropped frames, it means it isn't due to the mechanism. If the dropped frames go away, then it probably is the mechanism (and/or tape).

If you have or can borrow an miniDV camcorder with analog inputs, use that instead of the Pyro. If the problem goes away, the Pyro is a strong suspect. If the problem doesn't go away, try recording to a miniDV tape instead of capturing and then play the tape on a conventional TV. If the recording shows dropped frames then you know it has nothing to do with the PC or Pyro.

Try different capture software to rule out WinDV being the problem. Odds are it isn't though since nearly all capture apps use the same OS functions.

[miamicanes]

If the chunk-dropping is periodic, I haven't noticed the pattern yet. I've gone for more than 5 minutes without getting any, I've had 2 or 3 batches within 30 seconds, and I've had batches 1-2 minutes apart.

The drops DO seem to be consistent from play to play. In other words, if I try to capture a scene again, they seem to happen at the same place in the scene.

It almost looks like something is over-reacting to the first dropped frame, and waiting long enough for 35 more to elapse before resuming the capture.

How likely is it, really, that Windows could be the culprit? Is the Pyro's operation REALLY so brittle that it needs the host computer's undivided attention in rigid lockstep (like HP's first coaster-producing late-90s CD writers), and has zero tolerance for distraction? Does the Pyro just blindly spew data at the 1394 bus and hope for the best, or is there a real 2-way protocol involved that can re-send a datagram if necessary?

[JohnnyMalaria]

Interesting. It reminds me of Sony DSR-11 tape deck that I have that *should* have a very high quality DV codec chip (since the deck is >$1000). Usually, it is flawless, never a dropped frame. However, when I hook it up to a DVD player and play this one particular DVD, it always drops one frame at exactly the same point. It's the Ziggy Stardust motion picture. For the most part, the video is dark (since it's a stage show) but there is this one camera flash that just seems to overpower or confuse the DV encoder in the tape deck.

Is there anything noticeable about when the frames get dropped? A sudden transition to a very bright picture?

Given your description - esp the repeatability - it would rule out a PC-related thing. But, as you suggest, perhaps the Pyro is recovering poorly from a single bad frame....

[JohnnyMalaria]

Does the Pyro just blindly spew data at the 1394 bus and hope for the best, or is there a real 2-way protocol involved that can re-send a datagram if necessary?

Blindly it doth spew. DV sources simply broadcast what they have to offer. If the recipient misses it, it's gone.

[miamicanes]

Ouch. So much for the binary file-copy analogy.

OK, first questions first: in DV terminology, does "ONE dropped FRAME" mean, "a single odd or even field, whose resolution is 720x240", or does it mean "an odd and even field, interleaved together and sent as a single 720x480 frame"? In other words, if WinDV tells me I have 36 "dropped frames", does that mean it dropped 72 fields, or is it just playing fast & loose with semantics and really dropped 36 fields?

Second: is each frame (field?) identified by a unique, ascending, continuous number? In other words, does the capture app know it dropped 36 frames because dead reckoning tells it that it hasn't received a frame in 36 x ${however-long-it-takes-to-send-one-frame} intervals of time, or does it know because it receives two sequential frames, one of which has id=x, and the next has id=x+36?

Are there any apps to try and troubleshoot DV problems by monitoring and logging DV activity in a rolling logfile (so I could start the capture, start logging, wait until a frame-drop occurs, then stop the capture & logging and study the log at the point where the drop occurred to see exactly what took place there?

[JohnnyMalaria]

Ouch. So much for the binary file-copy analogy.

Yup. That's why I (and a few others around here!) occasionally counter the "it's transfer, not capture" argument since, really, it is more like capturing something - you miss it, it's gone!

OK, first questions first: in DV terminology, does "ONE dropped FRAME" mean, "a single odd or even field, whose resolution is 720x240", or does it mean "an odd and even field, interleaved together and sent as a single 720x480 frame"? In other words, if WinDV tells me I have 36 "dropped frames", does that mean it dropped 72 fields, or is it just playing fast & loose with semantics and really dropped 36 fields?

DV is field-neutral - i.e., what gets compressed is a 720 x 480 image (or 720 x 576 for PAL), whether or not it is interlaced. So, one dropped frame means exactly that - an entire 720 x 480 image.

Second: is each frame (field?) identified by a unique, ascending, continuous number? In other words, does the capture app know it dropped 36 frames because dead reckoning tells it that it hasn't received a frame in 36 x ${however-long-it-takes-to-send-one-frame} intervals of time, or does it know because it receives two sequential frames, one of which has id=x, and the next has id=x+36?

The encoded DV data are sent in packets of 80 bytes (150 per frame for NTSC). It's the receiving end that decides if the frame is missing or corrupt and, therefore, gets dropped. That receiving end is typically the Microsoft MSDV drivers (+ the lower level ones that it needs) and the determination of dropped or not is made by the OS.

Sequential numbering of frames does occur when you record DV to tape - it's a requirement of the specification. This information (the Absolute Track Number or ATN) is contained in the data transmitted via FireWire. Our software can retrieve it (but we haven't implement the UI for it yet). Also, DirectShow-based applications receive raw DV frame data from Windows with a timestamp but, unless the app specifically records that info, it's transient.

The DirectShow framework that is used by nearly every capture program available for Windows provides functions that the applications can use to find out how many frames have been dropped. But that's all it does - tells you how many, not when. Capture apps typically poll the OS on a frequent basis (e.g., when each new frame arrives). If it is polling every frame, then you can narrow down the point at which a frame got dropped. But Microsoft warn that the reporting of dropped frames isn't guaranteed to be 100% accurate (though it seems to be in my experience).

Are there any apps to try and troubleshoot DV problems by monitoring and logging DV activity in a rolling logfile (so I could start the capture, start logging, wait until a frame-drop occurs, then stop the capture & logging and study the log at the point where the drop occurred to see exactly what took place there?

I'm not aware of any. A fews ago I wrote something called DV Inspector but it was for looking at static DV information (such as in an AVI file - actually, MOV and DV format). I could build the logging into our software - it would just need to make a record of the DirectShow "media time", exactly when dropped frames occur and, if available, the timecode/ATN. Logging of the capture process is something I want to add anyway, especially for scene detection.

If your source DV had timecode, you could capture with our software while burning the TC and then, if frames get dropped, you can tell which ones if you play the captured file using a suitable media player with frame stepping. Unfortunately, since you are capturing an analog source directly with the Pyro, you won't have timecode, nor will you have the ATN mentioned above.

[miamicanes]

Well, I ran a few more experiments. I made 4 passes through a scene using wmcap.exe (the "official" utility from ADS) -- two with the HR-S7800U's TBC disabled, and two with it enabled.

It looks like the number of dropped frames wasn't quite as fixed as I thought it was... this time, I got a mix of 36 and 37-frame drops. HOWEVER, as before, the drops appeared consistently at the same spot each time. Strangely, I actually had one MORE frame-dropping event during one of the runs with the TBC enabled. Looking at the quality of the captured DV files, the TBC did actually appear to make a big difference (even though it didn't do a thing to prevent frame drops). The captures made without the TBC enabled had a green bar running along the right side, and the video quality was noticeably lower than the captures made with the TBC enabled.

I also updated all of my drivers to the newest versions, and uninstalled Norton Antivirus. No improvement. Well, that's not quite true... my computer's running a lot faster now (grin), even if it didn't make the slightest bit of difference to the DV captures themselves.

Also, it appears that the firewire chip is definitely NOT sharing an IRQ with anything. In fact, it has an "extended" IRQ all to itself -- IRQ17 (finally! Extended IRQs have arrived in the AMD universe...)

I *DID* decide to go ahead and buy a AVT-8710 TBC. The company I bought it from is in Miami, so I'll either have it Friday (if they ship it tomorrow), or (god forbid) maybe tomorrow if they let me come in and pick it up (they're located about 10 miles away from my office). So I guess I'll find out one way or another whether or not it actually helps.


I have to admit that I AM curious to see whether it'll make the slightest bit of difference with regard to a tape I bought ~6 years ago at a flea market that was NEVER playable (let alone capturable) for some reason