Recherche avancée

Médias (1)

Mot : - Tags -/biomaping

Autres articles (18)

  • MediaSPIP v0.2

    21 juin 2013, par

    MediaSPIP 0.2 is the first MediaSPIP stable release.
    Its official release date is June 21, 2013 and is announced here.
    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 (...)

  • Déploiements possibles

    31 janvier 2010, par

    Deux types de déploiements sont envisageable dépendant de deux aspects : La méthode d’installation envisagée (en standalone ou en ferme) ; Le nombre d’encodages journaliers et la fréquentation envisagés ;
    L’encodage de vidéos est un processus lourd consommant énormément de ressources système (CPU et RAM), il est nécessaire de prendre tout cela en considération. Ce système n’est donc possible que sur un ou plusieurs serveurs dédiés.
    Version mono serveur
    La version mono serveur consiste à n’utiliser qu’une (...)

  • Les formats acceptés

    28 janvier 2010, par

    Les commandes suivantes permettent d’avoir des informations sur les formats et codecs gérés par l’installation local de ffmpeg :
    ffmpeg -codecs ffmpeg -formats
    Les format videos acceptés en entrée
    Cette liste est non exhaustive, elle met en exergue les principaux formats utilisés : h264 : H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 m4v : raw MPEG-4 video format flv : Flash Video (FLV) / Sorenson Spark / Sorenson H.263 Theora wmv :
    Les formats vidéos de sortie possibles
    Dans un premier temps on (...)

Sur d’autres sites (5368)

  • avformat/dashdec : Fix crash on invalid input/ENOMEM, fix leak

    20 septembre 2022, par Andreas Rheinhardt
    avformat/dashdec : Fix crash on invalid input/ENOMEM, fix leak
    

    In case a SupplementalProperty node exists in an adaptationset,
    it is searched for a "schemeIdUri" property via xmlGetProp().
    Whatever xmlGetProp() returns is then compared via av_strcasecmp()
    to a string literal. xmlGetProp() can return NULL, namely in case
    no "schemeIdUri" exists and (given that this string is allocated)
    presumably also on allocation failure. No check for NULL is done,
    so this may crash.

    Furthermore, the string returned by xmlGetProp() needs to be freed
    with xmlFree(), but this is not done either.

    This commit fixes both of these issues ; they existed since this code
    has been added in 10d008f0fd9e713e290f626300d66382ad786c49.

    This has been found while investigating ticket #9697. The continuous
    leaks might very well be the reason behind the observed slowdown.

    Reviewed-by : Steven Liu <lingjiujianke@gmail.com>
    Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

    • [DH] libavformat/dashdec.c
  • Does this code contain a potential memory leak ?

    26 juillet 2017, par Johnnylin

    Here is the code :

    cv::Mat YV12ToBRG24_FFmpeg(unsigned char* pYUV, int width,int height)
    {
       if (width &lt; 1 || height &lt; 1 || pYUV == nullptr){
           return cv::Mat();
       }

       cv::Mat result(height,width,CV_8UC3, cv::Scalar::all(0));
       uchar* pBGR24 = result.data;

       AVFrame* pFrameYUV = av_frame_alloc();
       pFrameYUV->width = width;
       pFrameYUV->height = height;
       pFrameYUV->format = AV_PIX_FMT_YUV420P;
       av_image_fill_arrays(pFrameYUV->data, pFrameYUV->linesize, pYUV, AV_PIX_FMT_YUV420P, width, height, 1);

       //U,V exchange
       uint8_t * ptmp=pFrameYUV->data[1];
       pFrameYUV->data[1]=pFrameYUV->data[2];
       pFrameYUV->data[2]=ptmp;

       AVFrame* pFrameBGR = av_frame_alloc();
       pFrameBGR->width = width;
       pFrameBGR->height = height;
       pFrameBGR->format = AV_PIX_FMT_BGR24;
       av_image_fill_arrays(pFrameBGR->data, pFrameBGR->linesize, pBGR24, AV_PIX_FMT_BGR24, width, height, 1);

       struct SwsContext* imgCtx = nullptr;
       imgCtx = sws_getContext(width,height,AV_PIX_FMT_YUV420P,width,height,AV_PIX_FMT_BGR24,SWS_BILINEAR,0,0,0);
       if (imgCtx != nullptr){
           sws_scale(imgCtx,pFrameYUV->data,pFrameYUV->linesize,0,height,pFrameBGR->data,pFrameBGR->linesize);
           sws_freeContext(imgCtx);
           imgCtx = nullptr;
           ptmp = nullptr;
           pBGR24 = nullptr;
           av_frame_free(&amp;pFrameYUV);
           av_frame_free(&amp;pFrameBGR);
           return result;
       }
       else{
           sws_freeContext(imgCtx);
           imgCtx = nullptr;
           ptmp = nullptr;
           pBGR24 = nullptr;
           av_frame_free(&amp;pFrameYUV);
           av_frame_free(&amp;pFrameBGR);
           return cv::Mat();
       }
    }

    This function is called every 40 ms (25 fps) and I saw a significant memory increase after several days(like 12GB). But if I ran this code for hours, the memory leak problem would not be obvious enough to be observed.

    Can anyone help ?
    Thanks.

  • avformat/hevc : Fix potential leak in case of ff_hevc_annexb2mp4_buf failure

    23 janvier 2020, par Andreas Rheinhardt
    avformat/hevc : Fix potential leak in case of ff_hevc_annexb2mp4_buf failure
    

    ff_hevc_annexb2mp4_buf() could indicate an error, yet leave cleaning
    after itself to the caller, so that a caller could not simply return the
    error, but had to free the buffer first.

    (Given that all current callers have set filter_ps = 0, this error can
    currently not be triggered.)

    Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
    Signed-off-by : James Almer <jamrial@gmail.com>

    • [DH] libavformat/hevc.c
    • [DH] libavformat/hevc.h