[NTLUG:Discuss] A client solution using Linux

[Daniel Hauck]

What about various V4L offerings?

I will say that we have already tried working with the ATI All-In-Wonder PCI
card to capture video with limited success.  The frame rates were
unimpressive but I think that not enough tweaking was done on that part of
the project but the expense of it was too much.

I don't know of any supported USB camera devices yet.  I own one (Intel
Create and Capture) but isn't supported at all.  Do you know of any from the
get-go?

Our ATMs' comm link will be a bit faster than modem links or maybe not.  But
we don't anticipate more than 60 seconds of video to transmit and will
definitely not be real-time.  15FPS might be acceptable for this purpose.  I
just don't want it to look too much like Max Headroom.

Encryption is part of the ATM world's standards and is certainly planned for
deployment in this case as well per banking regulations.

So has anyone had any reasonable success with video capture under Linux?

----- Original Message -----
From: Bug Hunter <bughuntr at one.ctelcom.net>
To: <discuss at ntlug.org>
Sent: Sunday, October 22, 2000 4:26 PM
Subject: Re: [NTLUG:Discuss] A client solution using Linux


>
>   You can do this, but my opinion it will take 6 months to 1 year to bring
> to manufacturable status.
>
>   The basic problem with ATM's is they tend to rely on slow modem links.
> Therefore, you have the same limitations as calling in from home.  I would
> recommend taking one of the USB cameras that are now proliferating, and
> use that camera with a microphone, and capture about 15 frames a second to
> send to mexico or wherever.
>
>   Another problem with this is the rate at which technology is moving.
> You will need to be prepared to swap out hardware as your bandwidth
> increases.  The huge cost of deployment is something else also.
>
>   Now that RSA is in the public domain, be sure to encrypt the images and
> voice.  Most of the public won't use it. the ones that do will appreciate
> it, including the evil ones.
>
>   One thing to note, you must compress any data you transmit before you
> encrypt that data.  I managed an encryption project at a small company
> for an IBM contract, and that is one thing that confused some folks.
> Encrypted data has no redundancies, and therefore cannot be compressed.
> However, compressed data can be encrypted.  Technically speaking,
> compressed data is encrypted, but the decryption sequence is well known,
> therefore it isn't encrypted.  :)
>