Recherche avancée

Sur d’autres sites (7950)

• avcodec/hevcdec : Add stat_coeffs to HEVCABACState

  30 juin 2022, par Andreas Rheinhardt

  avcodec/hevcdec : Add stat_coeffs to HEVCABACState
  The HEVC decoder has both HEVCContext and HEVCLocalContext
  
  structures. The latter is supposed to be the structure
  
  containing the per-slicethread state.
  Yet that is not how it is handled in practice : Each HEVCLocalContext
  
  has a unique HEVCContext allocated for it and each of these
  
  coincides with the main HEVCContext except in exactly one field :
  
  The corresponding HEVCLocalContext.
  
  This makes it possible to pass the HEVCContext everywhere where
  
  logically a HEVCLocalContext should be used.
  This led to confusion in the first version of what eventually became
  
  commit c8bc0f66a875bc3708d8dc11b757f2198606ffd7 :
  
  Before said commit, the initialization of the Rice parameter derivation
  
  state was incorrect ; the fix for single-threaded as well as
  
  frame-threaded decoding was to add backup stats to HEVCContext
  
  that are used when the cabac state is updated*, see
  
  https://ffmpeg.org/pipermail/ffmpeg-devel/2020-August/268861.html
  
  Yet due to what has been said above, this does not work for
  
  slice-threading, because the each HEVCLocalContext has its own
  
  HEVCContext, so the Rice parameter state would not be transferred
  
  between threads.
  This is fixed in c8bc0f66a875bc3708d8dc11b757f2198606ffd7
  
  by a hack : It rederives what the previous thread was and accesses
  
  the corresponding HEVCContext.
  Fix this by treating the Rice parameter state the same way
  
  the ordinary CABAC parameters are shared between threads :
  
  Make them part of the same struct that is shared between
  
  slice threads. This does not cause races, because
  
  the parts of the code that access these Rice parameters
  
  are a subset of the parts of code that access the CABAC parameters.
  * : And if the persistent_rice_adaptation_enabled_flag is set.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavcodec/hevc_cabac.c
  • [DH] libavcodec/hevcdec.c
  • [DH] libavcodec/hevcdec.h

• Anomalie #3043 (Nouveau) : Suggestion ergonomie Interface privée : bouton Sauvegarder "flottant"

  19 août 2013, par YannX spip

  Bonjour,

  Au fur et à mesure de la complexification croissante de SPIP, les formulaires du privé s’allongent....
  vers le bas, alors que nos écrans s’allongent horizontalement !

  Dans la lignée de la taille d’ecran "Elastic" que je viens de decouvrir (avec HEUREUSE surprise),
  je suggère trois axes d’améliorations à discuter :
  - pouvoir rendre le bouton "sauvegarder" flottant (ou bien doublé en heaut de marge droite du menu /option)
  > de façon à toujours avoir accès (sans devoir scroller) quand on fait une modif rapide en début d’article
  avoir une personnalisation différente du menu (inspirée de Luis en 200 ? ),
  qui proposerait de disposer les icones principales du bandeau à gauche
  (à l’exemple de l’interface privée de WP... dont l’ergonomie semble assez souvent reconnue comme exemplaire)
  - utiliser plus largement les colonnes/boites du menu droite pour compléter les saisies...
  (mais cela pourrait nécessiter de revoir l’intégration dans un écran 2-colonnes (qd il existe encore)
  pour que des zones de saisie annexe (je pense en particulier aux mots-clés !! ) soient visibles/accessibles facilement !

  Qu’ne pensez-vous ?

  YannX
  PS n’oublions pas la définition de la majorité des portables : 1360 x 768
  sans oublier le format "vertical" des tablettes ou smartphones...

• Evolution #4429 : Ajouter « configurer » en toutes lettres à côté de l’icône dans la liste des plu...

  17 février 2020, par tcharlss (*´_ゝ｀)

  Oui, une entrée de menu à part pour la configuration des plugins, c’est une piste intéressante.