Buffers & Chunks In VDub

[orion940]

I've been going through frame loss reduction excercises and trying to eliminate jerkiness in the capture. I'm using the Huffyuy (sp) codec and compressing audio to 44Khz, 4bit stereo. I have VCR input.

My problem seems to lie in audio time sych etc. In VDub, I've increased the # of buffers to 20, both audio and video. I made chunk size 8K with with 8 chunks to buffer. I had relatively good luck playing around with these.

Does anyone know where there are discussions of the buffers etc in VDub? Or has anyone else played with these settings?

Thanks in advance for any pointers.

[orion940]

I ended up writing to Avery Lee with questions about chucks/buffers etc. I'm passing them along as they might be of some interest to some...

> I am having problems with capture. Vdub (latest version) gives me >minimal frame drop, which is good. I see the VT #, move though. >When I see that VT adjust # change significantly, I see a stutter (as if >there were frame drops) but VDub does not record any frame drop.

When the VT Adjust value drifts, it means that VirtualDub is detecting
a differential between the clocks of the audio and video capture
devices. This is normal whenever you have a separate sound card from
the video capture device. Once that value becomes large enough, a
frame is either dropped or inserted to make up the difference. You
won't be able to spot any 'drop' frames in the video stream if frames
were dropped instead of inserted. The name "dropped frame" comes from
their original use, which is placeholders when the application detects
that the *device* has dropped a frame, i.e. too few frames are coming
in.
-------------------------------------
> In upping the # of Video Buffers to 50, and Audio to 10 (seems to max out
> at 10), and then I played with the chunksize and #chunks in buffer. I
> found that if I went to 16M, I saw no improvement, even degradation. I did
> better it seems with a lower # in chunksize. I have a 4M chunksize and 4
> chunk/buffer.


The larger a chunksize you specify, the larger of an atomic disk
operation you are asking Windows to do. There is a limit on I/O size,
and furthermore, larger I/O causes VirtualDub to serialize as it waits
for the entire write to complete. If your hard disk nominally writes
about 15MB/sec (you will get only some of the maximum write rate, on
average), that 4MB chunk will take a fourth of a second to write. You
are thus better off with a more moderate block size that averages around
8-15 writes/sec.

If you specify a chunk size that is too small, the hard disk and
Windows kernel are burdened with too many disk requests, and the disk
may not receive data fast enough to obtain a good write rate. There
is a "sweet spot" which gives you the best results -- at the extremes,
you will either get slower disk performance, or lower parallelism
(serialization). For the vast majority of cases, 4 x 1MB is fine.

> Can you in a nutshell explain for me how the buffers, chunks all fit
> together? Are the Video and Audio Buffers input buffers?
> The chunk output buffers?

Audio and video buffers hold incoming data from the capture devices
until VirtualDub is ready to handle them. That data is processed and
compressed, and then pushed into a pipe. Data is pulled from that
pipe into a disk buffer with the chunk count and sizes you specify,
and individual chunks are then written to disk.