Recherche avancée

Médias (39)

Mot : - Tags -/audio

Autres articles (103)

  • 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

  • De l’upload à la vidéo finale [version standalone]

    31 janvier 2010, par

    Le chemin d’un document audio ou vidéo dans SPIPMotion est divisé en trois étapes distinctes.
    Upload et récupération d’informations de la vidéo source
    Dans un premier temps, il est nécessaire de créer un article SPIP et de lui joindre le document vidéo "source".
    Au moment où ce document est joint à l’article, deux actions supplémentaires au comportement normal sont exécutées : La récupération des informations techniques des flux audio et video du fichier ; La génération d’une vignette : extraction d’une (...)

  • Encodage et transformation en formats lisibles sur Internet

    10 avril 2011

    MediaSPIP transforme et ré-encode les documents mis en ligne afin de les rendre lisibles sur Internet et automatiquement utilisables sans intervention du créateur de contenu.
    Les vidéos sont automatiquement encodées dans les formats supportés par HTML5 : MP4, Ogv et WebM. La version "MP4" est également utilisée pour le lecteur flash de secours nécessaire aux anciens navigateurs.
    Les documents audios sont également ré-encodés dans les deux formats utilisables par HTML5 :MP3 et Ogg. La version "MP3" (...)

Sur d’autres sites (6438)

  • avformat/allformats : Fix data race when accessing devices lists

    1er octobre 2021, par Andreas Rheinhardt
    avformat/allformats : Fix data race when accessing devices lists
    

    Up until now setting the input and output devices lists is guarded
    by a mutex. This prevents data races emanating from multiple concurrent
    calls to avpriv_register_devices() (triggered by multiple concurrent
    calls to avdevice_register_all()). Yet reading the lists pointers was
    done without any lock and with nonatomic variables. This means that
    there are data races in case of concurrent calls to
    av_(de)muxer_iterate() and avdevice_register_all() (but only if the
    iteration in av_(de)muxer_iterate exhausts the non-device (de)muxers).

    This commit fixes this by putting said pointers into atomic objects.
    Due to the unavailability of _Atomic the object is an atomic_uintptr,
    leading to ugly casts. Switching to atomics also allowed to remove
    the mutex currently used in avpriv_register_devices().

    Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

    • [DH] libavformat/allformats.c
  • avutil/cpu : Fix race condition in av_cpu_count()

    2 décembre 2020, par Andreas Rheinhardt
    avutil/cpu : Fix race condition in av_cpu_count()
    

    av_cpu_count() intends to emit a debug message containing the number of
    logical cores when called the first time. The check currently works with
    a static volatile int ; yet this does not help at all in case of
    concurrent accesses by multiple threads. So replace this with an
    atomic_int.

    Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

    • [DH] libavutil/cpu.c
  • avformat/libsrt : fix race condition with libsrt_network_wait_fd and epoll

    31 janvier 2021, par Marton Balint
    avformat/libsrt : fix race condition with libsrt_network_wait_fd and epoll
    

    The way SRT's async / epoll-based IO works is that the event status is stored
    in the epoll containers. That is, if an event occurs on an SRT socket, and that
    SRT socket isn't part of any epoll container, then that event is lost. If we
    later add that socket to an epoll container, we still won't receive the event
    even if it wasn't serviced.

    Therefore we create the epoll and put the fd into it right after the connection
    is established.

    See http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2021-January/275334.html

    Signed-off-by : Marton Balint <cus@passwd.hu>

    • [DH] libavformat/libsrt.c