On Mon, 06 Jul 2009 20:41:03 +0300, jack catcher (nick) wrote:

>> Does the webcam just deliver frames, or are you getting frames out of
>> a decoder layer?  If it's the latter, you want to distribute the encoded
>> video, which should be much lower bandwidth.  Exactly how you do that
>> depends a bit on what format the webcam claims to deliver.
> 
> Well, getting already encoded video from the webcam sounds almost like a 
> free lunch (which it probably is not). At least I wouldn't want to get 
> too long a delay because of the encoding.
> 
> I haven't got the webcam(s) yet, and I guess I can basically purchase 
> any ones I find suitable for getting the job done. Any recommendations?

The webcam is bound to do some encoding; most of them use USB "full speed"
(12Mbit/sec), which isn't enough for raw 640x480x24...@30fps data.

Chroma subsampling and JPEG compression will both reduce the bandwidth
without introducing noticable latency (the compression time will be no
more than one frame).

Temporal compression will reduce the bandwidth further. Using B-frames
(frames which contain the differences from a predicted frame which is
based upon both previous and subsequent frames) will provide more 
compression, but increases the latency significantly. For this reason, the
compression built into video cameras normally only uses P-frames (frames
which contain the differences from a predicted frame which is based only
upon previous frames).

The biggest issue is likely to be finding latency specifications, followed
by finding a camera which meets your latency requirement.

Also, any "read frame, write frame" loops will add an additional frame of
latency, as you can't start writing the first byte of the frame until
after you've read the last byte of the frame. Video APIs which let you get
rows as they're decoded are rare.

-- 
http://mail.python.org/mailman/listinfo/python-list

Reply via email to