Recherche avancée

Médias (1)

Mot : - Tags -/berlin

Autres articles (44)

  • Demande de création d’un canal

    12 mars 2010, par

    En fonction de la configuration de la plateforme, l’utilisateur peu avoir à sa disposition deux méthodes différentes de demande de création de canal. La première est au moment de son inscription, la seconde, après son inscription en remplissant un formulaire de demande.
    Les deux manières demandent les mêmes choses fonctionnent à peu près de la même manière, le futur utilisateur doit remplir une série de champ de formulaire permettant tout d’abord aux administrateurs d’avoir des informations quant à (...)

  • Gestion de la ferme

    2 mars 2010, par

    La ferme est gérée dans son ensemble par des "super admins".
    Certains réglages peuvent être fais afin de réguler les besoins des différents canaux.
    Dans un premier temps il utilise le plugin "Gestion de mutualisation"

  • MediaSPIP Core : La Configuration

    9 novembre 2010, par

    MediaSPIP Core fournit par défaut trois pages différentes de configuration (ces pages utilisent le plugin de configuration CFG pour fonctionner) : une page spécifique à la configuration générale du squelettes ; une page spécifique à la configuration de la page d’accueil du site ; une page spécifique à la configuration des secteurs ;
    Il fournit également une page supplémentaire qui n’apparait que lorsque certains plugins sont activés permettant de contrôler l’affichage et les fonctionnalités spécifiques (...)

Sur d’autres sites (6042)

  • 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

  • avcodec/hevcdec : Check early whether film grain is supported, fix race

    22 août 2022, par Andreas Rheinhardt
    avcodec/hevcdec : Check early whether film grain is supported, fix race

    Applying film grain happens after ff_thread_finish_setup(),
    
so the parameters synced in hevc_update_thread_context() must not
    
be modified. But this is exactly what happens in case applying
    
film grain fails. (The likely result is that in case of frame threading
    
an uninitialized frame is output.)
    

    Given that it is actually very easy to know in advance whether
    
ff_h274_apply_film_grain() supports a given set of parameters,
    
one can check for this before ff_thread_finish_setup()
    
and avoid allocating an unused buffer lateron.
    

    Reviewed-by : Niklas Haas <ffmpeg@haasn.xyz>
    
Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
    • [DH] libavcodec/h274.h
    • [DH] libavcodec/hevcdec.c
    • [DH] libavcodec/hevcdec.h

Navigation