Recherche avancée

Médias (1)

Mot : - Tags -/portrait

Autres articles (102)

  • Amélioration de la version de base

    13 septembre 2013

    Jolie sélection multiple
    Le plugin Chosen permet d’améliorer l’ergonomie des champs de sélection multiple. Voir les deux images suivantes pour comparer.
    Il suffit pour cela d’activer le plugin Chosen (Configuration générale du site > Gestion des plugins), puis de configurer le plugin (Les squelettes > Chosen) en activant l’utilisation de Chosen dans le site public et en spécifiant les éléments de formulaires à améliorer, par exemple select[multiple] pour les listes à sélection multiple (...)

  • Emballe médias : à quoi cela sert ?

    4 février 2011, par

    Ce plugin vise à gérer des sites de mise en ligne de documents de tous types.
    Il crée des "médias", à savoir : un "média" est un article au sens SPIP créé automatiquement lors du téléversement d’un document qu’il soit audio, vidéo, image ou textuel ; un seul document ne peut être lié à un article dit "média" ;

  • Des sites réalisés avec MediaSPIP

    2 mai 2011, par

    Cette page présente quelques-uns des sites fonctionnant sous MediaSPIP.
    Vous pouvez bien entendu ajouter le votre grâce au formulaire en bas de page.

Sur d’autres sites (10841)

  • fftools/resources/resman : Don't alloc ResourceManager, fix race

    1er juin, par Andreas Rheinhardt
    fftools/resources/resman : Don't alloc ResourceManager, fix race

    The resman_ctx pointer was accessed outside of its guarding
    
mutex.
    

    Also make the ResourceManager static.
    

    Reviewed-by : softworkz . <softworkz-at-hotmail.com@ffmpeg.org>
    
Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
    • [DH] fftools/resources/resman.c

  • lavc/vvc : Fix race condition for MVs cropped to subpic

    30 décembre 2024, par Frank Plowman
    lavc/vvc : Fix race condition for MVs cropped to subpic

    When the current subpicture has sps_subpic_treated_as_pic_flag equal to
    
1, motion vectors are cropped such that they cannot point to other
    
subpictures.  This was accounted for in the prediction logic, but not
    
in pred_get_y, which is used by the scheduling logic to determine which
    
parts of the reference pictures must have been reconstructed before
    
inter prediction of a subsequent frame may begin.  Consequently, where a
    
motion vector pointed to a location significantly above the current
    
subpicture, there was the possibility of a race condition.  Patch fixes
    
this by cropping the motion vector to the current subpicture in
    
pred_get_y.
    

    Signed-off-by : Frank Plowman <post@frankplowman.com>
    • [DH] libavcodec/vvc/ctu.c

  • avcodec/h264dec : Fix data race when updating decode_error_flags

    12 septembre 2023, par Andreas Rheinhardt
    avcodec/h264dec : Fix data race when updating decode_error_flags

    When using multi-threaded decoding, every decoding thread
    
has its own DBP consisting of H264Pictures and each of these
    
points to its own AVFrames. They are synced during
    
update_thread_context via av_frame_ref() and therefore
    
the threads actually decoding (as well as all the others)
    
must not modify any field that is copied by av_frame_ref()
    
after ff_thread_finish_setup().
    

    Yet this is exactly what happens when an error occurs
    
during decoding and the AVFrame's decode_error_flags are updated.
    
Given that these errors only become apparent during decoding,
    
this can't be set before ff_thread_finish_setup() without
    
defeating the point of frame-threading ; in practice,
    
this meant that the decoder did not set these flags correctly
    
in case frame-threading was in use. (This means that e.g.
    
the ffmpeg cli tool fails to output its "corrupt decoded frame"
    
message in a nondeterministic fashion.)
    

    This commit fixes this by adding a new H264Picture field
    
that is actually propagated across threads ; the field
    
is an AVBufferRef* whose data is an atomic_int ; it is
    
atomic in order to allow multiple threads to update it
    
concurrently and not to provide synchronization
    
between the threads setting the field and the thread
    
ultimately returning the AVFrame.
    

    This unfortunately has the overhead of one allocation
    
per H264Picture (both the original one as well as
    
creating a reference to an existing one), even in case
    
of no errors. In order to mitigate this, an AVBufferPool
    
has been used and only if frame-threading is actually
    
in use. This expense will be removed as soon as
    
a proper API for refcounted objects (not based upon
    
AVBuffer) is in place.
    

    Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
    • [DH] libavcodec/h264_picture.c
    • [DH] libavcodec/h264_slice.c
    • [DH] libavcodec/h264dec.c
    • [DH] libavcodec/h264dec.h

Navigation