View Full Version : Re: Subject: uncompressed video

Peter Vint
11-14-2003, 03:15 AM
I sincerely appreciate everyone's contribution on this topic, but I
wonder if we might try to solicit the advice of some commercial groups
who rely on DV for their motion measurement products. Included in this
might be technicians from Peak Performance, Dartfish, Simi, etc. If
these groups would be interested in responding with the professional
experience and advice, while keeping advertisements out of the
discussion, it might benefit the group.


Peter F. Vint, Ph.D.
Research Scientist

Research Integrations, Inc.
9280 S. Kyrene Rd. Suite 101
Tempe, AZ 85284

Phone: 480-893-1600 x214
Fax: 480-893-0602
e-mail: peter.vint@riimail.com

-----Original Message-----
From: Biomechanics and Movement Science listserver
[mailto:BIOMCH-L@NIC.SURFNET.NL] On Behalf Of Jason Harrison
Sent: Wednesday, November 12, 2003 2:03 PM
Subject: [BIOMCH-L] Subject: uncompressed video

Tomislav Pribanic asked:
> Frequently I came across expression claiming that some video cameras
> are able to 'save streaming uncompressed video directly to disk'. What
> bothers me here is word 'uncompressed'.

If we're going to talk about specific bandwidths and terminology let's
talk about specific cameras:

Imaging Source DFK21F01, 640x480, 1CCD color, IEEE1394 bus, DCAM
protocol, no audio

> If we take cameras (effective) CCD to be 640x480 pixels size we end up
> with 307200 pixels. Then each pixel is granted 3 bytes for color which
> leads to amount of information 307200*3=921600 bytes, or
> 921600/1024=900KB, or 900/1024=3D0.8789MB. That is how much you are
> going to get if you take still photo (bmp file) with your digital
> photographic (video)camera.

Thankfully, video cameras don't use BMP or 24 bits per pixel for
colour. Instead they can use 8 (monochromatic), 12 (YUV 4:1:1), 16
(monochromatic or YUV 4:2:2), or 24 bits per pixel. This is one way to
reduce the video bandwidth: appropriate representation to achieve
reduced bits per channel.

The Imagining Source has a table of CDD sizes, bits per pixel and
frames per second achievable on a firewire bus:

For example, one DFK21F01, 640x480 on a firewire bus:
- 8 bits/pixel monochome is 64% of the bus bandwidth at 60fps,
- 12 bits/pixel YUV 4:1:1 is 48% of the bus at 30fps
- 16 bits/pixel YUV 4:2:2 is 64% of the bus at 30fps
- 24 bits/pixel RGB is 96% of the bus at 30fps

> Now, 25frames progressive video camera would need to handle 25 of
> those images in second, meaning that 0.8789*25=21.97MB need to be sent
> via firewire on hard disk.
> Theoretical speed of firewire is 400MBits/seconds which is roughly
> twice as needed for above data. However to my knowledge realistic
> read/write speeds of most commercial hard drives can be expected
> around 20-30MB, which is pretty optimistic (try diagnostic toll
> SisSoft Sandra). If CCD sensor is of even greater size things becomes
> even more suspicious.

Your HDD numbers sound like they are for an ATA 7200RPM HDD -- typical
for a new workstation. Serial ATA supports up to 150MB/sec (but you
may have trouble finding HDD to match that maximum bandwidth).

The solution is to use (a) faster HDD (SCSI 1000RPM), (b) and RAID:
multiple HDD (eg 4) each taking a fraction of the bandwidth. We have a
Ultra 160 SCSI RAID0 enclosure at UBC purchased in 1999 that supports
1000MB/sec read and 500MB/sec writes for video editing.

> 1. Thus, do 'streaming uncompressed video cameras' really have no
> compression at all or some takes place right at the CCD sensor?

You can get them in all possible flavors (RGB, YUV, monochrome)

> 2. Is it possible to save uncompressed above data on tape too ( I have
> no idea how inert is tape saving mechanism on cameras ). If so, then
> it should be no problem to grab those video images on disk, but of
> course not in real (playback) time if our disks are not ready for it!?

I don't expect that tape would have the bandwidth available for
uncompress video recording -- I think DV and D1 are designed for RAID
HDD arrays rather than tape. There are special busses for D1 and
DigiBeta (eg, SDI). Firewire is sort of like "prosumer USB" -- it
solves many of the same problems but is not designed for all purposes
(eg, the length of Firewire cables is limited to 3m, but you can use
hubs or string longer cables if you dare). I expect that most "high
performance serial" transfer busses will eventually shift to fiber
optics to avoid impedance delays in copper. You can get Firewire to
fiber translators but they are very expensive (USD$1500).

Further reading:

Jason Harrison, PhD
Post-Doctoral Fellow and Imager Lab Manager
Imager Laboratory for Computer Graphics, Visualization and HCI
FSC3640 - 2424 Main Mall, Vancouver BC V6T 1Z4
Cell: 604 644 8611 Lab: 604 822 2218; Fax: 604 822 8989
Web: http://www.cs.ubc.ca/~harrison

To unsubscribe send SIGNOFF BIOMCH-L to LISTSERV@nic.surfnet.nl
For information and archives: http://isb.ri.ccf.org/biomch-l
Web-based discussion forum: http://movement-analysis.com/biomch_l

To unsubscribe send SIGNOFF BIOMCH-L to LISTSERV@nic.surfnet.nl
For information and archives: http://isb.ri.ccf.org/biomch-l
Web-based discussion forum: http://movement-analysis.com/biomch_l