Capture Files
11 messages in this thread
Hi,
I have a FAST MM Pro with M-JPEG bundle and I use Adobe Premier 4.0.
Last night I began serious video capture efforts to build a movie of our son's
wedding almost two years ago. I'm fortunate in that at times there were 3
video cameras going, so I ought'a have fun with transitions!
Anyway, I have a very fast setup, but I'm still dropping frames.
About avery 5-10 seconds the disk makes a seek and return seek. I can barely
hear it, but it happens. Shortly afterwards, we drop a frame.
After a while, the disk makes a MAJOR interruption, and we drop about 18
frames. There's been nothing on the 2 GB disk partition, so it's not
fragmented. This happens frequently – at regular intervals.
Between these periods of significant disk activity, the drop rate is about a
frame in 800, which doesn't bother me. Maybe it should. These dropped frames
fall out at about the 5-10 second interval mentioned above.
At lunch today, a buddy and I were discussing this and he mentioned
pre-allocating the file. Bingo! I remember reading about this somewhere,
perhaps in the FAST MM Pro or Adobe Docs.
The questions are, has someone written a program that pre-allocates a capture
file? I can write one, but there's no sense in reinventing the wheel!
What does Movie Capture do when it's pointed to an existing file? Does it
simply write on top of it – which is the correct answer? Or does it delete it
and create a new file of the same name?
When I stop a capture, and it was to a capture file, what does Movie Capture do
about marking the end of file? My plan would be to write a program that would
give me the option of allocating, and zeroing out, disk space based upon time
(and expected capture ratios), or on size (MB), or fill the disk! If I write a
100MB capture file, and Movie Capture only uses 75MB, does Movie Capture "close
up" the file and release the unused space at the end?
The settings I'm using for capture follow:
FAST's Movie Capture Settings
Frame Rate: 30
Capture Audio: On
Video:
Image Size
1/2
320×240
Keep Aspect Ratio: ON
Compression:
Compression Ratio: 16:1
Audio:
Sample Size
8 Bit
Channels
Stereo
Frequency
22 KHz
Bill Metzger
Bill, part of your problem might stem from a Thermal Recalibration disruption
on your hard disk. Digital video is very sensitive to hard drive TCAL's. I
have had to replace several otherwise good hard disks with "AV" versions to rid
myself of frame drop problems.
Dean
Dean:
>part of your problem might stem from a Thermal Recalibration disruption on
your hard disk<
To quote Will Durst, "Er?" <g>.
What's "Thermal Recalibration disruption", and can it happen on DOS-system SCSI
HDDs? I also have problems w/frame droppage on my 486/66 w/a 1 gig SCSI HDD.
Should I have gotten/get an AV hard drive for my computer? And can I even get
one for a DOS-based system?
Tim Liebe
Thermal Recalabration is performed on all hard disks to insure correct drive
operation due to expansion and contraction from heat buildup or cooldown. "AV"
series drives perform this task in the background without interruption data
flow during intensive read or write operations.
You certainly can get an "AV" type drive for your DOS system. Many
manufacturers such as Maxtor, Connor, Seagate, Micropolis make such specialty
drives. The prices are coming down and availability is generally good except
for the very large drives in the 9gb range.
This might go a long way towards solving your frame drop problems, Many CD-ROM
recorders must be used with AV type drives to keep data flowing to the
recorder. Otherwise if data stops flowing during the write process, the disc
will be ruined.
Good luck
Dean Hills
Dean:
>Thermal Recalabration is performed on all hard disks…<
Thanks for the explanation!
Tim
Dean:
Let me jump in in support of the consumer. Maxtor does have an "AV" drive, BUT
their "AV" does not stand for audio video or audio/visual or any other "AV"
from any high school equipment prep room. No, it is with true marketing
insight that Maxtor has created an acronym for "ADDED VALUE." :-> Perhaps in
their defence I should note that, having spoken with officials there, I don't
believe it to be an intentional deception. Multimedia, after all, means
different things to different people; overhead transparancies and audio, or
singing and dancing together… :-)))
BTW, marketing tsar, Rick Lucas at Micropolis deserves a lot of credit for
using T-Cal (thermo recal..) to get everyone to think video on a hard disk. He
was absoluting right that video creates special problems for hard drives. It
turns out, though, that T-Cal is just the poster child for a couple dozen
factors and parameters that have to be dealt with properly for optimal video
performance.
Jeff Sauer
Dean:
I might also add that it's not quite right to say T-Cal is done on all drives.
There is a move now toward what are called embedded servo drives. These drives
will keep reference information on each of the platters and therefore eliminate
the need for all platters to be reference or calibrated to a single platter.
One can make an argument that this inceases the overhead and therefore
decreases performance and that as long as T-Cal is postponable, there's no
reason to not do it. None-the-less, it has been suggested to me that since
T-Cal has such a negative stigma, that the industry is likely to move to
embedded servo anyway.
Jeff Sauer
Part II:
You do not mention if you have benchmarked your drive subsystem at a specific
data transfer rate. Try a package such as PCTools to determine your drive
throughput in Windows. It is possible that if you are trying to capture
uncompressed or RAW video, that your disk subsystem just is not capable of
moving data fast enough.
The only solutions to that problem is to buy as faster drive system such as a
PCI SCSI card, or a Fast & Wide SCSI subsystem (drive and controller) or
possibly a Fast & Wide RAID setup. Of course another solution would be to add
massive amount of RAM to your system such as 256MB or more if possible and
encode to a large ram drive.
The solutions are the same, ADD CASH & STIR!
Dean
Dean:
>You do not mention if you have benchmarked your drive subsystem at a specific
data transfer rate.<
No, I haven't–but I'll look into it. At this point in time, I'm simply
capturing 3-5 minute clips at 320×240 for use in multimedia presentations, and
haven't had to worry about nonlinear video use. OTOH, since I write about this
kind of stuff, it helps if *I* know what's going wrong so I can point readers
in the right direction…
>It is possible that if you are trying to capture uncompressed or RAW video,
that your disk subsystem just is not capable of moving data fast enough.<
Actually, I capture video using Intel's Indeo 3.2 compression scheme (I use a
SVR Pro card). The only time I capture "raw" video is if I'm going for
individual frames to use in DTP.
>The solutions are the same, ADD CASH & STIR!<
Ain't THAT the truth? For now, I'm more interested in finding out what's needed
than in actually laying out the money–tho it sounds like I may have to…
Best,
Tim
Dean,
I bought the Seagate Baracuda specifically to avoid the TCALs!
Thanks for the thought though.
Bill Metzger
———————–
Bill, part of your problem might stem from a Thermal Recalibration disruption
on your hard disk. Digital video is very sensitive to hard drive TCAL's. I
have had to replace several otherwise good hard disks with "AV" versions to rid
myself of frame drop problems.
Dean
—————————————
I just saw your other remarks.
I was told the drives TCAL about every 5 secs. I loose 20 frames about every
10 minutes – all at once, and another frame every 700-800 frames (25 secs).
I'm using a QLogic Fast PCI IQ SCSI card, on an Intel Pentium 90 motherboard.
That's fast SCSI! They claim the drive will sustain 8MB/sec rates.
Because I was gonna do video capture, I set out to buy the fastest PC possible.
The problem is in the DOS file system, and potentially in how the capture
program does I/O. If it's doing I/O with 512 byte blocks, it'll be slow. It
should be using LARGE block sizes and double buffering. Blocks of 64 KB to 1
MB come to mind. Double buffering allows you to write a block while filling
the next. I don't know if DOS/Windows will permit this type of behavior.
Bill
BM>> The problem is in the DOS file system, and potentially in how the capture
program does I/O. If it's doing I/O with 512 byte blocks, it'll be slow. It
should be using LARGE block sizes and double buffering. Blocks of 64 KB to 1
MB come to mind. Double buffering allows you to write a block while filling
the next. I don't know if DOS/Windows will permit this type of behavior.
DOS/Windows uses clusters of logical sectors and the block size get bigger as
your partition size gets bigger. The disk drive buffer and its physical sector
size is not a problem here. Yes, DOS will always use 512 bytes buffer to
read/write data/directory, therefore, reduce the DOS buffer size (default 20)
will speed up things. You can do it by adding a line like BUFFERS=3 at your
CONFIG.SYS (it can't be set to 0 because DOS will hang). Also put a line,
DEVICE=SMARTDRV.EXE /DOUBLE_BUFFER, at your CONFIG.SYS will allow SCSI
adapter/drive to perform double buffering without lossing data due to the
delayed disk cache flushing.
–Vince
Ulead Systems, Inc.