Recherche avancée

Médias (91)

Autres articles (98)

  • Publier sur MédiaSpip

    13 juin 2013

    Puis-je poster des contenus à partir d’une tablette Ipad ?
    Oui, si votre Médiaspip installé est à la version 0.2 ou supérieure. Contacter au besoin l’administrateur de votre MédiaSpip pour le savoir

  • Contribute to documentation

    13 avril 2011

    Documentation is vital to the development of improved technical capabilities.
    MediaSPIP welcomes documentation by users as well as developers - including : critique of existing features and functions articles contributed by developers, administrators, content producers and editors screenshots to illustrate the above translations of existing documentation into other languages
    To contribute, register to the project users’ mailing (...)

  • Submit bugs and patches

    13 avril 2011

    Unfortunately a software is never perfect.
    If you think you have found a bug, report it using our ticket system. Please to help us to fix it by providing the following information : the browser you are using, including the exact version as precise an explanation as possible of the problem if possible, the steps taken resulting in the problem a link to the site / page in question
    If you think you have solved the bug, fill in a ticket and attach to it a corrective patch.
    You may also (...)

Sur d’autres sites (11457)

  • 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.

  • 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 &amp;";
    
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 ?

  • 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 ?

Navigation