[Nottingham] Webcam snapshots
notlug at pendinas.org.uk
Mon Sep 5 11:48:00 UTC 2011
On 05/09/11 10:25, Martin wrote:
> On 3 September 2011 10:12, Camilo Mesias<camilo at mesias.co.uk> wrote:
>> The obvious solution seems to be to upgrade the hardware to support
>> the number of devices you need, my gut feel is that one big box is
>> going to be the cheapest way to run several HD webcams at once. If you
>> need to scale to many more webcams or more locations then several
>> small networked boxes might be a possibility.
>> A barebones PC starting with a £40 motherboard should give onboard
>> everything including three PCI slots plus one onboard USB hub (that's
>> your 4 webcams sorted), you might be able to fit it in an existing PC
>> for a low cost upgrade.
>> It wlil also be easier to synchronise everything if it's on one PC
>> rather than spread over several networked devices.
> I started out on this thinking it should all be just plug'n'play and
> easy, not realising that webcams grab all of the USB2 bandwidth for
> themselves... So trying to keep to a software fix is preferred if it
> can be still kept simple...
> Is there a feature in UVC whereby a webcam can be set up but have it
> 'hibernate' or continue to run /without/ sending data so that you
> could have them 'streaming' but selectively stream only from the
> webcam of interest for that frame?
Can you use uvcdynctrl to reduce the camera framerate and/or resolution
so they do not saturate your USB2 ?
Also, a quick (local) analysis using a definitely-not-HD UVC camera...
ffmpeg -f video4linux2 -i /dev/video0 -f image2 -y -sameq -vframes 1
ffmpeg -f video4linux2 -i /dev/video0 -f image2 -y -ss 0.375 -sameq
-vframes 1 screenshot.jpg
ffmpeg -f video4linux2 -i /dev/video0 -f image2 -y -ss 1 -sameq -vframes
(-ss T = delay T seconds before beginning recording, -vframes 1 = record
_All_ take on average 1.7s (real) to run. If the overhead were in
setting up the camera
then you would expect the time to depend on the -ss delay - but it doesn't.
ffmpeg -f video4linux2 -i /dev/video0 -f image2 -y -ss 1.7 -sameq
-vframes 1 screenshot.png
takes on average 1.93s (real)
ffmpeg -f video4linux2 -i /dev/video0 -f image2 -y -ss 4 -sameq -vframes
takes on average 4.25s (real).
time ffmpeg -f video4linux2 -i /dev/video0 -f image2 -y -sameq -vframes
takes on average 1.64s (real) indicating a 0.06s disk+filesystem overhead.
ffmpeg -f video4linux2 -i /dev/video0 -f image2 -y -r 8 -sameq -vframes
(record 120 frames at 8 frames/second) shows no appreciable overhead.
This all suggests that (at least here) the single frame overhead
from camera initialization, nor does it come from the image encoding. It
isn't at all obvious where the overhead is coming from but if your
cameras are stable
by the 3rd or 4th frame (you lucky b*****d) then you may get a better
you get down and dirty with C rather than looping in bash.
More information about the Nottingham