Recherche avancée
Médias (1)
-
Bug de détection d’ogg
22 mars 2013, par
Mis à jour : Avril 2013
Langue : français
Type : Video
Autres articles (100)
-
HTML5 audio and video support
13 avril 2011, parMediaSPIP 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 (...) -
Librairies et binaires spécifiques au traitement vidéo et sonore
31 janvier 2010, parLes logiciels et librairies suivantes sont utilisées par SPIPmotion d’une manière ou d’une autre.
Binaires obligatoires FFMpeg : encodeur principal, permet de transcoder presque tous les types de fichiers vidéo et sonores dans les formats lisibles sur Internet. CF ce tutoriel pour son installation ; Oggz-tools : outils d’inspection de fichiers ogg ; Mediainfo : récupération d’informations depuis la plupart des formats vidéos et sonores ;
Binaires complémentaires et facultatifs flvtool2 : (...) -
La sauvegarde automatique de canaux SPIP
1er avril 2010, parDans le cadre de la mise en place d’une plateforme ouverte, il est important pour les hébergeurs de pouvoir disposer de sauvegardes assez régulières pour parer à tout problème éventuel.
Pour réaliser cette tâche on se base sur deux plugins SPIP : Saveauto qui permet une sauvegarde régulière de la base de donnée sous la forme d’un dump mysql (utilisable dans phpmyadmin) mes_fichiers_2 qui permet de réaliser une archive au format zip des données importantes du site (les documents, les éléments (...)
Sur d’autres sites (6609)
-
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.


-
Adding FFMPEG support to Chromium Portable on Windows without recompiling
13 décembre 2023, par AshbyI am using Chromium portable on Windows recently.


I downloaded Chromium portable from chromium.org, finding it without FFMPEG support, which means playing media just not possible for some websites.


Is there a simple or a little complex hack or plugin or patches to make FFMPEG on Chromium portable from chromium.org work ? Thanks.


Due to personal reasons I am not intended to use Google Chrome for some months, due to its automatic updates something like Windows Update, making me annoyed.


On Linux, I know there is a package called
chromium-codecs-ffmpeg-extra, which makes FFMPEG support possible. But I do NOT find something similar on Windows.

Recompiling Chromium costs hours and I just do not want to use some third-party Chromium releases due to security requests.


Years have gone and past questions years ago on stackflow just not cater my need today.


Thanks for your patience & understanding.


-
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
