Recherche avancée
Médias (1)
-
Somos millones 1
21 juillet 2014, par
Mis à jour : Juin 2015
Langue : français
Type : Video
Autres articles (63)
-
D’autres logiciels intéressants
12 avril 2011, parOn ne revendique pas d’être les seuls à faire ce que l’on fait ... et on ne revendique surtout pas d’être les meilleurs non plus ... Ce que l’on fait, on essaie juste de le faire bien, et de mieux en mieux...
La liste suivante correspond à des logiciels qui tendent peu ou prou à faire comme MediaSPIP ou que MediaSPIP tente peu ou prou à faire pareil, peu importe ...
On ne les connais pas, on ne les a pas essayé, mais vous pouvez peut être y jeter un coup d’oeil.
Videopress
Site Internet : (...) -
Récupération d’informations sur le site maître à l’installation d’une instance
26 novembre 2010, parUtilité
Sur le site principal, une instance de mutualisation est définie par plusieurs choses : Les données dans la table spip_mutus ; Son logo ; Son auteur principal (id_admin dans la table spip_mutus correspondant à un id_auteur de la table spip_auteurs)qui sera le seul à pouvoir créer définitivement l’instance de mutualisation ;
Il peut donc être tout à fait judicieux de vouloir récupérer certaines de ces informations afin de compléter l’installation d’une instance pour, par exemple : récupérer le (...) -
Organiser par catégorie
17 mai 2013, parDans MédiaSPIP, une rubrique a 2 noms : catégorie et rubrique.
Les différents documents stockés dans MédiaSPIP peuvent être rangés dans différentes catégories. On peut créer une catégorie en cliquant sur "publier une catégorie" dans le menu publier en haut à droite ( après authentification ). Une catégorie peut être rangée dans une autre catégorie aussi ce qui fait qu’on peut construire une arborescence de catégories.
Lors de la publication prochaine d’un document, la nouvelle catégorie créée sera proposée (...)
Sur d’autres sites (4200)
-
configure : rework parsing —cpu arguments to support all features unless blacklisted
17 septembre 2023, par James Almerconfigure : rework parsing —cpu arguments to support all features unless blacklisted
Keeping an ever growing list of CPUs just to pass -march to the compiler and
enable fast_cmov is a waste of time. Every CPU we know has limitations is
already handled here, so just fallback to enabling everything when a passed in
argument is not one of those.This will enable optimizations for CPU architectures released in the past 7 or
so years with supported GCC and clang compilers when used as argument in
configure, instead of silently ignoring them.Signed-off-by : James Almer <jamrial@gmail.com>
-
ffmpeg memory leak when opening libx264 encoder
18 octobre 2023, par ksb496I have spotted a memory leak issue when I use the libx264 encoder in the FFmpeg C API. Specifically, when it comes to deallocate memory after encoding a video. After tracking the factor that causes it, I realized that it happens after invoking
avcodec_open2, which allocates some memory that afterwards cannot be freed. Once the video is processed, callingavcodec_closeand thenavcodec_free_contextdoes not entirely free all the allocated memory.

After some investigation, I found out that the problem could be located in
AVCodecContext::priv_databeing allocated but not being freed afterwards. In this question a solution to the issue is proposed. However, I tried to implement it without success (the memory being leaked seems to be exactly the same).

As a matter of fact, the following simple code (which includes the patch that was proposed in the aforementioned question), in which the codec is being opened and closed multiple times without even writing a single frame or allocating an
AVFormatContext, illustrates the memory leak.

#include 
extern "C"{
#include 
#include <libavcodec></libavcodec>avcodec.h>
#include <libavutil></libavutil>opt.h>
}

int main()
{
 avcodec_register_all();

 AVCodec *codec;
 AVCodecContext *c;
 for (int n=0; n<2000; n++)
 {
 codec = avcodec_find_encoder_by_name("libx264");
 c=avcodec_alloc_context3(codec);
 c->pix_fmt=AV_PIX_FMT_YUV420P;
 c->width=1920;
 c->height=1080;
 c->time_base=(AVRational){1, 30};
 c->framerate=(AVRational){30, 1};
 avcodec_open2(c, codec, NULL);
 avcodec_close(c);
 av_opt_free(c->priv_data);
 av_freep(&c->priv_data);
 avcodec_free_context(&c);
 }
 return 0;
}


It must be remarked that if the line
codec = avcodec_find_encoder_by_name("libx264")is replaced to an invocation to an internal/native encoder, e.g.,codec = avcodec_find_encoder(AV_CODEC_ID_MPEG4), then the memory leak issue completely disappears. Hence, it certainly seems to be an issue related to some private data of the external encoder not being properly freed.

It is also worth mentioning that I am using an old version of ffmpeg and libx264. To be more precise, ffmpeg version 2.8git and libx264 version 0.136.x. For technical reasons that are beyond the scope of this question, it is not possible to upgrade the libraries to newer versions onto the project in which these are being used. I am fully aware that most of the involved ffmpeg/libx264 code has been probably changed along the years and many functions became deprecated or fixed, and thus reporting this as a possible bug in the ffmpeg developer's mailbox is out of the question.


Nevertheless, I am still asking this here because I would like to know whether it is just some mistake on my end and/or something I am not taking into account when it comes to free all the memory relative to an external encoder (best case scenario). Otherwise, I would like to know whether there can be some reasonably cheap solution through some custom code or function that can be implemented as a patch (assuming it is indeed an issue related to ffmpeg/libx264), no matter if it makes the whole deallocation code less elegant or concise. If someone is still working on these older versions of ffmpeg and can come up with a workaround, that would be highly appreciated.


-
ffmpeg memory leak when opening libx264 encoder
18 octobre 2023, par ksb496I have spotted a memory leak issue when I use the libx264 encoder in the FFmpeg C API. Specifically, when it comes to deallocate memory after encoding a video. After tracking the factor that causes it, I realized that it happens after invoking
avcodec_open2, which allocates some memory that afterwards cannot be freed. Once the video is processed, callingavcodec_closeand thenavcodec_free_contextdoes not entirely free all the allocated memory.

After some investigation, I found out that the problem could be located in
AVCodecContext::priv_databeing allocated but not being freed afterwards. In this question a solution to the issue is proposed. However, I tried to implement it without success (the memory being leaked seems to be exactly the same).

As a matter of fact, the following simple code (which includes the patch that was proposed in the aforementioned question), in which the codec is being opened and closed multiple times without even writing a single frame or allocating an
AVFormatContext, illustrates the memory leak.

#include 
extern "C"{
#include 
#include <libavcodec></libavcodec>avcodec.h>
#include <libavutil></libavutil>opt.h>
}

int main()
{
 avcodec_register_all();

 AVCodec *codec;
 AVCodecContext *c;
 for (int n=0; n<2000; n++)
 {
 codec = avcodec_find_encoder_by_name("libx264");
 c=avcodec_alloc_context3(codec);
 c->pix_fmt=AV_PIX_FMT_YUV420P;
 c->width=1920;
 c->height=1080;
 c->time_base=(AVRational){1, 30};
 c->framerate=(AVRational){30, 1};
 avcodec_open2(c, codec, NULL);
 avcodec_close(c);
 av_opt_free(c->priv_data);
 av_freep(&c->priv_data);
 avcodec_free_context(&c);
 }
 return 0;
}


It must be remarked that if the line
codec = avcodec_find_encoder_by_name("libx264")is replaced to an invocation to an internal/native encoder, e.g.,codec = avcodec_find_encoder(AV_CODEC_ID_MPEG4), then the memory leak issue completely disappears. Hence, it certainly seems to be an issue related to some private data of the external encoder not being properly freed.

It is also worth mentioning that I am using an old version of ffmpeg and libx264. To be more precise, ffmpeg version 2.8git and libx264 version 0.136.x. For technical reasons that are beyond the scope of this question, it is not possible to upgrade the libraries to newer versions onto the project in which these are being used. I am fully aware that most of the involved ffmpeg/libx264 code has been probably changed along the years and many functions became deprecated or fixed, and thus reporting this as a possible bug in the ffmpeg developer's mailbox is out of the question.


Nevertheless, I am still asking this here because I would like to know whether it is just some mistake on my end and/or something I am not taking into account when it comes to free all the memory relative to an external encoder (best case scenario). Otherwise, I would like to know whether there can be some reasonably cheap solution through some custom code or function that can be implemented as a patch (assuming it is indeed an issue related to ffmpeg/libx264), no matter if it makes the whole deallocation code less elegant or concise. If someone is still working on these older versions of ffmpeg and can come up with a workaround, that would be highly appreciated.


Syndiquer tout le site
