
Recherche avancée
Autres articles (75)
-
MediaSPIP v0.2
21 juin 2013, parMediaSPIP 0.2 est la première version de MediaSPIP stable.
Sa date de sortie officielle est le 21 juin 2013 et est annoncée ici.
Le fichier zip ici présent contient uniquement les sources de MediaSPIP en version standalone.
Comme pour la version précédente, 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 (...) -
Mise à disposition des fichiers
14 avril 2011, parPar défaut, lors de son initialisation, MediaSPIP ne permet pas aux visiteurs de télécharger les fichiers qu’ils soient originaux ou le résultat de leur transformation ou encodage. Il permet uniquement de les visualiser.
Cependant, il est possible et facile d’autoriser les visiteurs à avoir accès à ces documents et ce sous différentes formes.
Tout cela se passe dans la page de configuration du squelette. Il vous faut aller dans l’espace d’administration du canal, et choisir dans la navigation (...) -
MediaSPIP version 0.1 Beta
16 avril 2011, parMediaSPIP 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 (...)
Sur d’autres sites (5539)
-
FFMPEG Decoding - Memory Leak
1er mai 2013, par SpamdarkDeveloping an application for a test, I encountered an error. Meanwhile the packets were proccessed, I got a very horrible problem, a memory leak.
The av_free_packet is applied correctly, I think (See the code). When I run the app, the memory grows up to 500MB meanwhile it's playing the audio file, that's not normal. VLC or WMplayer (Windows Media Player) just wastes 30/20mb reading that file.
Here is the code :
static AVPacket pkt;
static uint8_t *audio_pkt_data = NULL;
static int audio_pkt_size = 0;
static AVFrame frame;
static bool first_time = true;
if(first_time){
first_time=false;
}
int len1, data_size = 0;
for(;;){
bool do_rt = false;
while(audio_pkt_size > 0){
int obt_frame = 0;
len1 = avcodec_decode_audio4(_audio_ccontext,&frame,&obt_frame,&pkt);
if(len1 < 0){
audio_pkt_size = 0;
break;
}
audio_pkt_data+=len1;
audio_pkt_size-=len1;
if(obt_frame){
data_size = av_samples_get_buffer_size(NULL,channel_count,sample_fr,_audio_ccontext->sample_fmt,1);
memcpy((int16_t*)audio_buf,frame.data[0],data_size);
}
if(data_size <= 0){
continue;
}
do_rt = true;
}
if(pkt.data){
//MessageBox(0,"hi","Hi",MB_OK); // This is only for test if the app si reaching this av_free_packet
av_free_packet(&pkt);
}
if(do_rt){
return data_size;
}
// Try to get a new packet
if(!audio_packets.empty()){
WaitForSingleObject(Queue_Audio_Mutex,INFINITE);
pkt = *audio_packets.front();
audio_packets.pop();
ReleaseMutex(Queue_Audio_Mutex);
audio_pkt_size = pkt.size;
audio_pkt_data = pkt.data;
}else{
return -1;
}
}
return 0;
}I would appreciate your help. Thank you very much.
-
Revision 8eec5cad50 : Merge "Fixing memory leak introduced in previous commit."
8 avril 2014, par Dmitry KovalevMerge "Fixing memory leak introduced in previous commit."
-
avformat/wavenc : Fix leak and segfault on reallocation error
22 février 2021, par Andreas Rheinhardtavformat/wavenc : Fix leak and segfault on reallocation error
Up until now, the wav muxer used a reallocation of the form ptr =
av_realloc(ptr, size) ; that leaks upon error. Furthermore, if a
failed reallocation happened when writing the trailer, a segfault
would occur due to avio_write(NULL, size) because the muxer only
prints an error message upon allocation error, but does not return
the error.Moreover setting the pointer to the buffer to NULL on error seems to
be done on purpose in order to record that an error has occured so that
outputting the peak values is no longer attempted. This behaviour has
been retained by simply disabling whether peak data should be written
if an error occurs.Finally, the reallocation is now done once per peak block and not once
per peak block per channel ; it is also done with av_fast_realloc and not
with a linear size increase.Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>