[gentoo-user] Re: Gentoo video camera security system

[James]

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