Recherche avancée

Médias (1)

Mot : - Tags -/pirate bay

Autres articles (53)

  • Installation en mode ferme

    4 février 2011, par

    Le mode ferme permet d’héberger plusieurs sites de type MediaSPIP en n’installant qu’une seule fois son noyau fonctionnel.
    C’est la méthode que nous utilisons sur cette même plateforme.
    L’utilisation en mode ferme nécessite de connaïtre un peu le mécanisme de SPIP contrairement à la version standalone qui ne nécessite pas réellement de connaissances spécifique puisque l’espace privé habituel de SPIP n’est plus utilisé.
    Dans un premier temps, vous devez avoir installé les mêmes fichiers que l’installation (...)

  • 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

  • Use, discuss, criticize

    13 avril 2011, par

    Talk to people directly involved in MediaSPIP’s development, or to people around you who could use MediaSPIP to share, enhance or develop their creative projects.
    The bigger the community, the more MediaSPIP’s potential will be explored and the faster the software will evolve.
    A discussion list is available for all exchanges between users.

Sur d’autres sites (8532)

  • avformat/mov : Increment stsd_count while processing stsd data ; avoids leaks.

    22 novembre 2017, par Dale Curtis
    avformat/mov : Increment stsd_count while processing stsd data ; avoids leaks.

    In the event of ff_mov_read_stsd_entries() failure, sc->stsd_count
    
is not updated, even if the function allocates extradata memory.
    
Instead update the sc->stsd_count as entries are parsed so that
    
mov_read_close() can do the right thing.
    

    Signed-off-by : Dale Curtis <dalecurtis@chromium.org>
    
Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
    • [DH] libavformat/mov.c

  • lavu : fix memory leaks by using a mutex instead of atomics

    14 novembre 2014, par wm4
    lavu : fix memory leaks by using a mutex instead of atomics

    The buffer pool has to atomically add and remove entries from the linked
    
list of available buffers. This was done by removing the entire list
    
with a CAS operation, working on it, and then setting it back again
    
(using a retry-loop in case another thread was doing the same thing).
    

    This could effectively cause memory leaks : while a thread was working on
    
the buffer list, other threads would allocate new buffers, increasing
    
the pool’s total size. There was no real leak, but since these extra
    
buffers were not needed, but not free’d either (except when the buffer
    
pool was destroyed), this had the same effects as a real leak. For some
    
reason, growth was exponential, and could easily kill the process due
    
to OOM in real-world uses.
    

    Fix this by using a mutex to protect the list operations. The fancy
    
way atomics remove the whole list to work on it is not needed anymore,
    
which also avoids the situation which was causing the leak.
    

    Signed-off-by : Anton Khirnov <anton@khirnov.net>
    • [DBH] libavutil/buffer.c
    • [DBH] libavutil/buffer_internal.h

  • mpegts : Fix memory leaks and related crashes in mpegs_write_header()

    6 août 2014, par Diego Biurrun
    mpegts : Fix memory leaks and related crashes in mpegs_write_header()
    • [DBH] libavformat/mpegtsenc.c

Navigation