Recherche avancée

Sur d’autres sites (6848)

• How to get .mp4 videos from motion on a Raspberry Pi ?

  9 octobre 2016, par Maarti

  I use motion on my laptop and it works perfectly in any format. But when I use it on my Raspberry Pi 3 (Raspbian Jessie) with the Raspberry Camera V2, the only formats that work are : .avi and .swf.

  When I choose any other format, the output video is a "0 sec video" that is played and closed instantly.

  I would like to have .mp4 or .ogg output so I can read it easily with HTML5.

  Here is the motion codec documentation.

  Here is my config file :

  ############################################################
  
  # Daemon
  
  ############################################################
  
  
  
  # Start in daemon (background) mode and release terminal (default: off)
  
  daemon on
  
  
  
  # File to store the process ID, also called pid file. (default: not defined)
  
  process_id_file /var/run/motion/motion.pid
  
  
  
  ############################################################
  
  # Basic Setup Mode
  
  ############################################################
  
  
  
  # Start in Setup-Mode, daemon disabled. (default: off)
  
  setup_mode off
  
  
  
  
  
  # Use a file to save logs messages, if not defined stderr and syslog is used. (default: not defined)
  
  #logfile /mnt/camshare/Cam1/motion.log
  
  logfile /tmp/motion.log
  
  
  
  # Level of log messages [1..9] (EMR, ALR, CRT, ERR, WRN, NTC, INF, DBG, ALL). (default: 6 / NTC)
  
  log_level 2
  
  
  
  # Filter to log messages by type (COR, STR, ENC, NET, DBL, EVT, TRK, VID, ALL). (default: ALL)
  
  log_type all
  
  
  
  ###########################################################
  
  # Capture device options
  
  ############################################################
  
  
  
  # Videodevice to be used for capturing  (default /dev/video0)
  
  # for FreeBSD default is /dev/bktr0
  
  #videodevice /dev/video0
  
  
  
  # v4l2_palette allows to choose preferable palette to be use by motion
  
  # to capture from those supported by your videodevice. (default: 17)
  
  # E.g. if your videodevice supports both V4L2_PIX_FMT_SBGGR8 and
  
  # V4L2_PIX_FMT_MJPEG then motion will by default use V4L2_PIX_FMT_MJPEG.
  
  # Setting v4l2_palette to 2 forces motion to use V4L2_PIX_FMT_SBGGR8
  
  # instead.
  
  #
  
  # Values :
  
  # V4L2_PIX_FMT_SN9C10X : 0  'S910'
  
  # V4L2_PIX_FMT_SBGGR16 : 1  'BYR2'
  
  # V4L2_PIX_FMT_SBGGR8  : 2  'BA81'
  
  # V4L2_PIX_FMT_SPCA561 : 3  'S561'
  
  # V4L2_PIX_FMT_SGBRG8  : 4  'GBRG'
  
  # V4L2_PIX_FMT_SGRBG8  : 5  'GRBG'
  
  # V4L2_PIX_FMT_PAC207  : 6  'P207'
  
  # V4L2_PIX_FMT_PJPG    : 7  'PJPG'
  
  # V4L2_PIX_FMT_MJPEG   : 8  'MJPEG'
  
  # V4L2_PIX_FMT_JPEG    : 9  'JPEG'
  
  # V4L2_PIX_FMT_RGB24   : 10 'RGB3'
  
  # V4L2_PIX_FMT_SPCA501 : 11 'S501'
  
  # V4L2_PIX_FMT_SPCA505 : 12 'S505'
  
  # V4L2_PIX_FMT_SPCA508 : 13 'S508'
  
  # V4L2_PIX_FMT_UYVY    : 14 'UYVY'
  
  # V4L2_PIX_FMT_YUYV    : 15 'YUYV'
  
  # V4L2_PIX_FMT_YUV422P : 16 '422P'
  
  # V4L2_PIX_FMT_YUV420  : 17 'YU12'
  
  #
  
  v4l2_palette 7
  
  
  
  # Tuner device to be used for capturing using tuner as source (default /dev/tuner0)
  
  # This is ONLY used for FreeBSD. Leave it commented out for Linux
  
  ; tunerdevice /dev/tuner0
  
  
  
  # The video input to be used (default: -1)
  
  # Should normally be set to 0 or 1 for video/TV cards, and -1 for USB cameras
  
  input -1
  
  
  
  # The video norm to use (only for video capture and TV tuner cards)
  
  # Values: 0 (PAL), 1 (NTSC), 2 (SECAM), 3 (PAL NC no colour). Default: 0 (PAL)
  
  norm 0
  
  
  
  # The frequency to set the tuner to (kHz) (only for TV tuner cards) (default: 0)
  
  frequency 0
  
  
  
  # Rotate image this number of degrees. The rotation affects all saved images as
  
  # well as movies. Valid values: 0 (default = no rotation), 90, 180 and 270.
  
  rotate 0
  
  
  
  # Image width (pixels). Valid range: Camera dependent, default: 352
  
  #width 1024
  
  width 640
  
  
  
  # Image height (pixels). Valid range: Camera dependent, default: 288
  
  #height 576
  
  height 480
  
  
  
  # Maximum number of frames to be captured per second.
  
  # Valid range: 2-100. Default: 100 (almost no limit).
  
  framerate 15
  
  
  
  # Minimum time in seconds between capturing picture frames from the camera.
  
  # Default: 0 = disabled - the capture rate is given by the camera framerate.
  
  # This option is used when you want to capture images at a rate lower than 2 per second.
  
  minimum_frame_time 0
  
  
  
  # URL to use if you are using a network camera, size will be autodetected (incl http:// ftp:// mjpg:// or file:///)
  
  # Must be a URL that returns single jpeg pictures or a raw mjpeg stream. Default: Not defined
  
  ;netcam_url http://127.0.0.1/cgi-bin/raspicam.sh
  
  
  
  # Username and password for network camera (only if required). Default: not defined
  
  # Syntax is user:password
  
  ; netcam_userpass value
  
  
  
  # The setting for keep-alive of network socket, should improve performance on compatible net cameras.
  
  # off:   The historical implementation using HTTP/1.0, closing the socket after each http request.
  
  # force: Use HTTP/1.0 requests with keep alive header to reuse the same connection.
  
  # on:    Use HTTP/1.1 requests that support keep alive as default.
  
  # Default: off
  
  netcam_keepalive off
  
  
  
  # URL to use for a netcam proxy server, if required, e.g. "http://myproxy".
  
  # If a port number other than 80 is needed, use "http://myproxy:1234".
  
  # Default: not defined
  
  ; netcam_proxy value
  
  
  
  # Set less strict jpeg checks for network cameras with a poor/buggy firmware.
  
  # Default: off
  
  netcam_tolerant_check off
  
  
  
  # Let motion regulate the brightness of a video device (default: off).
  
  # The auto_brightness feature uses the brightness option as its target value.
  
  # If brightness is zero auto_brightness will adjust to average brightness value 128.
  
  # Only recommended for cameras without auto brightness
  
  auto_brightness off
  
  
  
  # Set the initial brightness of a video device.
  
  # If auto_brightness is enabled, this value defines the average brightness level
  
  # which Motion will try and adjust to.
  
  # Valid range 0-255, default 0 = disabled
  
  brightness 0
  
  
  
  # Set the contrast of a video device.
  
  # Valid range 0-255, default 0 = disabled
  
  contrast 0
  
  
  
  # Set the saturation of a video device.
  
  # Valid range 0-255, default 0 = disabled
  
  saturation 0
  
  
  
  # Set the hue of a video device (NTSC feature).
  
  # Valid range 0-255, default 0 = disabled
  
  hue 0
  
  
  
  ############################################################
  
  # File "camera" support - read raw YUV data from a file
  
  ############################################################
  
  #filecam_path /home/pi/test-cap/motion-mmal.capture
  
  
  
  ############################################################
  
  # OpenMax/MMAL camera support for Raspberry Pi
  
  ############################################################
  
  mmalcam_name vc.ril.camera
  
  #mmalcam_control_params
  
  #mmalcam_raw_capture_file /home/pi/motion-mmal.capture
  
  
  
  # Switch this setting to "on" to use the still image mode of the Pi's camera
  
  # instead of video. This gives a wider field of view, but requires
  
  # a much slower frame-rate to achieve exposure stability
  
  # (e.g. 0.25 fps or slower). You can use the minimum_frame_time
  
  # parameter above to achieve this
  
  
  
  mmalcam_use_still off
  
  
  
  
  
  ############################################################
  
  # Round Robin (multiple inputs on same video device name)
  
  ############################################################
  
  
  
  # Number of frames to capture in each roundrobin step (default: 1)
  
  roundrobin_frames 1
  
  
  
  # Number of frames to skip before each roundrobin step (default: 1)
  
  roundrobin_skip 1
  
  
  
  # Try to filter out noise generated by roundrobin (default: off)
  
  switchfilter off
  
  
  
  
  
  ############################################################
  
  # Motion Detection Settings:
  
  ############################################################
  
  
  
  # Threshold for number of changed pixels in an image that
  
  # triggers motion detection (default: 1500)
  
  threshold 1500
  
  
  
  # Automatically tune the threshold down if possible (default: off)
  
  threshold_tune off
  
  
  
  # Noise threshold for the motion detection (default: 32)
  
  noise_level 32
  
  
  
  # Automatically tune the noise threshold (default: on)
  
  noise_tune on
  
  
  
  # Despeckle motion image using (e)rode or (d)ilate or (l)abel (Default: not defined)
  
  # Recommended value is EedDl. Any combination (and number of) of E, e, d, and D is valid.
  
  # (l)abeling must only be used once and the 'l' must be the last letter.
  
  # Comment out to disable
  
  despeckle_filter EedDl
  
  
  
  # Detect motion in predefined areas (1 - 9). Areas are numbered like that:  1 2 3
  
  # A script (on_area_detected) is started immediately when motion is         4 5 6
  
  # detected in one of the given areas, but only once during an event.        7 8 9
  
  # One or more areas can be specified with this option. Take care: This option
  
  # does NOT restrict detection to these areas! (Default: not defined)
  
  ; area_detect value
  
  
  
  # PGM file to use as a sensitivity mask.
  
  # Full path name to. (Default: not defined)
  
  ; mask_file value
  
  
  
  # Dynamically create a mask file during operation (default: 0)
  
  # Adjust speed of mask changes from 0 (off) to 10 (fast)
  
  smart_mask_speed 0
  
  
  
  # Ignore sudden massive light intensity changes given as a percentage of the picture
  
  # area that changed intensity. Valid range: 0 - 100 , default: 0 = disabled
  
  lightswitch 0
  
  
  
  # Picture frames must contain motion at least the specified number of frames
  
  # in a row before they are detected as true motion. At the default of 1, all
  
  # motion is detected. Valid range: 1 to thousands, recommended 1-5
  
  minimum_motion_frames 1
  
  
  
  # Specifies the number of pre-captured (buffered) pictures from before motion
  
  # was detected that will be output at motion detection.
  
  # Recommended range: 0 to 5 (default: 0)
  
  # Do not use large values! Large values will cause Motion to skip video frames and
  
  # cause unsmooth movies. To smooth movies use larger values of post_capture instead.
  
  pre_capture 2
  
  
  
  # Number of frames to capture after motion is no longer detected (default: 0)
  
  post_capture 2
  
  
  
  # Event Gap is the seconds of no motion detection that triggers the end of an event.
  
  # An event is defined as a series of motion images taken within a short timeframe.
  
  # Recommended value is 60 seconds (Default). The value -1 is allowed and disables
  
  # events causing all Motion to be written to one single movie file and no pre_capture.
  
  # If set to 0, motion is running in gapless mode. Movies don't have gaps anymore. An
  
  # event ends right after no more motion is detected and post_capture is over.
  
  event_gap 60
  
  
  
  # Maximum length in seconds of an mpeg movie
  
  # When value is exceeded a new movie file is created. (Default: 0 = infinite)
  
  # ATTENTION: when you're not using the motion build from the tutorial, it might fail with error 'Unknown config option "max_mpeg_time"'
  
  # the use this line instead:
  
  # max_movie_time 60
  
  max_movie_time 60
  
  
  
  # Always save images even if there was no motion (default: off)
  
  emulate_motion off
  
  
  
  
  
  ############################################################
  
  # Image File Output
  
  ############################################################
  
  
  
  # Output 'normal' pictures when motion is detected (default: on)
  
  # Valid values: on, off, first, best, center
  
  # When set to 'first', only the first picture of an event is saved.
  
  # Picture with most motion of an event is saved when set to 'best'.
  
  # Picture with motion nearest center of picture is saved when set to 'center'.
  
  # Can be used as preview shot for the corresponding movie.
  
  output_pictures best
  
  
  
  # Output pictures with only the pixels moving object (ghost images) (default: off)
  
  output_debug_pictures off
  
  
  
  # The quality (in percent) to be used by the jpeg compression (default: 75)
  
  quality 75
  
  
  
  # Type of output images
  
  # Valid values: jpeg, ppm (default: jpeg)
  
  picture_type jpeg
  
  
  
  ############################################################
  
  # FFMPEG related options
  
  # Film (movies) 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 movies in realtime (default: off)
  
  ffmpeg_output_movies on
  
  
  
  # Use ffmpeg to make movies with only the pixels moving
  
  # object (ghost images) (default: off)
  
  ffmpeg_output_debug_movies off
  
  
  
  # Use ffmpeg to encode a timelapse movie
  
  # Default value 0 = off - else save frame every Nth second
  
  ffmpeg_timelapse 0
  
  
  
  # The file rollover mode of the timelapse video
  
  # Valid values: hourly, daily (default), weekly-sunday, weekly-monday, monthly, manual
  
  ffmpeg_timelapse_mode daily
  
  
  
  # Bitrate to be used by the ffmpeg encoder (default: 400000)
  
  # This option is ignored if ffmpeg_variable_bitrate is not 0 (disabled)
  
  ffmpeg_bps 500000
  
  
  
  # Enables and defines variable bitrate for the ffmpeg encoder.
  
  # ffmpeg_bps is ignored if variable bitrate is enabled.
  
  # Valid values: 0 (default) = fixed bitrate defined by ffmpeg_bps,
  
  # or the range 2 - 31 where 2 means best quality and 31 is worst.
  
  ffmpeg_variable_bitrate 5
  
  
  
  # Codec to used by ffmpeg for the video compression.
  
  # Timelapse mpegs are always made in mpeg1 format independent from this option.
  
  # Supported formats are: mpeg1 (ffmpeg-0.4.8 only), mpeg4 (default), and msmpeg4.
  
  # mpeg1 - gives you files with extension .mpg
  
  # mpeg4 or msmpeg4 - gives you files with extension .avi
  
  # msmpeg4 is recommended for use with Windows Media Player because
  
  # it requires no installation of codec on the Windows client.
  
  # swf - gives you a flash film with extension .swf
  
  # flv - gives you a flash video with extension .flv
  
  # ffv1 - FF video codec 1 for Lossless Encoding ( experimental )
  
  # mov - QuickTime ( testing )
  
  # ogg - Ogg/Theora ( testing )
  
  #ffmpeg_video_codec msmpeg4
  
  ffmpeg_video_codec mp4
  
  
  
  # Use ffmpeg to deinterlace video. Necessary if you use an analog camera
  
  # and see horizontal combing on moving objects in video or pictures.
  
  # (default: off)
  
  ffmpeg_deinterlace off
  
  
  
  ############################################################
  
  # SDL Window
  
  ############################################################
  
  
  
  # Number of motion thread to show in SDL Window (default: 0 = disabled)
  
  #sdl_threadnr 0
  
  
  
  ############################################################
  
  # External pipe to video encoder
  
  # Replacement for FFMPEG builtin encoder for ffmpeg_output_movies only.
  
  # The options movie_filename and timelapse_filename are also used
  
  # by the ffmpeg feature
  
  #############################################################
  
  
  
  # Bool to enable or disable extpipe (default: off)
  
  use_extpipe off
  
  
  
  # External program (full path and opts) to pipe raw video to
  
  # Generally, use '-' for STDIN...
  
  ;extpipe mencoder -demuxer rawvideo -rawvideo w=320:h=240:i420 -ovc x264 -x264encopts bframes=4:frameref=1:subq=1:scenecut=-1:nob_adapt:threads=1:keyint=1000:8x8dct:vbv_bufsize=4000:crf=24:partitions=i8x8,i4x4:vbv_maxrate=800:no-chroma-me -vf denoise3d=16:12:48:4,pp=lb -of   avi -o %f.avi - -fps %fps
  
  
  
  
  
  
  
  ############################################################
  
  # Snapshots (Traditional Periodic Webcam File Output)
  
  ############################################################
  
  
  
  # Make automated snapshot every N seconds (default: 0 = disabled)
  
  snapshot_interval 0
  
  
  
  
  
  ############################################################
  
  # Text Display
  
  # %Y = year, %m = month, %d = date,
  
  # %H = hour, %M = minute, %S = second, %T = HH:MM:SS,
  
  # %v = event, %q = frame number, %t = thread (camera) number,
  
  # %D = changed pixels, %N = noise level, \n = new line,
  
  # %i and %J = width and height of motion area,
  
  # %K and %L = X and Y coordinates of motion center
  
  # %C = value defined by text_event - do not use with text_event!
  
  # You can put quotation marks around the text to allow
  
  # leading spaces
  
  ############################################################
  
  
  
  # Locate and draw a box around the moving object.
  
  # Valid values: on, off, preview (default: off)
  
  # Set to 'preview' will only draw a box in preview_shot pictures.
  
  locate_motion_mode off
  
  
  
  # Set the look and style of the locate box if enabled.
  
  # Valid values: box, redbox, cross, redcross (default: box)
  
  # Set to 'box' will draw the traditional box.
  
  # Set to 'redbox' will draw a red box.
  
  # Set to 'cross' will draw a little cross to mark center.
  
  # Set to 'redcross' will draw a little red cross to mark center.
  
  locate_motion_style box
  
  
  
  # Draws the timestamp using same options as C function strftime(3)
  
  # Default: %Y-%m-%d\n%T = date in ISO format and time in 24 hour clock
  
  # Text is placed in lower right corner
  
  text_right %d.%m.%Y\n%T
  
  
  
  # Draw a user defined text on the images using same options as C function strftime(3)
  
  # Default: Not defined = no text
  
  # Text is placed in lower left corner
  
  ; text_left CAMERA %t
  
  text_left HofCam
  
  
  
  # Draw the number of changed pixed on the images (default: off)
  
  # Will normally be set to off except when you setup and adjust the motion settings
  
  # Text is placed in upper right corner
  
  text_changes off
  
  
  
  # This option defines the value of the special event conversion specifier %C
  
  # You can use any conversion specifier in this option except %C. Date and time
  
  # values are from the timestamp of the first image in the current event.
  
  # Default: %Y%m%d%H%M%S
  
  # The idea is that %C can be used filenames and text_left/right for creating
  
  # a unique identifier for each event.
  
  text_event %Y%m%d%H%M%S
  
  
  
  # Draw characters at twice normal size on images. (default: off)
  
  text_double on
  
  
  
  
  
  # Text to include in a JPEG EXIF comment
  
  # May be any text, including conversion specifiers.
  
  # The EXIF timestamp is included independent of this text.
  
  ;exif_text %i%J/%K%L
  
  
  
  ############################################################
  
  # Target Directories and filenames For Images And Films
  
  # For the options snapshot_, picture_, movie_ and timelapse_filename
  
  # you can use conversion specifiers
  
  # %Y = year, %m = month, %d = date,
  
  # %H = hour, %M = minute, %S = second,
  
  # %v = event, %q = frame number, %t = thread (camera) number,
  
  # %D = changed pixels, %N = noise level,
  
  # %i and %J = width and height of motion area,
  
  # %K and %L = X and Y coordinates of motion center
  
  # %C = value defined by text_event
  
  # Quotation marks round string are allowed.
  
  ############################################################
  
  
  
  # Target base directory for pictures and films
  
  # Recommended to use absolute path. (Default: current working directory)
  
  target_dir /home/pi
  
  
  
  # File path for snapshots (jpeg or ppm) relative to target_dir
  
  # Default: %v-%Y%m%d%H%M%S-snapshot
  
  # Default value is equivalent to legacy oldlayout option
  
  # For Motion 3.0 compatible mode choose: %Y/%m/%d/%H/%M/%S-snapshot
  
  # File extension .jpg or .ppm is automatically added so do not include this.
  
  # Note: A symbolic link called lastsnap.jpg created in the target_dir will always
  
  # point to the latest snapshot, unless snapshot_filename is exactly 'lastsnap'
  
  snapshot_filename %v-%Y%m%d%H%M%S-snapshot
  
  
  
  # File path for motion triggered images (jpeg or ppm) relative to target_dir
  
  # Default: %v-%Y%m%d%H%M%S-%q
  
  # Default value is equivalent to legacy oldlayout option
  
  # For Motion 3.0 compatible mode choose: %Y/%m/%d/%H/%M/%S-%q
  
  # File extension .jpg or .ppm is automatically added so do not include this
  
  # Set to 'preview' together with best-preview feature enables special naming
  
  # convention for preview shots. See motion guide for details
  
  picture_filename %v-%Y%m%d%H%M%S-%q
  
  
  
  # File path for motion triggered ffmpeg films (movies) relative to target_dir
  
  # Default: %v-%Y%m%d%H%M%S
  
  # Default value is equivalent to legacy oldlayout option
  
  # For Motion 3.0 compatible mode choose: %Y/%m/%d/%H%M%S
  
  # File extension .mpg or .avi is automatically added so do not include this
  
  # This option was previously called ffmpeg_filename
  
  movie_filename %v-%Y%m%d%H%M%S
  
  
  
  # File path for timelapse movies relative to target_dir
  
  # Default: %Y%m%d-timelapse
  
  # Default value is near equivalent to legacy oldlayout option
  
  # For Motion 3.0 compatible mode choose: %Y/%m/%d-timelapse
  
  # File extension .mpg is automatically added so do not include this
  
  timelapse_filename %Y%m%d-timelapse
  
  
  
  ############################################################
  
  # Global Network Options
  
  ############################################################
  
  # Enable or disable IPV6 for http control and stream (default: off )
  
  ipv6_enabled off
  
  
  
  ############################################################
  
  # Live Stream Server
  
  ############################################################
  
  
  
  # The mini-http server listens to this port for requests (default: 0 = disabled)
  
  stream_port 8080
  
  
  
  # Quality of the jpeg (in percent) images produced (default: 50)
  
  stream_quality 50
  
  
  
  # Output frames at 1 fps when no motion is detected and increase to the
  
  # rate given by stream_maxrate when motion is detected (default: off)
  
  stream_motion on
  
  
  
  # Maximum framerate for stream streams (default: 1)
  
  stream_maxrate 4
  
  
  
  # Restrict stream connections to localhost only (default: on)
  
  stream_localhost off
  
  
  
  # Limits the number of images per connection (default: 0 = unlimited)
  
  # Number can be defined by multiplying actual stream rate by desired number of seconds
  
  # Actual stream rate is the smallest of the numbers framerate and stream_maxrate
  
  stream_limit 0
  
  
  
  # Set the authentication method (default: 0)
  
  # 0 = disabled
  
  # 1 = Basic authentication
  
  # 2 = MD5 digest (the safer authentication)
  
  stream_auth_method 0
  
  
  
  # Authentication for the stream. Syntax username:password
  
  # Default: not defined (Disabled)
  
  ; stream_authentication username:password
  
  
  
  
  
  ############################################################
  
  # HTTP Based Control
  
  ############################################################
  
  
  
  # TCP/IP port for the http server to listen on (default: 0 = disabled)
  
  webcontrol_port 8081
  
  
  
  # Restrict control connections to localhost only (default: on)
  
  webcontrol_localhost off
  
  
  
  # Output for http server, select off to choose raw text plain (default: on)
  
  webcontrol_html_output on
  
  
  
  # Authentication for the http based control. Syntax username:password
  
  # Default: not defined (Disabled)
  
  ; webcontrol_authentication username:password
  
  
  
  
  
  ############################################################
  
  # Tracking (Pan/Tilt)
  
  #############################################################
  
  
  
  # Type of tracker (0=none (default), 1=stepper, 2=iomojo, 3=pwc, 4=generic, 5=uvcvideo, 6=servo)
  
  # The generic type enables the definition of motion center and motion size to
  
  # be used with the conversion specifiers for options like on_motion_detected
  
  track_type 0
  
  
  
  # Enable auto tracking (default: off)
  
  track_auto off
  
  
  
  # Serial port of motor (default: none)
  
  ;track_port /dev/ttyS0
  
  
  
  # Motor number for x-axis (default: 0)
  
  ;track_motorx 0
  
  
  
  # Set motorx reverse (default: 0)
  
  ;track_motorx_reverse 0
  
  
  
  # Motor number for y-axis (default: 0)
  
  ;track_motory 1
  
  
  
  # Set motory reverse (default: 0)
  
  ;track_motory_reverse 0
  
  
  
  # Maximum value on x-axis (default: 0)
  
  ;track_maxx 200
  
  
  
  # Minimum value on x-axis (default: 0)
  
  ;track_minx 50
  
  
  
  # Maximum value on y-axis (default: 0)
  
  ;track_maxy 200
  
  
  
  # Minimum value on y-axis (default: 0)
  
  ;track_miny 50
  
  
  
  # Center value on x-axis (default: 0)
  
  ;track_homex 128
  
  
  
  # Center value on y-axis (default: 0)
  
  ;track_homey 128
  
  
  
  # ID of an iomojo camera if used (default: 0)
  
  track_iomojo_id 0
  
  
  
  # Angle in degrees the camera moves per step on the X-axis
  
  # with auto-track (default: 10)
  
  # Currently only used with pwc type cameras
  
  track_step_angle_x 10
  
  
  
  [...]

• The use cases for a element in HTML

  1er janvier 2014, par silvia

  The W3C HTML WG and the WHATWG are currently discussing the introduction of a <main> element into HTML.

  The <main> element has been proposed by Steve Faulkner and is specified in a draft extension spec which is about to be accepted as a FPWD (first public working draft) by the W3C HTML WG. This implies that the W3C HTML WG will be looking for implementations and for feedback by implementers on this spec.

  I am supportive of the introduction of a <main> element into HTML. However, I believe that the current spec and use case list don’t make a good enough case for its introduction. Here are my thoughts.

  Main use case : accessibility

  In my opinion, the main use case for the introduction of <main> is accessibility.

  Like any other users, when blind users want to perceive a Web page/application, they need to have a quick means of grasping the content of a page. Since they cannot visually scan the layout and thus determine where the main content is, they use accessibility technology (AT) to find what is known as “landmarks”.

  “Landmarks” tell the user what semantic content is on a page : a header (such as a banner), a search box, a navigation menu, some asides (also called complementary content), a footer, …. and the most important part : the main content of the page. It is this main content that a blind user most often wants to skip to directly.

  In the days of HTML4, a hidden “skip to content” link at the beginning of the Web page was used as a means to help blind users access the main content.

  In the days of ARIA, the aria @role=main enables authors to avoid a hidden link and instead mark the element where the main content begins to allow direct access to the main content. This attribute is supported by AT – in particular screen readers – by making it part of the landmarks that AT can directly skip to.

  Both the hidden link and the ARIA @role=main approaches are, however, band aids : they are being used by those of us that make “finished” Web pages accessible by adding specific extra markup.

  A world where ARIA is not necessary and where accessibility developers would be out of a job because the normal markup that everyone writes already creates accessible Web sites/applications would be much preferable over the current world of band-aids.

  Therefore, to me, the primary use case for a <main> element is to achieve exactly this better world and not require specialized markup to tell a user (or a tool) where the main content on a page starts.

  An immediate effect would be that pages that have a <main> element will expose a “main” landmark to blind and vision-impaired users that will enable them to directly access that main content on the page without having to wade through other text on the page. Without a <main> element, this functionality can currently only be provided using heuristics to skip other semantic and structural elements and is for this reason not typically implemented in AT.

  Other use cases

  The <main> element is a semantic element not unlike other new semantic elements such as <header>, <footer>, <aside>, <article>, <nav>, or <section>. Thus, it can also serve other uses where the main content on a Web page/Web application needs to be identified.

  Data mining

  For data mining of Web content, the identification of the main content is one of the key challenges. Many scholarly articles have been published on this topic. This stackoverflow article references and suggests a multitude of approaches, but the accepted answer says “there’s no way to do this that’s guaranteed to work”. This is because Web pages are inherently complex and many <div>, <p>, <iframe> and other elements are used to provide markup for styling, notifications, ads, analytics and other use cases that are necessary to make a Web page complete, but don’t contribute to what a user consumes as semantically rich content. A <main> element will allow authors to pro-actively direct data mining tools to the main content.

  Search engines

  One particularly important “data mining” tool are search engines. They, too, have a hard time to identify which sections of a Web page are more important than others and employ many heuristics to do so, see e.g. this ACM article. Yet, they still disappoint with poor results pointing to findings of keywords in little relevant sections of a page rather than ranking Web pages higher where the keywords turn up in the main content area. A <main> element would be able to help search engines give text in main content areas a higher weight and prefer them over other areas of the Web page. It would be able to rank different Web pages depending on where on the page the search words are found. The <main> element will be an additional hint that search engines will digest.

  Visual focus

  On small devices, the display of Web pages designed for Desktop often causes confusion as to where the main content can be found and read, in particular when the text ends up being too small to be readable. It would be nice if browsers on small devices had a functionality (maybe a default setting) where Web pages would start being displayed as zoomed in on the main content. This could alleviate some of the headaches of responsive Web design, where the recommendation is to show high priority content as the first content. Right now this problem is addressed through stylesheets that re-layout the page differently depending on device, but again this is a band-aid solution. Explicit semantic markup of the main content can solve this problem more elegantly.

  Styling

  Finally, naturally, <main> would also be used to style the main content differently from others. You can e.g. replace a semantically meaningless <div id=”main”> with a semantically meaningful <main> where their position is identical. My analysis below shows, that this is not always the case, since oftentimes <div id=”main”> is used to group everything together that is not the header – in particular where there are multiple columns. Thus, the ease of styling a <main> element is only a positive side effect and not actually a real use case. It does make it easier, however, to adapt the style of the main content e.g. with media queries.

  Proposed alternative solutions

  It has been proposed that existing markup serves to satisfy the use cases that <main> has been proposed for. Let’s analyse these on some of the most popular Web sites. First let’s list the propsed algorithms.

  Proposed solution No 1 : Scooby-Doo

  On Sat, Nov 17, 2012 at 11:01 AM, Ian Hickson <ian@hixie.ch> wrote :
  | The main content is whatever content isn’t
  | marked up as not being main content (anything not marked up with <header>,
  | <aside>, <nav>, etc).
  

  This implies that the first element that is not a <header>, <aside>, <nav>, or <footer> will be the element that we want to give to a blind user as the location where they should start reading. The algorithm is implemented in https://gist.github.com/4032962.

  Proposed solution No 2 : First article element

  On Sat, Nov 17, 2012 at 8:01 AM, Ian Hickson  wrote :
  | On Thu, 15 Nov 2012, Ian Yang wrote :
  | >
  | > That’s a good idea. We really need an element to wrap all the <p>s,
  | > <ul>s, <ol>s, <figure>s, <table>s ... etc of a blog post.
  |
  | That’s called <article>.
  

  This approach identifies the first <article> element on the page as containing the main content. Here’s the algorithm for this approach.

  Proposed solution No 3 : An example heuristic approach

  The readability plugin has been developed to make Web pages readable by essentially removing all the non-main content from a page. An early source of readability is available. This demonstrates what a heuristic approach can perform.

  Analysing alternative solutions

  Comparison

  I’ve picked 4 typical Websites (top on Alexa) to analyse how these three different approaches fare. Ideally, I’d like to simply apply the above three scripts and compare pictures. However, since the semantic HTML5 elements <header>, <aside>, <nav>, and <footer> are not actually used by any of these Web sites, I don’t actually have this choice.

  So, instead, I decided to make some assumptions of where these semantic elements would be used and what the outcome of applying the first two algorithms would be. I can then compare it to the third, which is a product so we can take screenshots.

  Google.com

  http://google.com – search for “Scooby Doo”.

  The search results page would likely be built with :

  • a <nav> menu for the Google bar
  • a <header> for the search bar
  • another <header> for the login section
  • another <nav> menu for the search types
  • a <div> to contain the rest of the page
  • a <div> for the app bar with the search number
  • a few <aside>s for the left and right column
  • a set of <article>s for the search results

  “Scooby Doo” would find the first element after the headers as the “main content”. This is the element before the app bar in this case. Interestingly, there is a <div @id=main> already in the current Google results page, which “Scooby Doo” would likely also pick. However, there are a nav bar and two asides in this div, which clearly should not be part of the “main content”. Google actually placed a @role=main on a different element, namely the one that encapsulates all the search results.

  “First Article” would find the first search result as the “main content”. While not quite the same as what Google intended – namely all search results – it is close enough to be useful.

  The “readability” result is interesting, since it is not able to identify the main text on the page. It is actually aware of this problem and brings a warning before displaying this page :

  

  Facebook.com

  https://facebook.com

  A user page would likely be built with :

  • a <header> bar for the search and login bar
  • a <div> to contain the rest of the page
  • an <aside> for the left column
  • a <div> to contain the center and right column
  • an <aside> for the right column
  • a <header> to contain the center column “megaphone”
  • a <div> for the status posting
  • a set of <article>s for the home stream

  “Scooby Doo” would find the first element after the headers as the “main content”. This is the element that contains all three columns. It’s actually a <div @id=content> already in the current Facebook user page, which “Scooby Doo” would likely also pick. However, Facebook selected a different element to place the @role=main : the center column.

  “First Article” would find the first news item in the home stream. This is clearly not what Facebook intended, since they placed the @role=main on the center column, above the first blog post’s title. “First Article” would miss that title and the status posting.

  The “readability” result again disappoints but warns that it failed :

  

  YouTube.com

  http://youtube.com

  A video page would likely be built with :

  • a <header> bar for the search and login bar
  • a <nav> for the menu
  • a <div> to contain the rest of the page
  • a <header> for the video title and channel links
  • a <div> to contain the video with controls
  • a <div> to contain the center and right column
  • an <aside> for the right column with an <article> per related video
  • an <aside> for the information below the video
  • a <article> per comment below the video

  “Scooby Doo” would find the first element after the headers as the “main content”. This is the element that contains the rest of the page. It’s actually a <div @id=content> already in the current YouTube video page, which “Scooby Doo” would likely also pick. However, YouTube’s related videos and comments are unlikely to be what the user would regard as “main content” – it’s the video they are after, which generously has a <div id=watch-player>.

  “First Article” would find the first related video or comment in the home stream. This is clearly not what YouTube intends.

  The “readability” result is not quite as unusable, but still very bare :

  

  Wikipedia.com

  http://wikipedia.com (“Overscan” page)

  A Wikipedia page would likely be built with :

  • a <header> bar for the search, login and menu items
  • a <div> to contain the rest of the page
  • an &ls ; article> with title and lots of text
  • <article> an <aside> with the table of contents
  • several <aside>s for the left column

  Good news : “Scooby Doo” would find the first element after the headers as the “main content”. This is the element that contains the rest of the page. It’s actually a <div id=”content” role=”main”> element on Wikipedia, which “Scooby Doo” would likely also pick.

  “First Article” would find the title and text of the main element on the page, but it would also include an <aside>.

  The “readability” result is also in agreement.

  

  Results

  In the following table we have summarised the results for the experiments :

  Site	Scooby-Doo	First article	Readability
  Google.com	FAIL	SUCCESS	FAIL
  Facebook.com	FAIL	FAIL	FAIL
  YouTube.com	FAIL	FAIL	FAIL
  Wikipedia.com	SUCCESS	SUCCESS	SUCCESS

  Clearly, Wikipedia is the prime example of a site where even the simple approaches find it easy to determine the main content on the page. WordPress blogs are similarly successful. Almost any other site, including news sites, social networks and search engine sites are petty hopeless with the proposed approaches, because there are too many elements that are used for layout or other purposes (notifications, hidden areas) such that the pre-determined list of semantic elements that are available simply don’t suffice to mark up a Web page/application completely.

  Conclusion

  It seems that in general it is impossible to determine which element(s) on a Web page should be the “main” piece of content that accessibility tools jump to when requested, that a search engine should put their focus on, or that should be highlighted to a general user to read. It would be very useful if the author of the Web page would provide a hint through a <main> element where that main content is to be found.

  I think that the <main> element becomes particularly useful when combined with a default keyboard shortcut in browsers as proposed by Steve : we may actually find that non-accessibility users will also start making use of this shortcut, e.g. to get to videos on YouTube pages directly without having to tab over search boxes and other interactive elements, etc. Worthwhile markup indeed.

• The use cases for a element in HTML

  1er janvier 2014, par silvia

  The W3C HTML WG and the WHATWG are currently discussing the introduction of a <main> element into HTML.

  The <main> element has been proposed by Steve Faulkner and is specified in a draft extension spec which is about to be accepted as a FPWD (first public working draft) by the W3C HTML WG. This implies that the W3C HTML WG will be looking for implementations and for feedback by implementers on this spec.

  I am supportive of the introduction of a <main> element into HTML. However, I believe that the current spec and use case list don’t make a good enough case for its introduction. Here are my thoughts.

  Main use case : accessibility

  In my opinion, the main use case for the introduction of <main> is accessibility.

  Like any other users, when blind users want to perceive a Web page/application, they need to have a quick means of grasping the content of a page. Since they cannot visually scan the layout and thus determine where the main content is, they use accessibility technology (AT) to find what is known as “landmarks”.

  “Landmarks” tell the user what semantic content is on a page : a header (such as a banner), a search box, a navigation menu, some asides (also called complementary content), a footer, …. and the most important part : the main content of the page. It is this main content that a blind user most often wants to skip to directly.

  In the days of HTML4, a hidden “skip to content” link at the beginning of the Web page was used as a means to help blind users access the main content.

  In the days of ARIA, the aria @role=main enables authors to avoid a hidden link and instead mark the element where the main content begins to allow direct access to the main content. This attribute is supported by AT – in particular screen readers – by making it part of the landmarks that AT can directly skip to.

  Both the hidden link and the ARIA @role=main approaches are, however, band aids : they are being used by those of us that make “finished” Web pages accessible by adding specific extra markup.

  A world where ARIA is not necessary and where accessibility developers would be out of a job because the normal markup that everyone writes already creates accessible Web sites/applications would be much preferable over the current world of band-aids.

  Therefore, to me, the primary use case for a <main> element is to achieve exactly this better world and not require specialized markup to tell a user (or a tool) where the main content on a page starts.

  An immediate effect would be that pages that have a <main> element will expose a “main” landmark to blind and vision-impaired users that will enable them to directly access that main content on the page without having to wade through other text on the page. Without a <main> element, this functionality can currently only be provided using heuristics to skip other semantic and structural elements and is for this reason not typically implemented in AT.

  Other use cases

  The <main> element is a semantic element not unlike other new semantic elements such as <header>, <footer>, <aside>, <article>, <nav>, or <section>. Thus, it can also serve other uses where the main content on a Web page/Web application needs to be identified.

  Data mining

  For data mining of Web content, the identification of the main content is one of the key challenges. Many scholarly articles have been published on this topic. This stackoverflow article references and suggests a multitude of approaches, but the accepted answer says “there’s no way to do this that’s guaranteed to work”. This is because Web pages are inherently complex and many <div>, <p>, <iframe> and other elements are used to provide markup for styling, notifications, ads, analytics and other use cases that are necessary to make a Web page complete, but don’t contribute to what a user consumes as semantically rich content. A <main> element will allow authors to pro-actively direct data mining tools to the main content.

  Search engines

  One particularly important “data mining” tool are search engines. They, too, have a hard time to identify which sections of a Web page are more important than others and employ many heuristics to do so, see e.g. this ACM article. Yet, they still disappoint with poor results pointing to findings of keywords in little relevant sections of a page rather than ranking Web pages higher where the keywords turn up in the main content area. A <main> element would be able to help search engines give text in main content areas a higher weight and prefer them over other areas of the Web page. It would be able to rank different Web pages depending on where on the page the search words are found. The <main> element will be an additional hint that search engines will digest.

  Visual focus

  On small devices, the display of Web pages designed for Desktop often causes confusion as to where the main content can be found and read, in particular when the text ends up being too small to be readable. It would be nice if browsers on small devices had a functionality (maybe a default setting) where Web pages would start being displayed as zoomed in on the main content. This could alleviate some of the headaches of responsive Web design, where the recommendation is to show high priority content as the first content. Right now this problem is addressed through stylesheets that re-layout the page differently depending on device, but again this is a band-aid solution. Explicit semantic markup of the main content can solve this problem more elegantly.

  Styling

  Finally, naturally, <main> would also be used to style the main content differently from others. You can e.g. replace a semantically meaningless <div id=”main”> with a semantically meaningful <main> where their position is identical. My analysis below shows, that this is not always the case, since oftentimes <div id=”main”> is used to group everything together that is not the header – in particular where there are multiple columns. Thus, the ease of styling a <main> element is only a positive side effect and not actually a real use case. It does make it easier, however, to adapt the style of the main content e.g. with media queries.

  Proposed alternative solutions

  It has been proposed that existing markup serves to satisfy the use cases that <main> has been proposed for. Let’s analyse these on some of the most popular Web sites. First let’s list the propsed algorithms.

  Proposed solution No 1 : Scooby-Doo

  On Sat, Nov 17, 2012 at 11:01 AM, Ian Hickson <ian@hixie.ch> wrote :
  | The main content is whatever content isn’t
  | marked up as not being main content (anything not marked up with <header>,
  | <aside>, <nav>, etc).
  

  This implies that the first element that is not a <header>, <aside>, <nav>, or <footer> will be the element that we want to give to a blind user as the location where they should start reading. The algorithm is implemented in https://gist.github.com/4032962.

  Proposed solution No 2 : First article element

  On Sat, Nov 17, 2012 at 8:01 AM, Ian Hickson  wrote :
  | On Thu, 15 Nov 2012, Ian Yang wrote :
  | >
  | > That’s a good idea. We really need an element to wrap all the <p>s,
  | > <ul>s, <ol>s, <figure>s, <table>s ... etc of a blog post.
  |
  | That’s called <article>.
  

  This approach identifies the first <article> element on the page as containing the main content. Here’s the algorithm for this approach.

  Proposed solution No 3 : An example heuristic approach

  The readability plugin has been developed to make Web pages readable by essentially removing all the non-main content from a page. An early source of readability is available. This demonstrates what a heuristic approach can perform.

  Analysing alternative solutions

  Comparison

  I’ve picked 4 typical Websites (top on Alexa) to analyse how these three different approaches fare. Ideally, I’d like to simply apply the above three scripts and compare pictures. However, since the semantic HTML5 elements <header>, <aside>, <nav>, and <footer> are not actually used by any of these Web sites, I don’t actually have this choice.

  So, instead, I decided to make some assumptions of where these semantic elements would be used and what the outcome of applying the first two algorithms would be. I can then compare it to the third, which is a product so we can take screenshots.

  Google.com

  http://google.com – search for “Scooby Doo”.

  The search results page would likely be built with :

  • a <nav> menu for the Google bar
  • a <header> for the search bar
  • another <header> for the login section
  • another <nav> menu for the search types
  • a <div> to contain the rest of the page
  • a <div> for the app bar with the search number
  • a few <aside>s for the left and right column
  • a set of <article>s for the search results

  “Scooby Doo” would find the first element after the headers as the “main content”. This is the element before the app bar in this case. Interestingly, there is a <div @id=main> already in the current Google results page, which “Scooby Doo” would likely also pick. However, there are a nav bar and two asides in this div, which clearly should not be part of the “main content”. Google actually placed a @role=main on a different element, namely the one that encapsulates all the search results.

  “First Article” would find the first search result as the “main content”. While not quite the same as what Google intended – namely all search results – it is close enough to be useful.

  The “readability” result is interesting, since it is not able to identify the main text on the page. It is actually aware of this problem and brings a warning before displaying this page :

  

  Facebook.com

  https://facebook.com

  A user page would likely be built with :

  • a <header> bar for the search and login bar
  • a <div> to contain the rest of the page
  • an <aside> for the left column
  • a <div> to contain the center and right column
  • an <aside> for the right column
  • a <header> to contain the center column “megaphone”
  • a <div> for the status posting
  • a set of <article>s for the home stream

  “Scooby Doo” would find the first element after the headers as the “main content”. This is the element that contains all three columns. It’s actually a <div @id=content> already in the current Facebook user page, which “Scooby Doo” would likely also pick. However, Facebook selected a different element to place the @role=main : the center column.

  “First Article” would find the first news item in the home stream. This is clearly not what Facebook intended, since they placed the @role=main on the center column, above the first blog post’s title. “First Article” would miss that title and the status posting.

  The “readability” result again disappoints but warns that it failed :

  

  YouTube.com

  http://youtube.com

  A video page would likely be built with :

  • a <header> bar for the search and login bar
  • a <nav> for the menu
  • a <div> to contain the rest of the page
  • a <header> for the video title and channel links
  • a <div> to contain the video with controls
  • a <div> to contain the center and right column
  • an <aside> for the right column with an <article> per related video
  • an <aside> for the information below the video
  • a <article> per comment below the video

  “Scooby Doo” would find the first element after the headers as the “main content”. This is the element that contains the rest of the page. It’s actually a <div @id=content> already in the current YouTube video page, which “Scooby Doo” would likely also pick. However, YouTube’s related videos and comments are unlikely to be what the user would regard as “main content” – it’s the video they are after, which generously has a <div id=watch-player>.

  “First Article” would find the first related video or comment in the home stream. This is clearly not what YouTube intends.

  The “readability” result is not quite as unusable, but still very bare :

  

  Wikipedia.com

  http://wikipedia.com (“Overscan” page)

  A Wikipedia page would likely be built with :

  • a <header> bar for the search, login and menu items
  • a <div> to contain the rest of the page
  • an &ls ; article> with title and lots of text
  • <article> an <aside> with the table of contents
  • several <aside>s for the left column

  Good news : “Scooby Doo” would find the first element after the headers as the “main content”. This is the element that contains the rest of the page. It’s actually a <div id=”content” role=”main”> element on Wikipedia, which “Scooby Doo” would likely also pick.

  “First Article” would find the title and text of the main element on the page, but it would also include an <aside>.

  The “readability” result is also in agreement.

  

  Results

  In the following table we have summarised the results for the experiments :

  Site	Scooby-Doo	First article	Readability
  Google.com	FAIL	SUCCESS	FAIL
  Facebook.com	FAIL	FAIL	FAIL
  YouTube.com	FAIL	FAIL	FAIL
  Wikipedia.com	SUCCESS	SUCCESS	SUCCESS

  Clearly, Wikipedia is the prime example of a site where even the simple approaches find it easy to determine the main content on the page. WordPress blogs are similarly successful. Almost any other site, including news sites, social networks and search engine sites are petty hopeless with the proposed approaches, because there are too many elements that are used for layout or other purposes (notifications, hidden areas) such that the pre-determined list of semantic elements that are available simply don’t suffice to mark up a Web page/application completely.

  Conclusion

  It seems that in general it is impossible to determine which element(s) on a Web page should be the “main” piece of content that accessibility tools jump to when requested, that a search engine should put their focus on, or that should be highlighted to a general user to read. It would be very useful if the author of the Web page would provide a hint through a <main> element where that main content is to be found.

  I think that the <main> element becomes particularly useful when combined with a default keyboard shortcut in browsers as proposed by Steve : we may actually find that non-accessibility users will also start making use of this shortcut, e.g. to get to videos on YouTube pages directly without having to tab over search boxes and other interactive elements, etc. Worthwhile markup indeed.