Recherche avancée

Médias (91)

Autres articles (51)

  • Participer à sa traduction

    10 avril 2011

    Vous pouvez nous aider à améliorer les locutions utilisées dans le logiciel ou à traduire celui-ci dans n’importe qu’elle nouvelle langue permettant sa diffusion à de nouvelles communautés linguistiques.
    Pour ce faire, on utilise l’interface de traduction de SPIP où l’ensemble des modules de langue de MediaSPIP sont à disposition. ll vous suffit de vous inscrire sur la liste de discussion des traducteurs pour demander plus d’informations.
    Actuellement MediaSPIP n’est disponible qu’en français et (...)

  • Les autorisations surchargées par les plugins

    27 avril 2010, par

    Mediaspip core
    autoriser_auteur_modifier() afin que les visiteurs soient capables de modifier leurs informations sur la page d’auteurs

  • 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

Sur d’autres sites (7057)

  • ffmpeg avformat_open_input() function causes memory leak when receiving live stream

    12 septembre 2023, par george_d

    I have live streams (can be UDP or HLS, video codec is H264), from which I grab frames for further processing.

    


    For this purpose, I use ffmpeg + nvjpeg + cuda libraries.

    


    However I noticed memory leak - memory usage periodically (every 10-20 seconds) is increased by 100-400 KB, the amount and period may vary.

    


    After disabling pieces of code one by one, I realized that it is avformat_open_input() which causes memory leak.

    


    No matter which buffer settings (https://ffmpeg.org/ffmpeg-protocols.html#udp) I choose for UDP, the leak still persists. Same goes for HLS streams.

    


    I tried to find anything related to this problem, but all the sources I found claimed that this problem took place in the past and has been fixed.

    


    Is there some mysterious setting I am missing, so that memory could be freed properly ?

    


    Or is this memory supposed to be freed when processing frames (i.e. using av_read_frame() and av_packet_unref(), etc) ?

    


    Minimal example of code to reproduce the problem :

    


    avformat_example.cpp

    


    #include &#xA;extern "C" {&#xA;    #include <libavformat></libavformat>avformat.h>&#xA;    #include <libavcodec></libavcodec>avcodec.h>&#xA;}&#xA;&#xA;int main(int argc, char *argv[]){&#xA;    if (argc &lt; 2) {&#xA;      return 1;&#xA;    }&#xA;&#xA;    char* inputSource = argv[1];&#xA;    AVFormatContext *ctx = NULL;&#xA;&#xA;    if (avformat_open_input(&amp;ctx, inputSource, NULL, NULL) != 0) {&#xA;        av_log(NULL,&#xA;               AV_LOG_ERROR,&#xA;               "Cannot open &#x27;%s&#x27;",&#xA;               inputSource);&#xA;        return 1;&#xA;    }&#xA;&#xA;    /*&#xA;    This loop is placed here to demonstrate&#xA;    avformat_open_input() causing leak.&#xA;    Actually, instead of noop loop there is logic of getting and processing frames,&#xA;    but it doesn&#x27;t matter now.&#xA;    As loop goes on, the amount of leaked memory increases.&#xA;    */&#xA;    while(true) {&#xA;      sleep(1);&#xA;    }&#xA;&#xA;    return 0;&#xA;}&#xA;

    &#xA;

    Compile with :

    &#xA;

    g&#x2B;&#x2B; avformat_example.cpp -lavcodec -lavutil -lavformat -I/usr/include/ffmpeg-cuda -o avformat_open_input_example&#xA;

    &#xA;

    Run :

    &#xA;

    ./avformat_open_input_example "udp://127.0.0.1:5000?reuse=1&amp;pkt_size=1316&amp;buffer_size=1310720&amp;fifo_size=40000"&#xA;

    &#xA;

    Version of ffmpeg underlying libraries :

    &#xA;

    libavutil      58.  7.100 / 58.  7.100&#xA;libavcodec     60. 11.100 / 60. 11.100&#xA;libavformat    60.  5.100 / 60.  5.100&#xA;libavdevice    60.  2.100 / 60.  2.100&#xA;libavfilter     9.  8.100 /  9.  8.100&#xA;libswscale      7.  2.100 /  7.  2.100&#xA;libswresample   4. 11.100 /  4. 11.100&#xA;

    &#xA;

  • libavutil : include assembly with full path from source root

    18 janvier 2022, par Alexander Kanavin
    libavutil : include assembly with full path from source root
    

    Otherwise nasm writes the full host-specific paths into .o
    output, which breaks binary reproducibility.

    Signed-off-by : Alexander Kanavin <alex.kanavin@gmail.com>
    Signed-off-by : Anton Khirnov <anton@khirnov.net>

    • [DH] libavutil/x86/cpuid.asm
    • [DH] libavutil/x86/emms.asm
    • [DH] libavutil/x86/fixed_dsp.asm
    • [DH] libavutil/x86/float_dsp.asm
    • [DH] libavutil/x86/lls.asm
    • [DH] libavutil/x86/pixelutils.asm
    • [DH] libavutil/x86/tx_float.asm
  • swscale/cms,graph,lut3d : Use ff_-prefix, don't export internal functions

    8 janvier, par Andreas Rheinhardt
    swscale/cms,graph,lut3d : Use ff_-prefix, don't export internal functions
    

    Symbols with the sws_* prefix are exported.

    Reviewed-by : Alexander Strasser <eclipse7@gmx.net>
    Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

    • [DH] libswscale/cms.c
    • [DH] libswscale/cms.h
    • [DH] libswscale/graph.c
    • [DH] libswscale/graph.h
    • [DH] libswscale/lut3d.c
    • [DH] libswscale/lut3d.h
    • [DH] libswscale/swscale.c
    • [DH] libswscale/utils.c