Recherche avancée

Sur d’autres sites (6349)

• libavcodec/amfenc : add AV1 encoding support

  20 décembre 2022, par Dmitrii Ovchinnikov

  libavcodec/amfenc : add AV1 encoding support
  Tested-by : Jean-Baptiste Kempf <jb@videolan.org>
  

  • [DH] configure
  • [DH] libavcodec/Makefile
  • [DH] libavcodec/allcodecs.c
  • [DH] libavcodec/amfenc.c
  • [DH] libavcodec/amfenc.h
  • [DH] libavcodec/amfenc_av1.c

• lavfi/delogo : avoid propagation of rounding errors in chroma planes

  2 juillet 2013, par Jean Delvare

  lavfi/delogo : avoid propagation of rounding errors in chroma planes
  When operating on subsampled chroma planes, some rounding is taking
  
  place. The left and top borders are rounded down while the width and
  
  height are rounded up, so all rounding is done outward to guarantee the
  
  logo area is fully covered.
  The problem is that the width and height are counted from the
  
  unrounded left and top borders, respectively. So if the left or top
  
  border position has indeed been rounded down, and the width or height
  
  needs no rounding (up), the position of the the right or bottom border
  
  will be effectively rounded down, i.e. inward.
  The issue can easily be seen with a yuv240p input and
  
    -vf delogo=45:45:60:40:show=1 -vframes 1 delogo-bug.png
  
  (or virtually any logo area with odd x and y and even width and
  
  height.) The right and bottom chroma borders (in green) are clearly
  
  off.
  In order to fix this, the width and height must be adjusted to include
  
  the bits lost in the rounding of the left and top border positions,
  
  respectively, prior to being themselves rounded up.
  Signed-off-by : Jean Delvare <khali@linux-fr.org>
  
  Signed-off-by : Michael Niedermayer <michaelni@gmx.at>
  

  • [DH] libavfilter/vf_delogo.c
  • [DH] tests/ref/fate/filter-delogo

• Documentation #4098 : Compléter la documentation de #TRI pour générer un lien de tri avec un sens ...

  28 septembre 2018, par cedric -

  Juste pour être sûr, ce que Jean-Luc précise c’est que tu peux générer deux liens de changement de sens de tri avec la syntaxe suivante :
  

  [(#TRI’>’, #CHEMIN_IMAGEtri-asc-16.png|balise_img<:par_tri_croissant :>)]
  [(#TRI’<’, #CHEMIN_IMAGEtri-desc-16.png|balise_img<:par_tri_decroissant :>)]
  

  
  comme dans https://zone.spip.org/trac/spip-zone/browser/spip-zone/_plugins_/albums/branches/v2/prive/objets/liste/albums.html#L47
  Ce sont 2 liens uniques qu’on met en général en début de bare de tri.
  Mais tu peux aussi les générer de manière contextuelle à côte de chaque lien en testant le champ de tri :
  

  [(#TRIid_album, <:medias:par_id :>)]
  [(#TRI|==id_album|oui)
    [(#TRI’>’, #CHEMIN_IMAGEtri-asc-16.png|balise_img<:par_tri_croissant :>)]
    [(#TRI’<’, #CHEMIN_IMAGEtri-desc-16.png|balise_img<:par_tri_decroissant :>)]
  ]
  

  Bon je réponds un petit peu à côté de la question mais quand même donc : on peut générer des liens de sens de tri dynamique, et les mettre en contextuel à côté de chaque lien de tri si c’est ce que tu veux.

  C’est vrai que le même lien qui change le sens du tri "comme dans phpMyAdmin" ce n’est pas prévu, mais a moitié aussi parce que je ne suis pas du tout certain que ce soit une bonne pratique accessibilité/usabilité
  (ie le même lien dont l’action change selon le contexte, ce n’est pas hyper cognitif)

  Donc à voir/discuter sous cet aspect peut-être aussi avant de coder quoi que ce soit de plus