In this earlear posting in this thread
viewtopic.php?f=43&t=109137&start=375#p1263896
I showed that full VGA capturing with raspiraw can be done without frame skips at 240fps, and sometimes even with 300fps.
Today I modified "tools/640x480" slightly for better statistics, new file attached here:
Code: Select all
$ diff ../tools/640x480 640x480
14c14,17
< echo "$l frames were captured at $((1000000 / $us))fps"
---
> start=`head -1 tstamps.csv | cut -f3 -d,`
> end=`tail -1 tstamps.csv | cut -f3 -d,`
> echo "$l frames were captured in $(($end-$start))us"
> echo "majority at $((1000000 / $us))fps, average at $(((1000000*$l)/($end-$start)))fps"
17c20
< cut -f1 -d, tstamps.csv | sort -n | uniq -c
---
> cut -f1 -d, tstamps.csv | sort -n | uniq -c | sed "s/^/</"
27c30,31
< echo "$per% frame skips"
---
> echo "$skips frame skips ($per%)"
> grep "^[$D]" tstamps.csv | cut -f1 -d, | sort -n | uniq -c | sed "s/^/|/"
$I did another setup with classic mouse trap, but this time the Lego piece does not trigger the mouse trap, but hangs to get hit by closing mouse trap. This is the command, excluding the delay distribution analysis and list of frame skips (by last grep):
Code: Select all
pi@raspberrypi02:~/raspiraw/t $ ./640x480 2800 420 | grep -v "^[<>]"
removing /dev/shm/out.*.raw
capturing frames for 2800ms with 420fps requested
1155 frames were captured in 2792271us
majority at 424fps, average at 413fps
frame delta time[us] distribution
after skip frame indices (middle column)
31 frame skips (2%)
| 5 4712
| 26 4713
pi@raspberrypi02:~/raspiraw/t $
The majority of frames is captured with delay corresponding 424fps.
Dividing total time taken (last timestamp minus first timestamp) by frames captured shows 413fps average framerate.
The capture was restricted to 2.8s because that just fits into /dev/shm ramdisk:
Code: Select all
pi@raspberrypi02:~/raspiraw/t $ df /dev/shm
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 448400 434280 14120 97% /dev/shm
pi@raspberrypi02:~/raspiraw/t $
This is the frame just before the closing mouse trap hits the Lego piece
(you can see the closing part of mouse trap washy right of Lego piece):
And this is 1st frame after hit:
Yes, only the top 640x215 area of the frame is correctly updated, in lower part two frames show up alternately. But as the statistics show the average framerate is 413fps, not bad for a 640x215 video.
I created .ogg video from all frames capture for playback at 25fps (for youtube upload):
Code: Select all
pi@raspberrypi02:~/raspiraw/t $ time ( raw2ogg2anim t 1 1126 25 )
removing old auxiliary files
...
done
real 51m36.653s
user 42m54.330s
sys 0m45.740s
The post processing for .ogg and .anim creation took 52min on a Pi 3B!
This is the .ogg video uploaded to youtube (2.8s corresponds to 45s at 25fps, plays slowed down by factor 413/25=16.52):
https://www.youtube.com/watch?v=QbgOGrz ... e=youtu.be
Lego piece is static from 0-10s, then moves from 10-12s, swings back into view from 22-28s, and again 32-40s and 44-45s. Pendulum is the reason Lego piece appears again and again.
Summary:
420fps requested framerate overloads v2 camera capabilities at 640x480.
But surprisingly gives clean 640x215 video in top part at >400fps average framerate.
P.S:
Browser view of scene short before final setup of raspiraw capture:
