Re: OT: Why is usb data many times the cpu hog that firewire is?
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Why is usb data many times the cpu hog that firewire is?
use a minimum resolution until you detect motion then switch to high resolution. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Why is usb data many times the cpu hog that firewire is?
use a minimum resolution until you detect motion then switch to high resolution. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Why is usb data many times the cpu hog that firewire is?
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Why is usb data many times the cpu hog that firewire is?
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Why is usb data many times the cpu hog that firewire is?
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Why is usb data many times the cpu hog that firewire is?
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) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Why is usb data many times the cpu hog that firewire is?
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) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Why is usb data many times the cpu hog that firewire is?
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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Why is usb data many times the cpu hog that firewire is?
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Why is usb data many times the cpu hog that firewire is?
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Why is usb data many times the cpu hog that firewire is?
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Why is usb data many times the cpu hog that firewire is?
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]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Why is usb data many times the cpu hog that firewire is?
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] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Why is usb data many times the cpu hog that firewire is?
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Why is usb data many times the cpu hog that firewire is?
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Why is usb data many times the cpu hog that firewire is?
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Why is usb data many times the cpu hog that firewire is?
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) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Why is usb data many times the cpu hog that firewire is?
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Why is usb data many times the cpu hog that firewire is?
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Why is usb data many times the cpu hog that firewire is?
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Why is usb data many times the cpu hog that firewire is?
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
OT: Why is usb data many times the cpu hog that firewire is?
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
OT: Why is usb data many times the cpu hog that firewire is?
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Why is usb data many times the cpu hog that firewire is?
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Why is usb data many times the cpu hog that firewire is?
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Why is usb data many times the cpu hog that firewire is?
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Why is usb data many times the cpu hog that firewire is?
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Why is usb data many times the cpu hog that firewire is?
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) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Why is usb data many times the cpu hog that firewire is?
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
