Dropped Frames on Capture with VFW

[Christrati]

I remember someone posting something similar to this a while back, but I'm having trouble finding the answer. Basically, when I capture with VirtualDub or AVI_IO, I loose a frame or two every 1-2 mins.

The strange thing is if I capture without audio, I don't loose any frames (well, I've let it run for about 5-10 mins). Also, in VirtualDub, I use the internal test and still drop frames so I'm enclined to think it is something with my soundcard and syncing to the video. Any suggestions on what I could do to fix this?

Chris

[Dr Mordrid]

And the rest of your hardware is??....

Dr. Mordrid

[Christrati]

No problem:

1 GHZ Pentium 3
512 Meg DIMM
ABIT BE6 Motherboard
Marvel G450 eTV
Netgear 10/100 PCI Card
SBLive Value PCI
IBM 40gig 60GXP 7200rpm HD
Western Digital 20 gig 7200rpm HD
Sony DVD Drive
Plextor 12/10/32A

Chris

[Dr Mordrid]

Sounds like a minor case of SBLive-itis.

They are world class bus hogs and this kind of problem is the typical symptom. That and audio artifacting (pops, clicks etc.). Some folks, usually those running VIA chipped systems, have it so bad they drop many times what you're dropping.

I had 5 of 'em and all exhibited those problems. I'm now running the Turtle Beach Santa Cruz. It uses minimal resources and sounds much better than the SBLive.

Assuming Win9x/ME as your OS;

Before going out to buy a new card try the Matrox Win9x/ME system optimizations denoted here;

http://www.matrox.com/mga/support/fa.../video4.cfm#32

Chief among these are the changes to VCACHE, disabling of the write behind cache and the using of a custom editing profile with your network card disabled in it.

VCACHE changes can be made less painfully by using Outer Technologies freeware CACHEMAN utility. It has "multimedia" presets for each Win9x/ME variant and has a GUI for doing them manually. It can also be used to force the unloading of unused *.dll's and to optimize swapfile usage. Get it here;

http://www.outertech.com/

Dr. Mordrid



[This message has been edited by Dr Mordrid (edited 28 June 2001).]

[Christrati]

That's what I thought, since the Santa Cruz used the DSP processor. BTW, it now has Windows 2000 support for it also, so that might be the way I have to go.

I already ran through those tweaks, but is it normal to drop frames using the internal test of Virtual Dub?

Chris

[Dr Mordrid]

I don't use VirtualDUB much because it's not as good as AVI_IO in handling dropped frames plus it has a larger memory footprint. I've also found that it drops more frames than AVI_IO to start with so.....

AVI_IO will also fill in a dropped frame with the previously captured one to keep the frame count right. This keeps the audio in synch much better than other capture proggies.

When you do install the TBSC and its Win2K drivers FOLLOW THE DIRECTIONS TO THE LETTER. Win2K installs some drivers by default that will conflict. Also there is a multiple mixer patch you can install if you decide to put in a 2nd audio card etc. Handy.

Dr. Mordrid.



[This message has been edited by Dr Mordrid (edited 28 June 2001).]

[Christrati]

Cool, sound like I'll have to order one and ditch my SBLive. Thanks for your help! Do you remember the specific post where they discussed why it doesn't use so much bandwith? Was it because of the DSP processor or something like that?

Chris

[Dr Mordrid]

The major reason is the DSP. There is also a problem in the SBLive where it hits the system timer interrupt constantly for some reason. That sure helps

There is an interesting Santa Cruz FAQ on VIAhardware.com that discusses the relative issues vs. SBLive. The DMA issues and the hogging that causes the crackles also cause frame drops. Most issues here apply not only to VIA but to other hardware as well.

This FAQ also has some directions on getting rid of ALL the SBLive drivers, since the unstaller doesn't complete the job.

It's here;

http://www.viahardware.com/scfaq.shtm

Dr. Mordrid

[Christrati]

Done deal then, I went ahead and ordered the Santa Cruz soundcard. Thanks for the help.

Chris

[Dr Mordrid]

Just remember that a clean source is essential for lossless captures as well. Even a Ferrari runs bad on 80 octane gas

Dr. Mordrid

[Christrati]

Well, I installed this new card and here's the result:

1 frame lost after 1.5 mins. Hmmm, I'm starting to suspect Matrox's VFW drivers with the G450. Oh well, I'll have to break out the old G200 and give it a try with the 5.x drivers.

Thanks for the help though, I will say I like the features of this card a lot better! So far so good here, no big troubles with installing this card. Too bad it didn't solve my problems with capturing, but I'm sure it's due to an A/V synch. Any other tips? It seems to always happen at 1.5 mins.

Chris

[mikiem]

Hi Chris

The whole thing is somewhat longwinded I'm afraid, so I'll try to summerize. I've been doing a bit with this sort of problem for the past several weeks, though with a marvel g400 -- perhaps the basic stuff is the same, since most designers &/or engineers rely on experience as much as anything IMOH.

With the G400, the video stream is slaved to the audio, meaning the fps and length of the video stream as written to disk is adjusted to match the audio length. This is something PC-VCR does very well, but at the usual cost of a somewhat variable fps & audio stream length.

Many capture apps try to enforce a strict fps and interleave, as with AVI_IO, which according to some involves a bit of trickery, trying to fool the actual capture drivers etc... This doesn't always work well, and you can pick up all sorts of drops originating either with the card & drivers or with the capture app.

Unfortunately, it's a weakest link thing, or was in my case at least. If everything is perfect, then not a problem, but if anything stresses the card's capture process, it then can show up with the symptoms you've experienced. The fact that audio is involved may or may not reflect any problems in that end of things.

What you might try is looking for any capture apps that let you have a slightly variable frame rate, like Sonic Foundry's capture applet, Microsoft's Vcap, FreeVCR, that sort of thing. In VDub you can also try unchecking the box to set the video clock off the audio stream.

Other then that, IMO, might have a look at stuff that would at first seem irrelevant, like timing settings within the mothboard bios and so on.

Hope that helps
mikie

[Christrati]

I guess that's possible but from what Matrox has told me, PC-VCR for the G450 using DirectShow but it is not available to other drivers. I'm wondering if I use some older drivers along with my G200 card if that will fix the frame dropping issue. I'm going to try it later this weekend and post any results.

My gut feeling is it is something in the VFW drivers, but I can't be sure. What you've explained mickiem makes sense on why it works great in PC-VCR too. I just wonder why some people's system doesn't drop any while other people run into the similar problems I have. My sources are usually a TV broadcast or a VHS tape. Oh well, nothing like trial and error in order to fix some things!

Chris

[Dave Brown]

Chris, I have *exactly* the same problem, albeit on a G400tv. It IS something to do with the drivers (in my case). I have just installed the latest drivers. It does not do it if I install the origonal drivers that are on the cd. One strange thing I tried last night was that if I change the type of encoding on the audio from 44k stereo pcm to Microsoft ADPCM or MP3 it is ok. I found this strange, TMPencoder even converted it to vcd standard which I thought it would object to, so you might like to try MP3/ADPCM in the audio compression settings in VDub to see if it works for you.

I am a bit cheesed really as I changed to the new drivers because on TV out the pic would stutter and loose frames every 5-10 mins or so for about 30 secs (a bit like old keystone cops movies), this has been discussed here a lot recently. Any way the new drivers have curred this for me but I now have the problem you have. The other thing that happens is that if I choose the Matrox YUY2 setting it dosent drop any frames but the *use* indicator goes up to about 80% (at 352x288) but as I say it dosent drop frames, now if I choose huffyuv it starts to drop frames and the frame rate slowly drops but the *use * setting (you know the inicator in Vdub that tells how much proccessor your using) only shows about 10-15%, I find this confusing. Before I built this system I was using a Gigabyte GA5AX and a AMD K6/2/450 with 128mb ram and a Pinnacle DC30, this system could capture ALL day without dropping frames (makes me wonder why I upgraded in the first place). Sometimes I wonder if its all worth the effort.

my system is

P3 600 slot1
Abit BE6 r2
384 mb ram
Matrox G400 marvel tv
Soundblaster awe64 gold
Yamaha 2100s scsi writer
Pioneer 105s dvd
Iwill scsi card
Dlink 530 pci networkcard
IBM 45 gb ata 5 X2
Seagate 40 gb ata 5 x1


Dave Brown

[mikiem]

Hi Chris

I *think* the problem has more to do with the way windows handles media then with the vfw portion of code itself, though I could be very wrong. Microsoft introduced a different approach, at least with audio, with dx8, and I imagine they've incorporated this into everything media related in windows, including internet explorer. I would think that if this is the case and causing some of your problems, then you should have problems with the G200 as well -- be interesting to hear what you find out.

I know with dx8 they changed the steps audio goes through to reach your sound card, eliminating a few, and this new routing could work better or worse, maybe have some effects if say the capture card was expecting the old direct sound input.

Really guessing, I also imagine it's possible that when they designed the cards there was a high enough latency before the audio actually reached the hardware, that they didn't worry as much about timing. If they figured that the card had so much time to generate so many frames, and that time was then reduced because the audio gets there faster...

Older drivers might make less use of direct x related functions, so perform better if that was the case. Capturing the audio in a compressed format would increase the time it takes to get the audio stream on disk -- it would have to -- and if that does help capturing, maybe I'm at least partially right.

The part about PC-VCR using direct show with the 450 makes sense, though direct show is more concerned with moving the data around then actually manipulating it, so I don't know how much this would effect anything at the card level.

RE: Dave's experiences with yuv captures, recording just the streams should work because it's more of a straight through process, and the problem isn't getting the streams on the hard drive fast enough. Add HUFFYUV to the mix and then you're adding just a little lag time. That lag could be all it takes to push the card into dropping frames -- remember the capture process has to monitor the file written to the drive or else it wouldn't be able to report drops from exceeding your system's data rate capability.

If something here is marginal, with the way the cards operate or the logic behind them or whatever, just takes that little extra push to start showing drops. I've even had it occur & then eliminated the problem by swapping s-video cables, from a known good cable to another of shorter length, so it really can be something quite small, and maybe explains a bit why it happens with one person and not another.

RE: Dave's cpu usage... I think that when doing straight YUV it's probably using windows codecs, whereas HUFYUV is pretty optimized to eliminate the need for a lot of horsepower.

Hope something there makes sense
mikie

Almost Forgot!
Dave might want to see this, copied from the ProTools docs:
SoundBlaster family cards MUST BE USED AT A SAMPLE RATE OF 48KHz. due to input/output clock drift on these cards. Failure to use a sample rate of 48KHz. may cause audio artifacts, stop successful operation, and/or produce –9092 error messages.