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
