Recherche avancée

Médias (91)

Autres articles (29)

  • Contribute to a better visual interface

    13 avril 2011

    MediaSPIP is based on a system of themes and templates. Templates define the placement of information on the page, and can be adapted to a wide range of uses. Themes define the overall graphic appearance of the site.
    Anyone can submit a new graphic theme or template and make it available to the MediaSPIP community.

  • Organiser par catégorie

    17 mai 2013, par

    Dans 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 (...)

  • Qu’est ce qu’un éditorial

    21 juin 2013, par

    Ecrivez votre de point de vue dans un article. Celui-ci sera rangé dans une rubrique prévue à cet effet.
    Un éditorial est un article de type texte uniquement. Il a pour objectif de ranger les points de vue dans une rubrique dédiée. Un seul éditorial est placé à la une en page d’accueil. Pour consulter les précédents, consultez la rubrique dédiée.
    Vous pouvez personnaliser le formulaire de création d’un éditorial.
    Formulaire de création d’un éditorial Dans le cas d’un document de type éditorial, les (...)

Sur d’autres sites (7228)

  • Révision 24236 : Fix la langue de mail d’envoi des identifiants : il faut prendre celle de l’auteu...

    22 février 2019, par cerdic -
  • 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
  • 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