Hi Scott,

It's very good to have your input, thank you. I've looked at the links you provided - it's interesting what you are up to.

We are going to need streaming compression on the gumstix from the Caspa which I think means we'll need to dig into the DSP to achieve a decent frame rate but that seems quite a big step up from where we are currently. I'm holding out for that first link from Andrew to your site!

Thanks again and thanks for the offer of help.

John

On Tue, Jun 26, 2012 at 11:13 AM, jumpnowdev <scott@jumpnowtek.com> wrote:
Following up on what Andrew said, you might be interested in this post where
I
was fooling around with three USB webcams streaming from a single Gumstx.

http://www.jumpnowtek.com/index.php?option=com_content&view=article&id=83:gumstix-multicam&catid=35:gumstix&Itemid=67

If nothing else it's a proof of concept.

The video was 640x480 color at 30fps with negligible load on the Gumstix, no
DSP involved.


It was MJPEG video which many USB cameras support.

Network bandwidth wise, MJPEG is not a problem on most networks if the
number
of cameras is reasonable. I've had 16 cameras going and the network was not
the
problem. CPU load on the viewing machines was the bottleneck.

MJPEG is a bit of a storage problem, but that can be addressed by doing the
compression on a bigger machine on the LAN. My partner at Syntro has done a
post on this topic, but I can't find it right now.

MJPEG does have an advantage in stream processing in that every picture is
self-contained and you don't have to sync up.

Here's an example of some inline filtering of MJPEG

http://pansenti.wordpress.com/2012/02/09/syntro-pipeline-stream-filter-demonstration/


The driver on the Gumstix side for that first post is a simple custom V4L
app,
part of our Syntro suite of apps. It doesn't work with all USB cameras yet,
but
that's just because we haven't taken the time. The two missing features are

1. Handle MJPEG with restart markers embedded. Some of the newer webcams do
this.
We transmit these images just fine. Qt spews errors in our standard
SyntroViewer
app when we uncompress them for display on the other end. The images are
fine.
It's just an annoying warning message.

2. Some web cameras only provide YUV images. For these we are back to the
same
problem as the Caspa. We could use the DSP or the ARM core with somthing
like
libjpeg. We've just opted to choose the 'right' cameras to use with the
Gumstix.


There are some more Syntro demos here.

http://pansenti.wordpress.com

Gumstix boards are one of my standard test platforms for Syntro, so most of
our
apps run on it.

Syntro is GPL/LGPL and cross-platform. The kernel version is unimportant
with
Syntro which is convenient, but it does require Qt.

If you want more details or need some help setting up Syntro on a Gumstix on
let me know. Applies to anyone.

We are looking for some Gumstix users.



--
View this message in context: http://gumstix.8.n6.nabble.com/Kernel-version-for-new-Caspa-and-streaming-compression-project-tp4964710p4964724.html
Sent from the Gumstix mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
gumstix-users mailing list
gumstix-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gumstix-users