Recherche avancée

Sur d’autres sites (4248)

• Accurate FFmpeg capture start time

  28 juillet 2016, par Adam

  I’m using ffmpeg from the command line to capture from a webcam to a file using the following :

  ffmpeg -y -rtbufsize 702000k -f dshow -s 320x240 -r 25 -i video="<device>" -t 10 -vcodec mjpeg -q:v 2 out.mp4
  
  </device>

  There is a slight delay between executing the command and the start of the capture ( 0.5 sec).
  I’m trying to find a way to accurately determine the start time (UTC/GMT) of the capture.

  My initial thought was to use the file-creation time as this might accurately reflect when the first frame was encoded (as opposed to when the command was executed). Unfortunately the file creation time is only accurate to the second which is not precise enough (and I’m not sure this would have given an accurate result anyway).

  My next thought was to use ffmpegs timestamp option. According to the documentation (http://www.ffmpeg.org/ffmpeg.html) :

  ‘-timestamp time (output)’

  Set the recording timestamp in the container. The syntax for time is:
  
  
  
  now|([(YYYY-MM-DD|YYYYMMDD)[T|t| ]]((HH:MM:SS[.m...])|(HHMMSS[.m...]))[Z|z])

  If the value is "now" it takes the current time. Time is local time unless ’Z’ or
  ’z’ is appended, in which case it is interpreted as UTC. If the year-month-day part
  is not specified it takes the current year-month-day.

  So I added the option :

  ffmpeg -y -rtbufsize 702000k -f dshow -s 320x240 -r 25 -i video="<device>" -t 10 -vcodec mjpeg -q:v 2 -timestamp now out.mp4
  
  </device>

  Unfortunately ffmpeg doesn’t seem to like this :

  Option timestamp (set the recording timestamp (’now’ to set the
  current time)) cannot be applied to output file out.mp4 — you are
  trying to apply an input option to an output file or vice versa. Move
  this option before the file it belongs to.

  Error parsing options for output file out.mp4.

  Error opening output files : Error number -22 occurred

  The documentation says -timestamp is an output option and it appears to be applied to the output file so I’m confused by this error.

  Can anyone suggest a way to accurately determine the capture start time ?

  Does anyone know why the -timestamp option gives an error ?

• Revision 393a8ccef9 : Remove avoid_frame_with_high_error from RD loop The feature undergoes prior ass

  6 janvier 2014, par Jingning Han

  Changed Paths :
   Modify /vp9/encoder/vp9_block.h

  
   Modify /vp9/encoder/vp9_onyx_if.c

  
   Modify /vp9/encoder/vp9_onyx_int.h

  
   Modify /vp9/encoder/vp9_rdopt.c

  
  
  Remove avoid_frame_with_high_error from RD loop

  The feature undergoes prior assumption that the recursive partition
  size search from 4x4 to 64x64, hence utilizing information from small
  blocks to determine early termination in large block rate-distortion
  optimization search. The current codebase is now going from top down.
  The previous function might go with not properly initialized values,
  hence removed.

  Tested on pedestrian_area_1080p at 4000 kbps running under speed 2.
  No visible difference in runtime observed.

  Change-Id : I553df415c6191413762db7ae34e8790c71d8118e

• Revision a4ce53f14d : Adaptive motion control on ref and search range This commit takes a preliminary

  21 décembre 2013, par Jingning Han

  Changed Paths :
   Modify /vp9/encoder/vp9_block.h

  
   Modify /vp9/encoder/vp9_rdopt.c

  
  
  Adaptive motion control on ref and search range

  This commit takes a preliminary attempt to refine the motion search
  control. It detects the SAD associated with mv predictor per reference
  frame, and based on which to determine whether the encoder wants to
  reduce the motion search range (if the predicted mv provides fairly
  small SAD), or to skip the current reference frame (if there exists
  another ref frame that gives much smaller SAD cost).

  This feature is turned on in the settings of speed 1 and above.

  In speed 1, compression performance changed
  derf -0.018%
  yt -0.043%
  hd -0.045%
  stdhd -0.281%

  speed-up
  pedestrian_area_1080p at 4000 kbps 100 frames
  199651ms -> 188846ms (5.5% speed-up)
  blue_sky_1080p at 6000 kbps
  443531ms -> 415239ms (6.3% speed-up)

  In speed 2, compression performance changed
  derf -0.026%
  yt -0.090%
  hd -0.055%
  stdhd -0.210%

  speed-up
  pedstrian 113949ms -> 108855ms (4.5% speed-up)
  blue_sky 271057ms -> 257322ms (5% speed-up)

  Change-Id : I1b74ea28278c94fea329d971d706d573983d810d