Recherche avancée

Sur d’autres sites (8872)

• FFmpeg CPU utilization

  9 août 2013, par user2565986

  I have a server running Scientific Linux. I'm trying to convert a large amount of videos and want to maximize cpu usage. My ffmpeg version is git-2013-08-06-a68b6ec.

  FFmpeg command :

  ffmpeg -y -i "$i" -c:v libx264 -preset fast -b:v "$VID_BIT" -threads 0 -c:a libfdk_aac -b:a "$AUD_BIT" -f mp4 /"$OUT_DIR"/"$MD5"

  top output :

  top - 10:47:25 up 3 days, 22:05,  5 users,  load average: 1.94, 0.49, 0.16
  
  Tasks: 578 total,   1 running, 574 sleeping,   3 stopped,   0 zombie
  
  Cpu0  :  0.0%us,  0.6%sy, 63.2%ni, 36.1%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
  
  Cpu1  :  0.0%us,  0.6%sy, 60.1%ni, 39.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
  
  Cpu2  :  0.0%us,  0.3%sy, 59.5%ni, 40.1%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
  
  Cpu3  :  0.0%us,  0.6%sy, 57.1%ni, 42.2%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
  
  Cpu4  :  0.0%us,  0.3%sy, 55.0%ni, 44.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
  
  Cpu5  :  0.0%us,  0.6%sy, 50.2%ni, 49.2%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
  
  Cpu6  :  0.0%us,  0.3%sy, 56.4%ni, 43.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
  
  Cpu7  :  0.0%us,  0.6%sy, 50.3%ni, 49.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
  
  Cpu8  :  0.0%us,  0.6%sy, 47.7%ni, 51.6%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
  
  Cpu9  :  0.3%us,  0.3%sy, 46.8%ni, 52.6%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
  
  Cpu10 :  0.0%us,  0.3%sy, 50.2%ni, 49.5%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
  
  Cpu11 :  0.0%us,  0.7%sy, 49.0%ni, 50.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
  
  Cpu12 :  0.0%us,  0.6%sy, 49.4%ni, 50.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
  
  Cpu13 :  0.0%us,  0.6%sy, 43.2%ni, 56.1%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
  
  Cpu14 :  0.0%us,  0.3%sy, 44.5%ni, 55.2%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
  
  Cpu15 :  0.0%us,  0.6%sy, 46.3%ni, 53.1%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
  
  Cpu16 :  0.0%us,  0.7%sy, 44.6%ni, 54.8%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
  
  Cpu17 :  0.0%us,  0.3%sy, 43.3%ni, 56.4%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
  
  Cpu18 :  0.0%us,  0.3%sy, 41.6%ni, 58.1%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
  
  Cpu19 :  0.0%us,  0.3%sy, 34.3%ni, 65.4%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
  
  Cpu20 :  0.0%us,  0.6%sy, 32.5%ni, 66.9%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
  
  Cpu21 :  0.0%us,  0.3%sy, 37.9%ni, 61.4%id,  0.3%wa,  0.0%hi,  0.0%si,  0.0%st
  
  Cpu22 :  0.0%us,  0.3%sy, 36.9%ni, 62.8%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
  
  Cpu23 :  0.0%us,  1.0%sy, 37.6%ni, 61.4%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
  
  Mem:  198345032k total, 10135568k used, 188209464k free,   144212k buffers
  
  Swap: 55640056k total,        0k used, 55640056k free,  5066724k cached

  I'm not sure why user usage is at 0% and the niced usage is all I see, but either way I'm looking for a way to get the usage up to 100%. Is there anyway to bolster the usage or is this the best I'm gonna get ?

• ffmpeg rtmp streaming process exit

  12 août 2013, par Samson

  I'm using ffmpeg to capture jpeg images from an rtmp stream. Here is the command I use :

  /usr/local/bin/ffmpeg -threads 4 -i rtmp://..../chat/mp4:<variable>.mp4 
  
  -q:v 0.6 -r 15 -s 320x240 /frames/10021237_data/frame-%0999d.jpg
  
  
  
  ffmpeg version N-55388-g9386f33 Copyright (c) 2000-2013 the FFmpeg developers
  
    built on Aug  8 2013 14:07:38 with gcc 4.7 (Ubuntu/Linaro 4.7.2-2ubuntu1)
  
    configuration: 
  
    libavutil      52. 41.100 / 52. 41.100
  
    libavcodec     55. 24.100 / 55. 24.100
  
    libavformat    55. 13.102 / 55. 13.102
  
    libavdevice    55.  3.100 / 55.  3.100
  
    libavfilter     3. 82.100 /  3. 82.100
  
    libswscale      2.  4.100 /  2.  4.100
  
    libswresample   0. 17.103 /  0. 17.103
  
  Input #0, flv, from &#39;rtmp://......./mp4:10021237.mp4&#39;:
  
    Duration: N/A, start: 0.000000, bitrate: N/A
  
      Stream #0:0: Video: h264 (Main), yuv420p, 640x480 [SAR 1:1 DAR 4:3], 1.92 tbr, 1k tbn, 40 tbc
  
      Stream #0:1: Audio: nellymoser, 44100 Hz, mono, flt
  
  [swscaler @ 0x1910000] deprecated pixel format used, make sure you did set range correctly
  
  Output #0, image2, to &#39;/frames/10021237_data/frame-%0999d.jpg&#39;:
  
    Metadata:
  
      encoder         : Lavf55.13.102
  
      Stream #0:0: Video: mjpeg, yuvj420p, 320x240 [SAR 1:1 DAR 4:3], q=2-31, 200 kb/s, 90k tbn, 15 tbc
  
  Stream mapping:
  
    Stream #0:0 -> #0:0 (h264 -> mjpeg)
  
  Press [q] to stop, [?] for help
  
  </variable>

  However after a few minutes I get this line (before the process exits) :

  video:5264kB audio:0kB subtitle:0 global headers:0kB muxing overhead -100.000408%

  What exactly is the "muxing overhead" and why is it causing a crash ? Can I solve this or get it some other way (by restarting the process when it exits) ?

  EDIT :

  Actually it's not a crash. I'm running this command from a PHP CLI when a stream starts :

   $command = "/usr/local/bin/ffmpeg -i ".$rtmp." -q:v 0.6 -r 12 -s 320x240 ".__DIR__."/".$dir."/".$naming." >/dev/null 2>/dev/null &";
  
  shell_exec($command);

  but when one stops streaming all the ffmpeg processes end. Is there a way to make them independent ?

  Even opening 2 terminals and running the command (with different rtmp s)in each (for different streams), killing one of them closes the other one also.

  Bottom line is : How can I make 2 ffmpeg instances independent so as killing one does not kill the other. Is this behaviour expected ?

• How to detect audio sampling rate with avprobe / ffprobe ?

  8 août 2013, par Devy

  I am using libav 9.6, installed via Homebrew.

  $ avprobe -version
  
  avprobe version 9.6, Copyright (c) 2007-2013 the Libav developers
  
    built on Jun  8 2013 02:44:19 with Apple LLVM version 4.2 (clang-425.0.24) (based on LLVM 3.2svn)
  
  avprobe 9.6
  
  libavutil     52.  3. 0 / 52.  3. 0
  
  libavcodec    54. 35. 0 / 54. 35. 0
  
  libavformat   54. 20. 3 / 54. 20. 3
  
  libavdevice   53.  2. 0 / 53.  2. 0
  
  libavfilter    3.  3. 0 /  3.  3. 0
  
  libavresample  1.  0. 1 /  1.  0. 1
  
  libswscale     2.  1. 1 /  2.  1. 1

  Even though the sampling rate is displayed in the stdout in the command line output, the -show_format option doesn't surface the sampling rate information for the audio file at all.

  Here is the BASH terminal output :

  $ avprobe  -v verbose -show_format -of json  sample.gsm
  
  avprobe version 9.6, Copyright (c) 2007-2013 the Libav developers
  
    built on Jun  8 2013 02:44:19 with Apple LLVM version 4.2 (clang-425.0.24)
  
  (based on LLVM 3.2svn)
  
    configuration: --prefix=/usr/local/Cellar/libav/9.6 --enable-shared
  
  --enable-pthreads --enable-gpl --enable-version3 --enable-nonfree
  
  --enable-hardcoded-tables --enable-avresample --enable-vda --enable-gnutls
  
  --enable-runtime-cpudetect --disable-indev=jack --cc=cc --host-cflags=
  
  --host-ldflags= --enable-libx264 --enable-libfaac --enable-libmp3lame
  
  --enable-libxvid --enable-avplay
  
    libavutil     52.  3. 0 / 52.  3. 0
  
    libavcodec    54. 35. 0 / 54. 35. 0
  
    libavformat   54. 20. 3 / 54. 20. 3
  
    libavdevice   53.  2. 0 / 53.  2. 0
  
    libavfilter    3.  3. 0 /  3.  3. 0
  
    libavresample  1.  0. 1 /  1.  0. 1
  
    libswscale     2.  1. 1 /  2.  1. 1
  
  [gsm @ 0x7f8012806600] Estimating duration from bitrate, this may be inaccurate
  
  Input #0, gsm, from 'sample.gsm':
  
    Duration: 00:03:52.32, start: 0.000000, bitrate: 13 kb/s
  
      Stream #0.0: Audio: gsm, 8000 Hz, mono, s16, 13 kb/s
  
  {  "format" : {
  
      "filename" : "sample.gsm",
  
      "nb_streams" : 1,
  
      "format_name" : "gsm",
  
      "format_long_name" : "raw GSM",
  
      "start_time" : "0.000000",
  
      "duration" : "232.320000",
  
      "size" : "383328.000000",
  
      "bit_rate" : "13200.000000"
  
    }}

  And the python code example :

  >>> filename = 'sample.gsm'
  
  >>> result = subprocess.check_output(['avprobe', '-show_format', '-of',
  
  'json', filename])
  
  avprobe version 9.6, Copyright (c) 2007-2013 the Libav developers
  
    built on Jun  8 2013 02:44:19 with Apple LLVM version 4.2
  
  (clang-425.0.24) (based on LLVM 3.2svn)
  
  [gsm @ 0x7fe0b1806600] Estimating duration from bitrate, this may be
  
  inaccurate
  
  Input #0, gsm, from 'sample.gsm':
  
    Duration: 00:03:52.32, start: 0.000000, bitrate: 13 kb/s
  
      Stream #0.0: Audio: gsm, 8000 Hz, mono, s16, 13 kb/s
  
  >>> print result
  
  {  "format" : {
  
      "filename" : "sample.gsm",
  
      "nb_streams" : 1,
  
      "format_name" : "gsm",
  
      "format_long_name" : "raw GSM",
  
      "start_time" : "0.000000",
  
      "duration" : "232.320000",
  
      "size" : "383328.000000",
  
      "bit_rate" : "13200.000000"
  
  }}

  So I am aware that sampling rate could be a stream specific display to be shown in -show_format option results. But there isn't any other options to detect the sampling rate on a specific audio stream even though it's possible to set it with -ar when re-encoding it.

  I filed a ticket to libav but I am just curious if there is any other way to extract sampling rate from libav probing utils. I appreciate the answer beforehand.

  PS : it would be the same question for the upstream project of ffmpeg (ffprobe) in this case.