OT: Why is usb data many times the cpu hog that firewire is?

OT: Why is usb data many times the cpu hog that firewire is?

[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?

-- 
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.

Re: OT: Why is usb data many times the cpu hog that firewire is?

[Oliver Neukum]

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

Re: OT: Why is usb data many times the cpu hog that firewire is?

[Gene Heskett]

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.

Re: OT: Why is usb data many times the cpu hog that firewire is?

[Wichert Akkerman]

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 <wichert@wiggy.net>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.

Re: OT: Why is usb data many times the cpu hog that firewire is?

[Paulo Marques]

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 - www.grupopie.com

All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)

Re: OT: Why is usb data many times the cpu hog that firewire is?

[Oliver Neukum]

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

Re: OT: Why is usb data many times the cpu hog that firewire is?

[Gene Heskett]

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.

Re: OT: Why is usb data many times the cpu hog that firewire is?

[Barry K. Nathan]

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 <barryn@pobox.com>

Re: OT: Why is usb data many times the cpu hog that firewire is?

[Gene Heskett]

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 <barryn@pobox.com>

-- 
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.

Re: OT: Why is usb data many times the cpu hog that firewire is?

[Matt Mackall]

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.

Re: OT: Why is usb data many times the cpu hog that firewire is?

[Paulo Marques]

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 - www.grupopie.com

All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)

Re: OT: Why is usb data many times the cpu hog that firewire is?

[Geert Uytterhoeven]

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 -- geert@linux-m68k.org

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

Re: OT: Why is usb data many times the cpu hog that firewire is?

[Bill Davidsen]

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 (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: OT: Why is usb data many times the cpu hog that firewire is?

[David Ford]

use a minimum resolution until you detect motion then switch to high 
resolution.

Re: OT: Why is usb data many times the cpu hog that firewire is?

[H. Peter Anvin]

Followup to:  <200502211216.35194.gene.heskett@verizon.net>
By author:    Gene Heskett <gene.heskett@verizon.net>
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