Recherche avancée

Sur d’autres sites (7568)

• ffmpeg capture RTSP stream to hourly file

  23 avril 2017, par David Patrick

  I’m using ffmpeg to capture a RTSP stream to a file using the following command :

  ffmpeg -i rtsp://[IP Address]:[port]/[URL] -vcodec copy -r 60 -t 2600 -y /[outputfile].mp4

  This works ok and captures 60 mins fine. What I’d like to be able to do is :

  1. Output hourly files, e.g. capture1.mp4 capture2.mp4 etc.
  2. Put the current timestamp as the overlay in the current file (currently
     VLC says something like LIVE555...). I’d like to change this to
     source + timestamp.
  3. Delete old mp4 files over x days old, e.g. keep files for 1 or 2 days

  Is this possible in ffmpeg or do i need to put a script wrapper around the ffmpeg command ? If so, any examples of those I can re-use please ?
  This is on Ubuntu linux using latest ffmpeg package and using apt-get install ffmpeg to install so it’s built from source.

  Thanks

• avformat/sccdec : Don't use uninitialized data, fix crash, simplify logic

  1er octobre 2021, par Andreas Rheinhardt

  avformat/sccdec : Don't use uninitialized data, fix crash, simplify logic
  Up until now, the scc demuxer not only read the line that it intends
  
  to process, but also the next line, in order to be able to calculate
  
  the duration of the current line. This approach leads to unnecessary
  
  complexity and also to bugs : For the last line, the timing of the
  
  next subtitle is not only logically indeterminate, but also
  
  uninitialized and the same applies to the duration of the last packet
  
  derived from it.* Worse yet, in case of e.g. an empty file, it is not
  
  only the duration that is uninitialized, but the whole timing as well
  
  as the line buffer itself.** The latter is used in av_strtok(), which
  
  could lead to crashes. Furthermore, the current code always outputs
  
  at least one packet, even for empty files.
  This commit fixes all of this : It stops using two lines at a time ;
  
  instead only the current line is dealt with and in case there is
  
  a packet after that, the duration of the last packet is fixed up
  
  after having already parsed it ; consequently the duration of the
  
  last packet is left in its default state (meaning "unknown/up until
  
  the next subtitle"). If no further line could be read, processing
  
  is stopped ; in particular, no packet is output for an empty file.
  * : Due to stack reuse it seems to be zero quite often ; for the same
  
  reason Valgrind does not report any errors for a normal input file.
  
  ** : While ff_subtitles_read_line() claims to always zero-terminate
  
  the buffer like snprintf(), it doesn't do so if it didn't read anything.
  
  And even if it did, it would not necessarily help here : The current
  
  code jumps over 12 bytes that it deems to have read even when it
  
  hasn't.
  Reviewed-by : Paul B Mahol <onemda@gmail.com>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavformat/sccdec.c

• know exactly the size of the converted video

  19 septembre 2014, par moderadorkl25

  I’m trying to know the size more accurately converted video using ffmpeg, I’m getting the actual size of the original video and output video
  and dividing the size of 2, the logic when I get the size of another video will multiply the value to know the result.

  the purpose of this is because I want to make a progress bar using php and ajax, so by my logic would be.

  <?
  
  $total = $select_result;// total original file
  
  $video = 'test.mp4';
  
  
  
  
  
  //loop ajax
  
  $getID3 = new getID3;
  
  $file = $getID3->analyze($video);
  
  $current = $file['filesize'];
  
  
  
  
  
  $a = $total / $current;
  
  $b = $a * 100;
  
  print number_format($b,0).'%';
  
  ?>

  ffmpeg command will always be this

  exec("ffmpeg -i $video -ar 22050 -ab 32 -f mp4 -s 320x240 teste1.mp4")

  but by my logic does not work, each video is a different value, it is possible to do this calculation ?