Recherche avancée

Médias (1)

Mot : - Tags -/iphone

Autres articles (28)

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

  • Librairies et binaires spécifiques au traitement vidéo et sonore

    31 janvier 2010, par

    Les logiciels et librairies suivantes sont utilisées par SPIPmotion d’une manière ou d’une autre.
    Binaires obligatoires FFMpeg : encodeur principal, permet de transcoder presque tous les types de fichiers vidéo et sonores dans les formats lisibles sur Internet. CF ce tutoriel pour son installation ; Oggz-tools : outils d’inspection de fichiers ogg ; Mediainfo : récupération d’informations depuis la plupart des formats vidéos et sonores ;
    Binaires complémentaires et facultatifs flvtool2 : (...)

  • Support audio et vidéo HTML5

    10 avril 2011

    MediaSPIP utilise les balises HTML5 video et audio pour la lecture de documents multimedia en profitant des dernières innovations du W3C supportées par les navigateurs modernes.
    Pour les navigateurs plus anciens, le lecteur flash Flowplayer est utilisé.
    Le lecteur HTML5 utilisé a été spécifiquement créé pour MediaSPIP : il est complètement modifiable graphiquement pour correspondre à un thème choisi.
    Ces technologies permettent de distribuer vidéo et son à la fois sur des ordinateurs conventionnels (...)

Sur d’autres sites (1987)

  • 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