[Nottingham] Webcam snapshots

[Duncan]

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?
>

Hi Martin,
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  
screenshot.jpg
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 
1  screenshot.png

(-ss T = delay T seconds before beginning recording, -vframes 1 = record 
1 frame)

_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 
1  screenshot.png
takes on average 4.25s (real).

time ffmpeg -f video4linux2 -i /dev/video0 -f image2 -y  -sameq -vframes 
1 /dev/null
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 
120  screenshot_%03d.jpg
(record 120 frames at 8 frames/second) shows no appreciable overhead.

This all  suggests that (at least here) the single frame overhead 
doesn't  come
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 
framerate if
you get down and dirty with C rather than looping in bash.

Have fun,
Duncan