[pvrusb2] NSLU2 + PVRUSB2 = Bird-Box Cam
isely at isely.net
Mon Feb 6 07:36:37 CST 2006
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
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
> - 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
| 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
More information about the pvrusb2