Iain Buchanan <iaindb <at> netspace.net.au> writes: > > Neil Bothwick wrote: > > On Tue, 16 Sep 2008 06:40:11 -0700, Grant wrote: > > > >> I think USB cameras would be the way to go. Does anyone know of a USB > >> camera that works well with Gentoo? > > > > You can also use standard composite output security cameras, connected to > > a TV card with a composite input. > > except that you then have to provide power to the camera as well, and > composite is pretty bad at interference over long distances, especially > if you're running AC next to it! > RG59 coax cable can be problematic, but should work to at least 900 ft. RG6 is better (steel coated with copper in the coax core) that RG9. Power runs, particularly AC are OK to cross (perpendicular) but shot not be run parallel for more than a few feet.
If the cameras use AC (many ntsc cameras do) then a single point of grounding common for the AC power supply and the cameras is best. Sometimes isolation devices and filters have to be used on either the coax, the power circuits or both. RG6 cable should get you at least 1600 feet. > On the other hand, I've run composite without amplification about 30 > meters in a proper shielded environment, and had a clear (as the > original) picture at the other end. I don't know how USB would go over > that distance... I do, I design and supervise commercial video installations for industrial clients. > USB cameras put the reliance on your webcam drivers working, composite > cameras put the reliance on your TV card. And TV cards with multiple > inputs can start to get expensive, but most cheap motherboards have > multiple usb nowadays. QSee makes inexpensive cards that will perform 'frame grabbing'. Before transmitting you have to *ENCODE* the video. The encoding process is mathematically intensive (expensive) and runs best on a DSP such as the 6000 series from TI or a FPGA that has a custom processor for video processing implemented in hardware. Using a smoking 64 bit machine (Intel or AMD) will get you one to 2 channels of real time encoding, at best. Now receiving H.264 or any other encoded video stream and playing it back for viewing (mplayer, vlc mpeg4IP etc) that's more reasonable. This is the the best (cheapest) for hobbyist (webcams or ntsc(pal) frame grabber boards for a (local) campus setting. If you are going to re-transmit the video (stream it) over a WAN or the Internet you've got a host of other issues to deal with. If this is the goal, save yourself lots of grief and use H.264. It's better that the finest system made/deployed by Pelco, Digital Micro, GE or Honeywell ever dreamed of. Sure those big name systems have billions of feature that *nobody* ever uses, but the quality or the quality for a given amount of bandwidth you use; that war is over H.264 has whipped all competitors, include what-ever-patented-wavelet or anything thing else. I know, I've spent years deep in the mathematics of these issues, put code on FPGA, and used dev kits from TI (Da Vinci) and many others... H.264 rules and all other video encoding (although well intentioned) drooles.... http://www.linuxjournal.com/article/9005 http://www.balooga.com/mpeg4.php3 http://en.wikipedia.org/wiki/H.264 http://www.pixeltools.com/h264_paper.html http://mpeg4ip.sourceforge.net/features/index.php http://www.videolan.org/developers/x264.html And if you really want to dive into video encoding, check out this crazy Russian (actually a friend of mine). http://wiki.elphel.com/index.php?title=Main_Page Audrey has open source camera designs that run mjpeg or Ogg Theora. James
