Recherche avancée

Médias (91)

Autres articles (90)

  • Mise à jour de la version 0.1 vers 0.2

    24 juin 2013, par

    Explications des différents changements notables lors du passage de la version 0.1 de MediaSPIP à la version 0.3. Quelles sont les nouveautés
    Au niveau des dépendances logicielles Utilisation des dernières versions de FFMpeg (>= v1.2.1) ; Installation des dépendances pour Smush ; Installation de MediaInfo et FFprobe pour la récupération des métadonnées ; On n’utilise plus ffmpeg2theora ; On n’installe plus flvtool2 au profit de flvtool++ ; On n’installe plus ffmpeg-php qui n’est plus maintenu au (...)

  • MediaSPIP version 0.1 Beta

    16 avril 2011, par

    MediaSPIP 0.1 beta est la première version de MediaSPIP décrétée comme "utilisable".
    Le fichier zip ici présent contient uniquement les sources de MediaSPIP en version standalone.
    Pour avoir une installation fonctionnelle, il est nécessaire d’installer manuellement l’ensemble des dépendances logicielles sur le serveur.
    Si vous souhaitez utiliser cette archive pour une installation en mode ferme, il vous faudra également procéder à d’autres modifications (...)

  • Amélioration de la version de base

    13 septembre 2013

    Jolie sélection multiple
    Le plugin Chosen permet d’améliorer l’ergonomie des champs de sélection multiple. Voir les deux images suivantes pour comparer.
    Il suffit pour cela d’activer le plugin Chosen (Configuration générale du site > Gestion des plugins), puis de configurer le plugin (Les squelettes > Chosen) en activant l’utilisation de Chosen dans le site public et en spécifiant les éléments de formulaires à améliorer, par exemple select[multiple] pour les listes à sélection multiple (...)

Sur d’autres sites (11636)

  • Concat videos with ffmpeg does not work [migrated]

    6 mai 2013, par Yannick Schinko

    I'm currently trying to concat 3 Videos which don't have a audio stream and adding a audio file in the same step.

    I created this command which should do the work :

    ffmpeg -y -r 30 -i data\intro.mp4 -vcodec ppm -f image2pipe -i data\render.ppm -i data\outro.mp4 -i "data\I could be the one.mp3" -c:v libx264 -crf 18 -preset slow -pix_fmt yuv420p -c:a copy -filter_complex "[0:0] [1:0] [2:0] concat=n=3:v=1:a=0 [v]" -map [v] -map 3:0 -shortest -metadata title="Development of BrainStoneMod" -metadata description="This is the development of the BrainStoneMod starting from 08th April, 2013" -metadata author="The_BrainStone" -metadata copyright="2013" -metadata year="2013" -metadata composer="" -metadata TBPM="" -metadata TDAT="" gource.mp4

    It is indeed a long command but it satisfied my needs until I wanted to embend the actual video in between a intro and a outro.

    I'm getting this log :

    ffmpeg version N-51639-g7775992 Copyright (c) 2000-2013 the FFmpeg developers
     built on Apr  5 2013 22:24:22 with gcc 4.8.0 (GCC)
     configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-av
    isynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enab
    le-iconv --enable-libass --enable-libbluray --enable-libcaca --enable-libfreetyp
    e --enable-libgsm --enable-libilbc --enable-libmp3lame --enable-libopencore-amrn
    b --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libr
    tmp --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheo
    ra --enable-libtwolame --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-li
    bvorbis --enable-libvpx --enable-libx264 --enable-libxavs --enable-libxvid --ena
    ble-zlib
     libavutil      52. 25.100 / 52. 25.100
     libavcodec     55.  2.100 / 55.  2.100
     libavformat    55.  1.100 / 55.  1.100
     libavdevice    55.  0.100 / 55.  0.100
     libavfilter     3. 49.100 /  3. 49.100
     libswscale      2.  2.100 /  2.  2.100
     libswresample   0. 17.102 /  0. 17.102
     libpostproc    52.  2.100 / 52.  2.100
    Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'data\intro.mp4':
     Metadata:
       major_brand     : isom
       minor_version   : 512
       compatible_brands: isomiso2avc1mp41
       encoder         : Lavf55.1.100
     Duration: 00:00:04.00, start: 0.000000, bitrate: 42 kb/s
       Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1280x720
    [SAR 1:1 DAR 16:9], 38 kb/s, 30 fps, 30 tbr, 15360 tbn, 60 tbc
       Metadata:
         handler_name    : VideoHandler
    [image2pipe @ 027f0a80] Stream #0: not enough frames to estimate rate; consider
    increasing probesize
    Input #1, image2pipe, from 'data\render.ppm':
     Duration: N/A, bitrate: N/A
       Stream #1:0: Video: ppm, rgb24, 1280x720, 25 tbr, 25 tbn, 25 tbc
    Input #2, mov,mp4,m4a,3gp,3g2,mj2, from 'data\outro.mp4':
     Metadata:
       major_brand     : isom
       minor_version   : 512
       compatible_brands: isomiso2avc1mp41
       encoder         : Lavf55.1.100
     Duration: 00:00:04.00, start: 0.000000, bitrate: 42 kb/s
       Stream #2:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1280x720
    [SAR 1:1 DAR 16:9], 38 kb/s, 30 fps, 30 tbr, 15360 tbn, 60 tbc
       Metadata:
         handler_name    : VideoHandler
    [mp3 @ 02757020] max_analyze_duration 5000000 reached at 5015510 microseconds
    [mp3 @ 02757020] Estimating duration from bitrate, this may be inaccurate
    Input #3, mp3, from 'data\I could be the one.mp3':
     Metadata:
       TBPM            : 140
       TDAT            : 0000
       composer        : Kevin Als
     Duration: 00:03:55.91, start: 0.000000, bitrate: 320 kb/s
       Stream #3:0: Audio: mp3, 44100 Hz, stereo, s16p, 320 kb/s
    [Parsed_concat_0 @ 028b20e0] Input link in1:v0 parameters (size 1280x720, SAR 0:
    1) do not match the corresponding output link in0:v0 parameters (1280x720, SAR 1
    :1)
    [Parsed_concat_0 @ 028b20e0] Failed to configure output pad on Parsed_concat_0

    What should I do ?

    By the way : This is the command I used before and worked out great :

    ffmpeg -y -r 30 -i "data\I could be the one.mp3" -vcodec ppm -f image2pipe -i data\render.ppm -c:v libx264 -crf 18 -preset slow -pix_fmt yuv420p -c:a copy -map 1:0 -map 0:0 -shortest -metadata title="Development of BrainStoneMod" -metadata description="This is the development of the BrainStoneMod starting from 08th April, 2013" -metadata author="The_BrainStone" -metadata copyright="2013" -metadata year="2013" -metadata composer="" -metadata TBPM="" -metadata TDAT="" gource.mp4

    Any ideas ?

  • compiling errors with ffmpeg on linux [closed]

    7 mai 2013, par David Tree

    Hi all ,I downloaded the latest ffmpeg source code and successfully installed it on Ubuntu

    But I failed to compile a simple demo.
    This was created with QtCreator with the .pro file as follows :

    QT -= gui

    TARGET = qt_v4l2
    TEMPLATE = app
    SOURCES += \
    ../tutorial01.c

    LIBS += -L/-lavcodec -lavformat -lswscale -lavutil

    Here are the error messages ,just to name a few :

    ../tutorial01.c:22:16 : error : unknown type name 'AVFrame'

    ../tutorial01.c:55:5 : error : unknown type name 'uint8_t'

    ../tutorial01.c:68:50 : error : 'NULL' undeclared (first use in this function)

    /tutorial01.c:84:22 : error : request for member 'streams' in something not a structure or union

    ../tutorial01.c:84:57 : error : 'AVMEDIA_TYPE_VIDEO' undeclared (first use in this function)

    ../tutorial01.c:122:24 : error : expected expression before ')' token

    ../tutorial01.c:128:21 : error : 'AVPicture' undeclared (first use in this function)
    ../tutorial01.c:128:32 : error : expected expression before ')' token

    .

    And this is the ffmpeg installed
    ffmpeg version 1.1.git Copyright (c) 2000-2013 the FFmpeg developers
    built on May 7 2013 14:10:58 with gcc 4.7 (Ubuntu/Linaro 4.7.2-2ubuntu1)
    configuration : —enable-gpl —prefix=/usr —enable-libx264 —enable-pthreads

    And this is the actuall CODE

    https://github.com/phamquy/FFmpeg-tutorial-samples/blob/master/tutorial01.c

  • Does H.264 encoded video with BT.709 matrix include any gamma adjustment ?

    27 janvier 2019, par MoDJ

    I have read the BT.709 spec a number of times and the thing that is just not clear is should an encoded H.264 bitstream actually apply any gamma curve to the encoded data ? Note the specific mention of a gamma like formula in the BT.709 spec. Apple provided examples of OpenGL or Metal shaders that read YUV data from CoreVideo provided buffers do not do any sort of gamma adjustment. YUV values are being read and processed as though they are simple linear values. I also examined the source code of ffmpeg and found no gamma adjustments being applied after the BT.709 scaling step. I then created a test video with just two linear grayscale colors 5 and 26 corresponding to 2% and 10% levels. When converted to H.264 with both ffmpeg and iMovie, the output BT.709 values are (YCbCr) (20 128 128) and (38 128 128) and these values exactly match the output of the BT.709 conversion matrix without any gamma adjustment.

    A great piece of background on this topic can be found at Quicktime Gamma Bug. It seems that some historical issues with Quicktime and Adobe encoders were improperly doing different gamma adjustments and the results made video streams look awful on different players. This is really confusing because if you compare to sRGB, it clearly indicates how to apply a gamma encoding and then decode it to convert between sRGB and linear. Why does BT.709 go into so much detail about the same sort of gamma adjustment curve if no gamma adjustment is applied after the matrix step when creating a h.264 data stream ? Are all the color steps in a h.264 stream meant to be coded as straight linear (gamma 1.0) values ?

    In case specific example input would make things more clear, I am attaching 3 color bar images, the exact values of different colors can be displayed in an image editor with these image files.

    This first image is in the sRGB colorspace and is tagged as sRGB.

    sRGB colorspace

    This second image has been converted to the linear RGB colorspace and is tagged with a linear RGB profile.

    linear RGB colorspace

    This third image has been converted to REC.709 profile levels with Rec709-elle-V4-rec709.icc from elles_icc_profiles
    . This seems to be what one would need to do to simulate "camera" gamma as described in BT.709.

    BT.709 colorspace ICC

    Note how the sRGB value in the lower right corner (0x555555) becomes linear RGB (0x171717) and the BT.709 gamma encoded value becomes (0x464646). What is unclear is if I should be passing a linear RGB value into ffmpeg or if I should be passing an already BT.709 gamma encoded value which would then need to be decoded in the client before the linear conversion Matrix step to get back to RGB.

    Update :

    Based on the feedback, I have updated my C based implementation and Metal shader and uploaded to github as an iOS example project MetalBT709Decoder.

    Encoding a normalized linear RGB value is implemented like this :

    static inline
    int BT709_convertLinearRGBToYCbCr(
                               float Rn,
                               float Gn,
                               float Bn,
                               int *YPtr,
                               int *CbPtr,
                               int *CrPtr,
                               int applyGammaMap)
    {
     // Gamma adjustment to non-linear value

     if (applyGammaMap) {
       Rn = BT709_linearNormToNonLinear(Rn);
       Gn = BT709_linearNormToNonLinear(Gn);
       Bn = BT709_linearNormToNonLinear(Bn);
     }

     // https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.709-6-201506-I!!PDF-E.pdf

     float Ey = (Kr * Rn) + (Kg * Gn) + (Kb * Bn);
     float Eb = (Bn - Ey) / Eb_minus_Ey_Range;
     float Er = (Rn - Ey) / Er_minus_Ey_Range;

     // Quant Y to range [16, 235] (inclusive 219 values)
     // Quant Eb, Er to range [16, 240] (inclusive 224 values, centered at 128)

     float AdjEy = (Ey * (YMax-YMin)) + 16;
     float AdjEb = (Eb * (UVMax-UVMin)) + 128;
     float AdjEr = (Er * (UVMax-UVMin)) + 128;

     *YPtr = (int) round(AdjEy);
     *CbPtr = (int) round(AdjEb);
     *CrPtr = (int) round(AdjEr);

     return 0;
    }

    Decoding from YCbCr to linear RGB is implemented like so :

    static inline
    int BT709_convertYCbCrToLinearRGB(
                                int Y,
                                int Cb,
                                int Cr,
                                float *RPtr,
                                float *GPtr,
                                float *BPtr,
                                int applyGammaMap)
    {
     // https://en.wikipedia.org/wiki/YCbCr#ITU-R_BT.709_conversion
     // http://www.niwa.nu/2013/05/understanding-yuv-values/

     // Normalize Y to range [0 255]
     //
     // Note that the matrix multiply will adjust
     // this byte normalized range to account for
     // the limited range [16 235]

     float Yn = (Y - 16) * (1.0f / 255.0f);

     // Normalize Cb and CR with zero at 128 and range [0 255]
     // Note that matrix will adjust to limited range [16 240]

     float Cbn = (Cb - 128) * (1.0f / 255.0f);
     float Crn = (Cr - 128) * (1.0f / 255.0f);

     const float YScale = 255.0f / (YMax-YMin);
     const float UVScale = 255.0f / (UVMax-UVMin);

     const
     float BT709Mat[] = {
       YScale,   0.000f,  (UVScale * Er_minus_Ey_Range),
       YScale, (-1.0f * UVScale * Eb_minus_Ey_Range * Kb_over_Kg),  (-1.0f * UVScale * Er_minus_Ey_Range * Kr_over_Kg),
       YScale, (UVScale * Eb_minus_Ey_Range),  0.000f,
     };

     // Matrix multiply operation
     //
     // rgb = BT709Mat * YCbCr

     // Convert input Y, Cb, Cr to normalized float values

     float Rn = (Yn * BT709Mat[0]) + (Cbn * BT709Mat[1]) + (Crn * BT709Mat[2]);
     float Gn = (Yn * BT709Mat[3]) + (Cbn * BT709Mat[4]) + (Crn * BT709Mat[5]);
     float Bn = (Yn * BT709Mat[6]) + (Cbn * BT709Mat[7]) + (Crn * BT709Mat[8]);

     // Saturate normalzied linear (R G B) to range [0.0, 1.0]

     Rn = saturatef(Rn);
     Gn = saturatef(Gn);
     Bn = saturatef(Bn);

     // Gamma adjustment for RGB components after matrix transform

     if (applyGammaMap) {
       Rn = BT709_nonLinearNormToLinear(Rn);
       Gn = BT709_nonLinearNormToLinear(Gn);
       Bn = BT709_nonLinearNormToLinear(Bn);
     }

     *RPtr = Rn;
     *GPtr = Gn;
     *BPtr = Bn;

     return 0;
    }

    I believe this logic is implemented correctly, but I am having a very difficult time validating the results. When I generate a .m4v file that contains gamma adjusted color values (osxcolor_test_image_24bit_BT709.m4v), the result come out as expected. But a test case like (bars_709_Frame01.m4v) that I found here does not seem to work as the color bar values seem to be encoded as linear (no gamma adjustment).

    For a SMPTE test pattern, the 0.75 graylevel is linear RGB (191 191 191), should this RGB be encoded with no gamma adjustment as (Y Cb Cr) (180 128 128) or should the value in the bitstream appear as the gamma adjusted (Y Cb Cr) (206 128 128) ?

    (follow up)
    After doing additional research into this gamma issue, it has become clear that what Apple is actually doing in AVFoundation is using a 1.961 gamma function. This is the case when encoding with AVAssetWriterInputPixelBufferAdaptor, when using vImage, or with CoreVideo APIs. This piecewise gamma function is defined as follows :

    #define APPLE_GAMMA_196 (1.960938f)

    static inline
    float Apple196_nonLinearNormToLinear(float normV) {
     const float xIntercept = 0.05583828f;

     if (normV < xIntercept) {
       normV *= (1.0f / 16.0f);
     } else {
       const float gamma = APPLE_GAMMA_196;
       normV = pow(normV, gamma);
     }

     return normV;
    }

    static inline
    float Apple196_linearNormToNonLinear(float normV) {
     const float yIntercept = 0.00349f;

     if (normV < yIntercept) {
       normV *= 16.0f;
     } else {
       const float gamma = 1.0f / APPLE_GAMMA_196;
       normV = pow(normV, gamma);
     }

     return normV;
    }