Recherche avancée

Médias (16)

Mot : - Tags -/mp3

Autres articles (71)

  • Les vidéos

    21 avril 2011, par

    Comme les documents de type "audio", Mediaspip affiche dans la mesure du possible les vidéos grâce à la balise html5 .
    Un des inconvénients de cette balise est qu’elle n’est pas reconnue correctement par certains navigateurs (Internet Explorer pour ne pas le nommer) et que chaque navigateur ne gère en natif que certains formats de vidéos.
    Son avantage principal quant à lui est de bénéficier de la prise en charge native de vidéos dans les navigateur et donc de se passer de l’utilisation de Flash et (...)

  • 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

  • Gestion générale des documents

    13 mai 2011, par

    MédiaSPIP ne modifie jamais le document original mis en ligne.
    Pour chaque document mis en ligne il effectue deux opérations successives : la création d’une version supplémentaire qui peut être facilement consultée en ligne tout en laissant l’original téléchargeable dans le cas où le document original ne peut être lu dans un navigateur Internet ; la récupération des métadonnées du document original pour illustrer textuellement le fichier ;
    Les tableaux ci-dessous expliquent ce que peut faire MédiaSPIP (...)

Sur d’autres sites (10924)

  • pthread_frame : allow per-field ThreadFrame owners.

    3 avril 2017, par Ronald S. Bultje
    pthread_frame : allow per-field ThreadFrame owners.

    This tries to handle cases where separate invocations of decode_frame()
    
(each running in separate threads) write to respective fields in the
    
same AVFrame->data[]. Having per-field owners makes interaction between
    
readers (the referencing thread) and writers (the decoding thread)
    
slightly more optimal if both accesses are field-based, since they will
    
use the respective producer’s thread objects (mutex/cond) instead of
    
sharing the thread objects of the first field’s producer.
    

    In practice, this fixes the following tsan-warning in fate-h264 :
    

    WARNING : ThreadSanitizer : data race (pid=21615)
    
  Read of size 4 at 0x7d640000d9fc by thread T2 (mutexes : write M1006) :
    
    #0 ff_thread_report_progress pthread_frame.c:569 (ffmpeg:x86_64+0x100f7cf54)
    
[..]
    
  Previous write of size 4 at 0x7d640000d9fc by main thread (mutexes : write M1004) :
    
    #0 update_context_from_user pthread_frame.c:335 (ffmpeg:x86_64+0x100f81abb)
    • [DH] libavcodec/h264_slice.c
    • [DH] libavcodec/pthread_frame.c
    • [DH] libavcodec/thread.h
    • [DH] libavcodec/utils.c

  • pthread_frame : make accesses to debug field be protected by owner lock.

    6 avril 2017, par Ronald S. Bultje
    pthread_frame : make accesses to debug field be protected by owner lock.

    The av_log() is done outside the lock, but this way the accesses to the
    
field (reads and writes) are always protected by a mutex. The av_log()
    
is not run inside the lock context because it may involve user callbacks
    
and doing that in performance-sensitive code is probably not a good idea.
    

    This should fix occasional tsan warnings when running fate-h264, like :
    

    WARNING : ThreadSanitizer : data race (pid=10916)
    
  Write of size 4 at 0x7d64000174fc by main thread (mutexes : write M2313) :
    
    #0 update_context_from_user src/libavcodec/pthread_frame.c:335 (ffmpeg+0x000000df7b06)
    
[..]
    
  Previous read of size 4 at 0x7d64000174fc by thread T1 (mutexes : write M2311) :
    
    #0 ff_thread_await_progress src/libavcodec/pthread_frame.c:592 (ffmpeg+0x000000df8b3e)
    • [DH] libavcodec/pthread_frame.c

  • h264 : don’t re-call ff_h264_direct_ref_list_init() w/ frame-mt.

    6 avril 2017, par Ronald S. Bultje
    h264 : don’t re-call ff_h264_direct_ref_list_init() w/ frame-mt.

    I’m hoping that this will address the remaining tsan fate-h264 issues :
    

    WARNING : ThreadSanitizer : data race (pid=24478)
    
  Read of size 8 at 0x7dbc0001c828 by main thread (mutexes : write M3243) :
    
    #0 ff_h264_ref_picture src/libavcodec/h264_picture.c:107 (ffmpeg+0x0000013b78d8)
    
[..]
    
  Previous write of size 1 at 0x7dbc0001c82e by thread T2 (mutexes : write M3245) :
    
    #0 ff_h264_direct_ref_list_init src/libavcodec/h264_direct.c:137 (ffmpeg+0x000001382c93)
    

    But I’m not sure because I haven’t been able to reproduce locally.
    • [DH] libavcodec/h264_slice.c

Navigation