Recherche avancée

Sur d’autres sites (9582)

• How to make multiple ffmpeg commands run in parallel [duplicate]

  9 février, par Kim Mỹ

  I'm using the following ffmpeg command to compress video :

  


  `nice -n 10 ${ffmpegPath} -i "${chunkPath}" -c:v libx264 -preset fast -crf 28 "${compressedPath}"`


  


  However, when I run two instances of ffmpeg of this command to achieve parallelism :

  


  Either in two child processes within a single Node.js application or in two separate Node.js applications running at the same time, it seems only one command is processed, and the other is skipped.

  


  I've noticed that 2 FFmpeg instances are loaded into RAM and both create a starting file for the final compressed video, they finish compression around the same time. However, the total processing time is effectively doubled compared to compressing a single video file alone, which only takes half the time.

  


  I also try to pass the -threads argument but it produces same result.

  


• Shortcut to open command prompt with preloaded command

  13 janvier 2019, par Lemons

  I use FFMPEG to convert MP4s to WEBMs. This involves me constantly copying over my preferred script into the command prompt every single time. Is there a way to open a commant prompt with a certain command already set up and ready to go without executing the commmand immediately so that it is still editable ? Many times I need to change parameters of the script to match the specific file I will be converting...so simply having a pre-loaded script that runs by itself doesn’t make sense.

  Tried making a CMD shortcut but couldn’t find a way to do this without automatically running the command. Tried making a batch file, got the script to copy in, but it wasn’t editable.

  Here is the FFMPEG script I use : ffmpeg -i "in.mp4" -b:v 3000k -b:a 128k -threads 6 out.webm

• HTTP : improve performance by reducing forward seeks

  30 janvier 2017, par Joel Cunningham

  HTTP : improve performance by reducing forward seeks
  This commit optimizes HTTP performance by reducing forward seeks, instead
  
  favoring a read-ahead and discard on the current connection (referred to
  
  as a short seek) for seeks that are within a TCP window’s worth of data.
  
  This improves performance because with TCP flow control, a window’s worth
  
  of data will be in the local socket buffer already or in-flight from the
  
  sender once congestion control on the sender is fully utilizing the window.
  Note : this approach doesn’t attempt to differentiate from a newly opened
  
  connection which may not be fully utilizing the window due to congestion
  
  control vs one that is. The receiver can’t get at this information, so we
  
  assume worst case ; that full window is in use (we did advertise it after all)
  
  and that data could be in-flight
  The previous behavior of closing the connection, then opening a new
  
  with a new HTTP range value results in a massive amounts of discarded
  
  and re-sent data when large TCP windows are used.  This has been observed
  
  on MacOS/iOS which starts with an initial window of 256KB and grows up to
  
  1MB depending on the bandwidth-product delay.
  When seeking within a window’s worth of data and we close the connection,
  
  then open a new one within the same window’s worth of data, we discard
  
  from the current offset till the end of the window.  Then on the new
  
  connection the server ends up re-sending the previous data from new
  
  offset till the end of old window.
  Example (assumes full window utilization) :
  TCP window size : 64KB
  
  Position : 32KB
  
  Forward seek position : 40KB
        *                      (Next window)
  
  32KB |--------------| 96KB |---------------| 160KB
  
          *
  
    40KB |---------------| 104KB
  Re-sent amount : 96KB - 40KB = 56KB
  For a real world test example, I have MP4 file of 25MB, which ffplay
  
  only reads 16MB and performs 177 seeks. With current ffmpeg, this results
  
  in 177 HTTP GETs and 73MB worth of TCP data communication.  With this
  
  patch, ffmpeg issues 4 HTTP GETs and 3 seeks for a total of 22MB of TCP data
  
  communication.
  To support this feature, the short seek logic in avio_seek() has been
  
  extended to call a function to get the short seek threshold value.  This
  
  callback has been plumbed to the URLProtocol structure, which now has
  
  infrastructure in HTTP and TCP to get the underlying receiver window size
  
  via SO_RCVBUF.  If the underlying URL and protocol don’t support returning
  
  a short seek threshold, the default s->short_seek_threshold is used
  This feature has been tested on Windows 7 and MacOS/iOS.  Windows support
  
  is slightly complicated by the fact that when TCP window auto-tuning is
  
  enabled, SO_RCVBUF doesn’t report the real window size, but it does if
  
  SO_RCVBUF was manually set (disabling auto-tuning). So we can only use
  
  this optimization on Windows in the later case
  Signed-off-by : Joel Cunningham <joel.cunningham@me.com>
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavformat/avio.c
  • [DH] libavformat/avio.h
  • [DH] libavformat/aviobuf.c
  • [DH] libavformat/http.c
  • [DH] libavformat/tcp.c
  • [DH] libavformat/url.h