I have looked at motion.conf settings now, for ffmpeg video creation, and have successfully run each option – timelapse, ghost pixels and mpg – all with streaming as a simultaneous option - all at the same time and the Pi's coped! I'm impressed!
The cameras have identical format specs, but the Pi Noir has no Infra Red filter, so has a slightly redder tint to the video.
It was asking a lot for the Pi to run all options at once, I reckon, but they managed it at slightly different performance levels despite being technically identical for kernel, updates, firmware, raspi-conf settings etc.
The cameras v4l outputs are identical both for PiNoir and PiBlanc as I have named them. I have identical Share folders set up on each camera also to see the output files remotely. Running for each camera:
v4l2-ctl --all >> /Share/motion/NoirSpec.txt
v4l2-ctl --all >> /Share/motion/BlancSpec.txt
I diff'd the two files once copied to Mint, and got not differences:
MintRecPC stevee # diff Videos/BlancSpec.txt Videos/NoirSpec.txt
Driver Info (not using libv4l2):
Driver name : bm2835 mmal
Card type : mmal service 16.1
Bus info : platform:bcm2835-v4l2
Driver version: 3.18.11
Capabilities : 0x85200005
Device Caps : 0x05200005
Video input : 0 (Camera 0: ok)
Format Video Capture:
Width/Height : 320/240
Pixel Format : 'YUYV'
Field : None
Bytes per Line: 640
Size Image : 153600
Colorspace : Broadcast NTSC/PAL (SMPTE170M/ITU601)
Custom Info : feedcafe
Format Video Overlay:
Left/Top : 150/50
Field : None
Chroma Key : 0x00000000
Global Alpha: 0x00
Clip Count : 0
Clip Bitmap : No
Flags : Overlay Matches Capture/Output Size
Width : 320
Height : 240
Pixel Format : 'YU12'
Bytes per Line: 480
Size image : 115200
Colorspace : Broadcast NTSC/PAL (SMPTE170M/ITU601)
Streaming Parameters Video Capture:
Capabilities : timeperframe
Frames per second: 30.000 (30000/1000)
Read buffers : 1
brightness (int) : min=0 max=100 step=1 default=50 value=50 flags=slider
contrast (int) : min=-100 max=100 step=1 default=0 value=0 flags=slider
saturation (int) : min=-100 max=100 step=1 default=0 value=0 flags=slider
red_balance (int) : min=1 max=7999 step=1 default=1000 value=1000 flags=slider
blue_balance (int) : min=1 max=7999 step=1 default=1000 value=1000 flags=slider
horizontal_flip (bool) : default=0 value=0
vertical_flip (bool) : default=0 value=0
power_line_frequency (menu) : min=0 max=3 default=1 value=1
sharpness (int) : min=-100 max=100 step=1 default=0 value=0 flags=slider
color_effects (menu) : min=0 max=15 default=0 value=0
rotate (int) : min=0 max=360 step=90 default=0 value=0
color_effects_cbcr (int) : min=0 max=65535 step=1 default=32896 value=32896
video_bitrate_mode (menu) : min=0 max=1 default=0 value=0 flags=update
video_bitrate (int) : min=25000 max=25000000 step=25000 default=10000000 value=10000000
repeat_sequence_header (bool) : default=0 value=0
h264_i_frame_period (int) : min=0 max=2147483647 step=1 default=60 value=60
h264_level (menu) : min=0 max=11 default=11 value=11
h264_profile (menu) : min=0 max=4 default=4 value=4
auto_exposure (menu) : min=0 max=3 default=0 value=0
exposure_time_absolute (int) : min=1 max=10000 step=1 default=1000 value=1000
exposure_dynamic_framerate (bool) : default=0 value=0
auto_exposure_bias (intmenu): min=0 max=24 default=12 value=12
white_balance_auto_preset (menu) : min=0 max=9 default=1 value=1
image_stabilization (bool) : default=0 value=0
iso_sensitivity (intmenu): min=0 max=4 default=0 value=0
exposure_metering_mode (menu) : min=0 max=2 default=0 value=0
scene_mode (menu) : min=0 max=13 default=0 value=0
JPEG Compression Controls
compression_quality (int) : min=1 max=100 step=1 default=30 value=30
The Pi's were set next to each other, with (slight angle diffs due to the housings) and motion set running as a daemon almost exactly together to generate time lapses of the same scenes:
I found that one camera seemed to generate more jpg images in the Share folder than the other, but this may have been down to network conditions reading each Share contents differently. The videos are pretty identical except for tint and timestamp.
If you want to recursively remove all created pic and video content from the Share when testing, Raspbian rm command needs to be told to remove all files, else it will ask for confirmation for each file e.g.:
rm -vr --interactive=no /Share/motion/*.jpg
The conf file sections for these features are in the ffmpeg section e.g.:
# FFMPEG related options
# Film (mpeg) file output, and deinterlacing of the video input
# The options movie_filename and timelapse_filename are also used
# by the ffmpeg feature
# Use ffmpeg to encode mpeg movies in realtime (default: off)
# Use ffmpeg to make movies with only the pixels moving
# object (ghost images) (default: off)
# Use ffmpeg to encode a timelapse movie
# Default value 0 = off - else save frame every Nth second
# The file rollover mode of the timelapse video
# Valid values: hourly, daily (default), weekly-sunday, weekly-monday, monthly, manual
Be patient with the Pi's when expecting them to capture, stream AND create a stored video using the ffmpeg encoder, as I found a time lapse vid appeared in the Share after I had walked away for a while.
It's worth experimenting with the settings depending what you want, such as rollover hourly/daily... storage you need depending on how much storage space you have and what type of movies you want to create. You're SDRAM card and or network storage methods will decide this mainly, as it will have overhead costs on the Pi also – samba etc.
The live streaming to Firefox is very detailed from the 5 MP cameras, and I used a 1 second per jpg capture setting – which makes for good streaming and video creation quality, but there's loads yet to try with all this.
I viewed both camera streams simultaneously in 2 instances of Firefox to get:
The ripple is due to the screen snapshot not the camera images which are excellent.
All in all very interesting an a lot of fun – if very hard work to research initially from complete scratch.
Perms for Pi Motion Files/Folders that work - /Share/motion is where my vids/jpgs are saved, set in motion.conf:
ls -als /etc/init.d/motion
4 -rwxr-xr-x 1 root root 2410 Feb 12 2012 /etc/init.d/motion
ls -als /etc/motion/motion.conf
20 -rw-r----- 1 root motion 18647 Aug 20 16:54 /etc/motion/motion.conf
ls -als /Share/motion/
140 drwxrwxr-x 2 stevee motion 139264 Sep 3 19:24 .
4 drwxr-xr-x 4 stevee root 4096 Aug 30 07:05 ..
ls -als /etc/default/motion
4 -rw-r--r-- 1 root root 68 Aug 13 23:38 /etc/default/motion
To run motion from boot, both motion.conf and /default/motion have to have daemon=yes, and the start links have to be set via:
update-rc.d motion enable