public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Matt Mackall <mpm@selenic.com>
To: Gene Heskett <gene.heskett@verizon.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: OT: Why is usb data many times the cpu hog that firewire is?
Date: Tue, 22 Feb 2005 15:10:00 -0800	[thread overview]
Message-ID: <20050222231000.GA3163@waste.org> (raw)
In-Reply-To: <200502211708.27211.gene.heskett@verizon.net>

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.

  reply	other threads:[~2005-02-22 23:10 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-21 17:16 OT: Why is usb data many times the cpu hog that firewire is? Gene Heskett
2005-02-21 17:58 ` Oliver Neukum
2005-02-21 18:25   ` Gene Heskett
2005-02-21 18:29     ` Wichert Akkerman
2005-02-21 22:08       ` Gene Heskett
2005-02-22 23:10         ` Matt Mackall [this message]
2005-02-23 13:13           ` Paulo Marques
2005-02-23 17:15             ` Geert Uytterhoeven
2005-02-21 18:40     ` Paulo Marques
2005-02-21 18:46     ` Oliver Neukum
2005-02-24 11:52     ` David Ford
2005-02-22  8:53 ` Barry K. Nathan
2005-02-22 13:12   ` Gene Heskett
2005-02-23 23:28 ` Bill Davidsen
2005-02-24 23:50 ` H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050222231000.GA3163@waste.org \
    --to=mpm@selenic.com \
    --cc=gene.heskett@verizon.net \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox