Recherche avancée

Médias (91)

Autres articles (97)

  • MediaSPIP 0.1 Beta version

    25 avril 2011, par

    MediaSPIP 0.1 beta is the first version of MediaSPIP proclaimed as "usable".
    The zip file provided here only contains the sources of MediaSPIP in its standalone version.
    To get a working installation, you must manually install all-software dependencies on the server.
    If you want to use this archive for an installation in "farm mode", you will also need to proceed to other manual (...)

  • HTML5 audio and video support

    13 avril 2011, par

    MediaSPIP uses HTML5 video and audio tags to play multimedia files, taking advantage of the latest W3C innovations supported by modern browsers.
    The MediaSPIP player used has been created specifically for MediaSPIP and can be easily adapted to fit in with a specific theme.
    For older browsers the Flowplayer flash fallback is used.
    MediaSPIP allows for media playback on major mobile platforms with the above (...)

  • ANNEXE : Les plugins utilisés spécifiquement pour la ferme

    5 mars 2010, par

    Le site central/maître de la ferme a besoin d’utiliser plusieurs plugins supplémentaires vis à vis des canaux pour son bon fonctionnement. le plugin Gestion de la mutualisation ; le plugin inscription3 pour gérer les inscriptions et les demandes de création d’instance de mutualisation dès l’inscription des utilisateurs ; le plugin verifier qui fournit une API de vérification des champs (utilisé par inscription3) ; le plugin champs extras v2 nécessité par inscription3 (...)

Sur d’autres sites (8910)

  • ffprobe or avprove returning plain text errors in JSON output

    10 avril 2013, par Justin Jenkins

    I'm running avprobe to get stream infomation about a video in JSON ...

    avprobe -loglevel quiet -show_format -show_streams file.m4v -of json

    This is basically the exact same thing as ffprobe or ffmpeg -i (and I get the same error.)

    ffprobe -loglevel quiet -show_format -show_streams file.m4v -print_format json

    The command works most of the time ... however, on occation I'll have a video that has an odd stream in it that is "unsupported" and I'll get back something like this (abbreviated.)

    Unsupported codec with id 94213 for input stream 2
    
{  "format" : {
    
    "filename" : "file.m4v",
    
    "nb_streams" : 3,
    
    "format_name" : "mov,mp4,m4a,3gp,3g2,mj2" ...

    When I run the command I get back JSON + an error in plain text, which makes the result invalid JSON and I have to "clean it up" later.

    I'm suppressing errors from the output -loglevel quiet but the error still show up.

    How can I tell avprobe/ffprobe to not show this error and hence get back a proper JSON object ?

    Longer Output Examples

    ffprobe, from source, MacOS

    ffprobe version 0.9.1-subsplash, Copyright (c) 2007-2012 the FFmpeg developers
    
  built on Feb  5 2012 01:35:36 with gcc 4.2.1 (Apple Inc. build 5664)
    
  configuration: --prefix=/Volumes/Ramdisk/sw --as=yasm --extra-version=subsplash --disable-shared --enable-static --disable-ffplay --disable-ffserver --enable-gpl --enable-pthreads --enable-version3 --enable-libspeex --enable-libvpx --disable-decoder=libvpx --enable-libmp3lame --enable-libfaac --enable-libvorbis --enable-libtheora --enable-libx264 --enable-avfilter --enable-libopencore_amrwb --enable-libopencore_amrnb --enable-filters --arch=x86_64 --enable-runtime-cpudetect --enable-nonfree
    
  libavutil    51. 32. 0 / 51. 32. 0
    
  libavcodec   53. 42. 4 / 53. 42. 4
    
  libavformat  53. 24. 2 / 53. 24. 2
    
  libavdevice  53.  4. 0 / 53.  4. 0
    
  libavfilter   2. 53. 0 /  2. 53. 0
    
  libswscale    2.  1. 0 /  2.  1. 0
    
  libpostproc  51.  2. 0 / 51.  2. 0
    
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'file.m4v':
    
  Metadata:
    
    major_brand     : mp42
    
    minor_version   : 0
    
    compatible_brands: mp42isomavc1
    
    creation_time   : 2012-01-01 06:38:43
    
    encoder         : HandBrake 0.9.5 2011010300
    
  Duration: 00:30:47.53, start: 0.000000, bitrate: 1558 kb/s
    
    Chapter #0.0: start -0.066733, end 17.784433
    
    Metadata:
    
      title           : Chapter  1
    

    
...
    

    
    Stream #0:2(und): Subtitle: mov_text (text / 0x74786574)
    
    Metadata:
    
      creation_time   : 2012-01-01 06:38:43
    
      handler_name    : 
    
Unsupported codec with id 94213 for input stream 2
    
{
    

    
...

    avprobe, from source, Ubuntu Linux

    avprobe version 10_alpha1-6:10~~git20130307.4be368b-1~quantal1, Copyright (c) 2007-2013 the Libav developers
    
  built on Mar  7 2013 22:12:44 with gcc 4.7 (Ubuntu/Linaro 4.7.2-2ubuntu1)
    
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'file.m4v':
    
  Metadata:
    
    major_brand     : mp42
    
    minor_version   : 0
    
    compatible_brands: mp42isomavc1
    
    creation_time   : 2012-01-01 06:38:43
    
    encoder         : HandBrake 0.9.5 2011010300
    
  Duration: 00:30:47.53, start: 0.000000, bitrate: 1558 kb/s
    
    Chapter #0.0: start -0.066733, end 17.784433
    
    Metadata:
    
      title           : Chapter  1
    

    
...
    

    
    Stream #0.2(und): Subtitle: text / 0x74786574
    
    Metadata:
    
      creation_time   : 2012-01-01 06:38:43
    
Unsupported codec with id 94213 for input stream 2
    
{
    

    
...

  • Receive rtp (opus) stream from ffmpeg on other computer with VLC

    27 juin 2015, par Friendlyghost89

    I am currently trying to get an opus stream to play on a separate computer using VLC.

    Currently the setup is as follows :

    Odroid-U2 running ffmpeg to capture audio and send as rtp opus stream to remote computer....
    command used : ffmpeg -f alsa -ac 1 -i hw:0 -acodec libopus -ab 32k -ac 1 -f rtp rtp ://192.168.0.115:2032

    the remote computer (on same local network) is at 192.168.0.115
    the Odroid is at 192.168.0.124

    If i use libmp3lame in libopus’s place then the stream will run through without a problem and will not prompt the fact that it requires sdp....

    VLC output on remote computer :

    SDP required: A description in SDP format is required to receive the RTP stream. Note that rtp:// URIs cannot work with dynamic RTP payload format (97).

    If i use an *.sdp file that I drop into vlc to play the stream it does nothing (no errors and no playback)

    SDP file used :

        SDP:
    
    v=0
    
    o=- 0 0 IN IP4 127.0.0.1
    
    s=No Name
    
    c=IN IP4 192.168.0.115
    
    t=0 0
    
    a=tool:libavformat 55.2.100
    
    m=audio 2032 RTP/AVP 97
    
    b=AS:32
    
    a=rtpmap:97 opus/48000

    ffmpeg output on Odroid :

        linaro@linaro-ubuntu-desktop:~$ ffmpeg -f alsa -ac 1 -i hw:0 -acodec libopus -ab 32k -ac 1         -f rtp rtp://192.168.0.115:2032
    
    ffmpeg version git-2013-04-13-87dd62e Copyright (c) 2000-2013 the FFmpeg developers
    
      built on Apr 13 2013 09:47:34 with gcc 4.6 (Ubuntu/Linaro 4.6.3-1ubuntu5)
    
      configuration: --enable-gpl --enable-libmp3lame --enable-libopencore-amrnb --enable-        libopencore-amrwb --enable-libspeex --enable-librtmp --enable-libtheora --enable-libvorbis         --enable-libvpx --enable-x11grab --enable-libx264 --enable-nonfree --enable-version3         --enable-libopus
    
      libavutil      52. 26.100 / 52. 26.100
    
      libavcodec     55.  2.100 / 55.  2.100
    
      libavformat    55.  2.100 / 55.  2.100
    
      libavdevice    55.  0.100 / 55.  0.100
    
      libavfilter     3. 53.101 /  3. 53.101
    
      libswscale      2.  2.100 /  2.  2.100
    
      libswresample   0. 17.102 /  0. 17.102
    
      libpostproc    52.  3.100 / 52.  3.100
    
    Guessed Channel Layout for  Input Stream #0.0 : mono
    
    Input #0, alsa, from 'hw:0':
    
      Duration: N/A, start: 1365868129.196234, bitrate: 768 kb/s
    
        Stream #0:0: Audio: pcm_s16le, 48000 Hz, mono, s16, 768 kb/s
    
    Output #0, rtp, to 'rtp://192.168.0.115:2032':
    
      Metadata:
    
        encoder         : Lavf55.2.100
    
        Stream #0:0: Audio: opus, 48000 Hz, mono, s16, 32 kb/s
    
    Stream mapping:
    
      Stream #0:0 -> #0:0 (pcm_s16le -> libopus)
    
    SDP:
    
    v=0
    
    o=- 0 0 IN IP4 127.0.0.1
    
    s=No Name
    
    c=IN IP4 192.168.0.115
    
    t=0 0
    
    a=tool:libavformat 55.2.100
    
    m=audio 2032 RTP/AVP 97
    
    b=AS:32
    
    a=rtpmap:97 opus/48000

    Any help is greatly appreciated....

    Regards

  • ffmpeg decoding yuv420p to rgb shifts luminance/brightness down

    6 avril 2013, par glopes

    I'm recording video from a grayscale camera into an MPEG4 video file using FFMPEG. Recently I noticed a weird effect : if I playback the file using FFMPEG or windows media player, the output frames are noticeably darker (by about 10 brightness values) than the original source.

    I thought the encoding step was doing this until I opened the same file in VLC and it gave me back the correct result. I played around with FFMPEG command lines to decode a single frame and realized that if I decode a frame into GRAY8 pixel format, the brightness/luminance values are preserved. Here's the command and ffmpeg output :

    ffmpeg -ss 0.5 -i video.avi -vframes 1 -t 1 -s 1280x680 -pix_fmt gray gray.bmp
    

    
ffmpeg version 1.2 Copyright (c) 2000-2013 the FFmpeg developers
    
  built on Apr  4 2013 12:40:58 with gcc 4.6.2 (GCC)
    
  configuration: --enable-w32threads
    
  libavutil      52. 18.100 / 52. 18.100
    
  libavcodec     54. 92.100 / 54. 92.100
    
  libavformat    54. 63.104 / 54. 63.104
    
  libavdevice    54.  3.103 / 54.  3.103
    
  libavfilter     3. 42.103 /  3. 42.103
    
  libswscale      2.  2.100 /  2.  2.100
    
  libswresample   0. 17.102 /  0. 17.102
    
Input #0, avi, from 'video.avi':
    
  Metadata:
    
    encoder         : Lavf53.32.100
    
  Duration: 00:00:07.47, start: 0.000000, bitrate: 16532 kb/s
    
    Stream #0:0: Video: mpeg4 (Simple Profile) (FMP4 / 0x34504D46), yuv420p, 128
    
0x720 [SAR 1:1 DAR 16:9], 30 tbr, 30 tbn, 30 tbc
    
Output #0, image2, to 'gray.bmp':
    
  Metadata:
    
    encoder         : Lavf54.63.104
    
    Stream #0:0: Video: bmp, gray, 1280x680 [SAR 17:18 DAR 16:9], q=2-31, 200 kb
    
/s, 90k tbn, 30 tbc
    
Stream mapping:
    
  Stream #0:0 -> #0:0 (mpeg4 -> bmp)
    
Press [q] to stop, [?] for help
    
frame=    1 fps=0.0 q=0.0 Lsize=N/A time=00:00:00.03 bitrate=N/A
    
video:851kB audio:0kB subtitle:0 global headers:0kB muxing overhead -100.002524%

    However, if I decode the same frame into an rgb color pixel format, I end up again with the darker frames :

    ffmpeg -ss 0.5 -i video.avi -vframes 1 -t 1 -s 1280x680 -pix_fmt bgr24 rgb.bmp
    

    
ffmpeg version 1.2 Copyright (c) 2000-2013 the FFmpeg developers
    
  built on Apr  4 2013 12:40:58 with gcc 4.6.2 (GCC)
    
  configuration: --enable-w32threads
    
  libavutil      52. 18.100 / 52. 18.100
    
  libavcodec     54. 92.100 / 54. 92.100
    
  libavformat    54. 63.104 / 54. 63.104
    
  libavdevice    54.  3.103 / 54.  3.103
    
  libavfilter     3. 42.103 /  3. 42.103
    
  libswscale      2.  2.100 /  2.  2.100
    
  libswresample   0. 17.102 /  0. 17.102
    
Input #0, avi, from 'video.avi':
    
  Metadata:
    
    encoder         : Lavf53.32.100
    
  Duration: 00:00:07.47, start: 0.000000, bitrate: 16532 kb/s
    
    Stream #0:0: Video: mpeg4 (Simple Profile) (FMP4 / 0x34504D46), yuv420p, 128
    
0x720 [SAR 1:1 DAR 16:9], 30 tbr, 30 tbn, 30 tbc
    
Output #0, image2, to 'rgb.bmp':
    
  Metadata:
    
    encoder         : Lavf54.63.104
    
    Stream #0:0: Video: bmp, bgr24, 1280x680 [SAR 17:18 DAR 16:9], q=2-31, 200 k
    
b/s, 90k tbn, 30 tbc
    
Stream mapping:
    
  Stream #0:0 -> #0:0 (mpeg4 -> bmp)
    
Press [q] to stop, [?] for help
    
frame=    1 fps=0.0 q=0.0 Lsize=N/A time=00:00:00.03 bitrate=N/A
    
video:2550kB audio:0kB subtitle:0 global headers:0kB muxing overhead -100.000843%

    This happens with every single grayscale video that I encode to MPEG4 with FFMPEG. My best guess so far is it has to do with how the container pixel format gets converted to/from. Since I'm using MPEG4, the file pixel format is YUV420P. I have no idea how ffmpeg encodes from GRAY8 to YUV420P, but maybe it stores just the luminance values in Y... if this happens, then decoding from this to RGB could produce darker pixels by the scaling factor that is applied to the luminance matrix ?

    To sum it up :

    1) How can encoding a grayscale video to YUV420P with FFMPEG and decoding back produce wrong (darker) brightness values when decoding to RGB versus GRAY8 ? Presumably once the frames are in YUV420P format it shouldn't matter whether the source is actually grayscale or not so the result should be equivalent, no ?

    2) How does VLC avoid this situation ? I was under the impression that VLC used FFMPEG as well for video decoding, but somehow they managed to figure out how to produce the correct values without requiring me to indicate explicitly that the video was grayscale.

Navigation