Greetings;
Motherboard is a biostar with nforce2 chipset, 2800xp cpu, gig of ram.
I've recently made the observation that while I can view 30fps video
from my firewire equipt movie camera with a minimal cpu hit of 2-3%,
but viewing the video from a webcam on a usb 1.1 circuit takes 30-40%
of the cpu, at half the frame rate.
Do I have something fubar in the usb? Or is this just the nature of
the beast?
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
Am Montag, 21. Februar 2005 18:16 schrieb Gene Heskett:
> Greetings;
>
> Motherboard is a biostar with nforce2 chipset, 2800xp cpu, gig of ram.
>
> I've recently made the observation that while I can view 30fps video
> from my firewire equipt movie camera with a minimal cpu hit of 2-3%,
> but viewing the video from a webcam on a usb 1.1 circuit takes 30-40%
> of the cpu, at half the frame rate.
>
> Do I have something fubar in the usb? Or is this just the nature of
> the beast?
A video stream over usb1.1 must be compressed due to bandwidth available.
Decompression needs cpu.
Regards
Oliver
On Monday 21 February 2005 12:58, Oliver Neukum wrote:
>Am Montag, 21. Februar 2005 18:16 schrieb Gene Heskett:
>> Greetings;
>>
>> Motherboard is a biostar with nforce2 chipset, 2800xp cpu, gig of
>> ram.
>>
>> I've recently made the observation that while I can view 30fps
>> video from my firewire equipt movie camera with a minimal cpu hit
>> of 2-3%, but viewing the video from a webcam on a usb 1.1 circuit
>> takes 30-40% of the cpu, at half the frame rate.
>>
>> Do I have something fubar in the usb? Or is this just the nature
>> of the beast?
>
>A video stream over usb1.1 must be compressed due to bandwidth
> available. Decompression needs cpu.
>
Thats what I was afraid of, which makes using it for a motion detected
burgular alarm source considerably less than practical since the
machine must be able to do other things too. Darn. And its usb1.1
even when plugged into a 2.0 capable port.
One could probably use the FIR output of an EagleEye (X10 stuff) to
start & stop a capture, but the lag inherent in that is less than
'optimum' IMO.
Thank you Oliver.
> Regards
> Oliver
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
Previously Gene Heskett wrote:
> Thats what I was afraid of, which makes using it for a motion detected
> burgular alarm source considerably less than practical since the
> machine must be able to do other things too.
Dependin on the type of compression used you might be able to detect
motion by analyzing the compressed datastream.
Wichert.
--
Wichert Akkerman <[email protected]> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
Am Montag, 21. Februar 2005 19:25 schrieb Gene Heskett:
> Thats what I was afraid of, which makes using it for a motion detected
> burgular alarm source considerably less than practical since the
> machine must be able to do other things too. ?Darn. ?And its usb1.1
> even when plugged into a 2.0 capable port.
There are some cameras which can operate without compression at lowered
resolution and framerate. Maybe that is good enough. In addition,
decompression may be optimised.
Regards
Oliver
Gene Heskett wrote:
> On Monday 21 February 2005 12:58, Oliver Neukum wrote:
>[...]
>>A video stream over usb1.1 must be compressed due to bandwidth
>>available. Decompression needs cpu.
>>
>
> Thats what I was afraid of, which makes using it for a motion detected
> burgular alarm source considerably less than practical since the
> machine must be able to do other things too. Darn. And its usb1.1
> even when plugged into a 2.0 capable port.
Depending on the camera model you can try some bandwidth reduction
measures to try to make it send uncompressed video:
- reduce frame rate. Something as low as 2 fps should be enough for
motion detection.
- reduce requested resolution. This of course depends on whether you
have enough resolution or not.
- selecting gray scale images. I don't know if your motion detection
software is greatly affected by this, or not.
USB1.1 bandwidth is enought for 640x480, 8 bits gray scale (or color, 8
bits bayer pattern), at 3 fps.
Of course, you can always buy a USB2.0 camera :)
--
Paulo Marques - http://www.grupopie.com
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
On Monday 21 February 2005 13:29, Wichert Akkerman wrote:
>Previously Gene Heskett wrote:
>> Thats what I was afraid of, which makes using it for a motion
>> detected burgular alarm source considerably less than practical
>> since the machine must be able to do other things too.
>
>Dependin on the type of compression used you might be able to detect
>motion by analyzing the compressed datastream.
>
Its jpg coming out of the camera, but I don't know to capture the raw
stream and do the comparisons. One would have to first subtract the
expected peak values of the sensors noise (snow if you will), either
by a running average obtained by frame addition on a pixel by pixel
basis. Somehow, that seems to imply a decoded stream. And thats
obviously not going to be anything but cpu intensive too. So I'm
less than enthusiastic that its a workable solution unless one is
able to dedicate a machine to that job exclusively. X10 FIR's like
the EagleEye or HawkEye will need to be used to detect when the
recording should be started (and stopped)
Many thanks to the responders here.
>Wichert.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
On Mon, Feb 21, 2005 at 12:16:35PM -0500, Gene Heskett wrote:
> Greetings;
>
> Motherboard is a biostar with nforce2 chipset, 2800xp cpu, gig of ram.
>
> I've recently made the observation that while I can view 30fps video
> from my firewire equipt movie camera with a minimal cpu hit of 2-3%,
> but viewing the video from a webcam on a usb 1.1 circuit takes 30-40%
> of the cpu, at half the frame rate.
>
> Do I have something fubar in the usb? Or is this just the nature of
> the beast?
Is your USB 1.1 controller UHCI or OHCI? If it's UHCI, perhaps you could
try an OHCI controller (e.g. some USB PCI cards) and see if that makes
any difference. (I remember reading something about OHCI being more
efficient than UHCI in some cases, although I don't remember the details
now.)
-Barry K. Nathan <[email protected]>
On Tuesday 22 February 2005 03:53, Barry K. Nathan wrote:
>Is your USB 1.1 controller UHCI or OHCI? If it's UHCI, perhaps you
> could try an OHCI controller (e.g. some USB PCI cards) and see if
> that makes any difference. (I remember reading something about OHCI
> being more efficient than UHCI in some cases, although I don't
> remember the details now.)
I'm already useing the OHCI version, its an nforce2 chipset.
And I think the lack of 'efficiency' is the jpg decodeing. That just
means I can't run the capture full time, only when its triggered.
Thats doable...
>-Barry K. Nathan <[email protected]>
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
On Mon, Feb 21, 2005 at 05:08:27PM -0500, Gene Heskett wrote:
> On Monday 21 February 2005 13:29, Wichert Akkerman wrote:
> >Previously Gene Heskett wrote:
> >> Thats what I was afraid of, which makes using it for a motion
> >> detected burgular alarm source considerably less than practical
> >> since the machine must be able to do other things too.
> >
> >Dependin on the type of compression used you might be able to detect
> >motion by analyzing the compressed datastream.
> >
> Its jpg coming out of the camera, but I don't know to capture the raw
> stream and do the comparisons. One would have to first subtract the
> expected peak values of the sensors noise (snow if you will), either
> by a running average obtained by frame addition on a pixel by pixel
> basis. Somehow, that seems to imply a decoded stream. And thats
> obviously not going to be anything but cpu intensive too. So I'm
> less than enthusiastic that its a workable solution unless one is
> able to dedicate a machine to that job exclusively. X10 FIR's like
> the EagleEye or HawkEye will need to be used to detect when the
> recording should be started (and stopped)
JPEG data is DCT of 8x8 pixel chunks. If you can get at that, you can
compare the DC terms of each chunk with minimal decoding. Various
thumbnailers do this for speed already.
--
Mathematics is the supreme nostalgia of our time.
Matt Mackall wrote:
>[...]
> JPEG data is DCT of 8x8 pixel chunks. If you can get at that, you can
> compare the DC terms of each chunk with minimal decoding. Various
> thumbnailers do this for speed already.
I really doubt that this would work. It seems to me that you can have
very different DC terms with very similar results. In other words, even
a little noise in the picture might produce very different DC terms.
Instead of comparing the DC terms, you could compare just the luminance.
You would have to decompress just half the data for that and you
wouldn't need to make the YUV->RGB conversion. That would probably save
a few cycles.
--
Paulo Marques - http://www.grupopie.com
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
On Wed, 23 Feb 2005, Paulo Marques wrote:
> Matt Mackall wrote:
> > [...]
> > JPEG data is DCT of 8x8 pixel chunks. If you can get at that, you can
> > compare the DC terms of each chunk with minimal decoding. Various
> > thumbnailers do this for speed already.
>
> I really doubt that this would work. It seems to me that you can have very
> different DC terms with very similar results. In other words, even a little
> noise in the picture might produce very different DC terms.
It will cause only a slight difference, noise is mainly visible in the
high-frequence parts.
> Instead of comparing the DC terms, you could compare just the luminance. You
> would have to decompress just half the data for that and you wouldn't need to
> make the YUV->RGB conversion. That would probably save a few cycles.
And since you cannot do `exact' comparisons of the luminance due to noise, but
have to do some averaging, you're back to the previous solution: Hence compare
the DC terms of the luminance. They're the average luminance of the 8x8 chunks.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Gene Heskett wrote:
> Greetings;
>
> Motherboard is a biostar with nforce2 chipset, 2800xp cpu, gig of ram.
>
> I've recently made the observation that while I can view 30fps video
> from my firewire equipt movie camera with a minimal cpu hit of 2-3%,
> but viewing the video from a webcam on a usb 1.1 circuit takes 30-40%
> of the cpu, at half the frame rate.
You have gotten most of an answer, unless someone make a fireware to
USB2 adaptor you are going to have to go slow or run firewire.
I would think the framerate could be quite slow and still be useful.
What software do you use to do the detection (curiousity only)? Of
course after you detect motion you probably want to up the framerate, so
you can see what's really happening.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
use a minimum resolution until you detect motion then switch to high
resolution.
Followup to: <[email protected]>
By author: Gene Heskett <[email protected]>
In newsgroup: linux.dev.kernel
>
> Do I have something fubar in the usb? Or is this just the nature of
> the beast?
>
USB pretty much is fubar. It's a horrible protocol on pretty much
every level including the physical level.
-hpa