[pvrusb2] NSLU2 + PVRUSB2 = Bird-Box Cam

[Mike Isely]

On Sun, 5 Feb 2006, Phil Endecott wrote:

> Dear PVRUSB2 people,
>
> Thanks to Mike and friends for their work on this driver, which is key
> to my "geeky project of the season" - a bird-box cam!  Let me explain...
>
> For the last couple of years a pair of bluetits have raised a family in
> the nest box on the side of my house.  I was able to watch them first
> bringing nest materials and later food for the chicks from my bedroom
> window.  But that wasn't enough - I wanted to see inside the box - and
> last weekend I borrowed a ladder, drilled a hole in its roof and fitted
> a wireless camera.  The birds should be arriving in the next few weeks
> and I plan a "live webcast" of the whole thing.
>
> At the other end of the (analogue) wireless link I have a PVRUSB2,
> connected to an NSLU2.  If you're not familiar with the NSLU2, aka Slug,
> it's a Linksys product with a 266MHz XScale processor, 2 USB2.0 ports
> and ethernet, running Linux.  The plan is that the NSLU2 will grab the
> video from the PVRUSB2 and upload it to my co-located web server.
>
> The PVRUSB2 worked first time, which was great, except that the NSLU2
> crashed ten minutes later.  This was very repeatable; the NSLU2, which
> was normally rock-solid, would lock up about ten minutes or so after any
> PVRUSB2 activity.  Unfortunately it's not easy to see any kernel panic
> message on the NSLU2 but I have some parts ordered so that I can connect
> to its serial port; if that reveals anything I'll post again.  But is
> anyone aware of anything with a ten minute timeout, or anything of that
> sort?  I did wonder if the PVRUSB2 was going to sleep, or something.

That's the first I've heard of this sort of problem.


>
> My NSLU2 had been running Debian, but in an effort to track down the
> cause of the crash yesterday I installed an OpenEmbedded-based
> distribution on a new flash stick.  This is running exactly the same
> kernel image and modules as the Debian system, but doesn't crash!  The
> mystery deepens.  What can be different?  The hotplug scripts, perhaps?
>  A Debian cron job was my first guess, but it still crashes with cron
> off.  Anyway, I can now look at the other parts of the system.

Mystery indeed.  If the kernel + modules stayed the same, then maybe 
something in userland is driving the kernel / modules differently.  Is 
your lsmod output the same in both cases?  (Just thinking if perhaps 
different modules might be getting loaded.)


>
>
> My motivation for using the PVRUSB2 was of course its built-in MPEG2
> encoder; software encoding on the NSLU2 would have been very
> challenging.  But it has the disadvantage of inflexibility compared to a
> software encoder.  Here are some of the particular issues that I've
> encountered; does anyone have any suggestions?
>
> - Capturing still images: I'd like the web page to include still images
> as well as video clips.  I think that the only way to do this is to read
> from the MPEG stream until I've got the first frame, and then convert it
>  to a JPEG.  Doesn't the Connexant chip have a way to read the raw
> framebuffer, bypassing the MPEG encoder?  (Is this functionality present
> in the Windows driver?)  Is there a computationally-easy way to convert
> an MPEG frame into a JPEG - they both use DCTs, don't they?

Yes, I believe the chip does have a way to provide raw frames.  The driver 
doesn't implement it, though this is on my longer term list of things to 
do.  I am told however that the frame format provided by the chip is 
different than what a V4L application is going to expect so there's some 
transformation that the driver needs to do to the data in order to make 
this work.

As for converting mpeg frame(s) into jpeg, I really have no idea.  Yes 
they both use similar compression techniques, but mpeg also does delta 
compression between the frames.  This means that converting a given 
instant in time to a jpeg may require finding the last key frame and 
building up from there.  Seems like there might be a utility somewhere for 
doing that - it's certainly outside the scope of the driver.


>
> - Motion detection: since I have limited bandwidth between the NSLU2 and
> the web server (wrong way on an asymetric cable modem), I'd like to
> record clips when something interesting happens.  This means doing
> motion detection, or similar, on the NSLU2.  I bet that the connexant
> chip internally has a good idea of an image activity metric, but we
> can't get at it.  There is a Linux program called "motion", but I think
> it needs an unencoded video source.  Is there a computationally-cheap
> way to do motion detection on an MPEG stream?  Maybe, if
> variable-bit-rate encoding is used, I could just look for a spike in the
> bit rate.  Any comments?

Yes, certainly in order to efficiently generate mpeg data, the Conexant 
chip has to be doing motion detection.  But it's all inside the part and I 
know of no way to access such information.

Looking for a spike in the bit rate might be a quick and dirty way to 
detect this.


>
> - The light level in the birdbox is rather low.  The camera has
> automatic gain control and the image looks OK, but it has the sort of
> noise you expect from a cheap sensor when it is being amplified a lot.
> The only problem with this is that it wastes bits in the MPEG stream.  I
> noticed that there are some noise reduction parameters in
> pvrusb2-encoder.c, but they don't seem to be exported to the /sys
> interface.  Is this what I need?

I need to update the controls exported from the driver.  I have a lot more 
information available about the chip now than I did when I first set all 
that up in sysfs.  It's another thing that needs to get done which hasn't 
happened yet.

   -Mike


-- 
                         |         Mike Isely          |     PGP fingerprint
      Spammers Die!!     |                             | 03 54 43 4D 75 E5 CC 92
                         |   isely @ pobox (dot) com   | 71 16 01 E2 B5 F5 C1 E8
                         |                             |