Recherche avancée

Sur d’autres sites (4144)

• avfilter/delogo : Set default band to 1

  7 octobre 2015, par Jean Delvare

  avfilter/delogo : Set default band to 1
  The original interpolation algorithm behaved poorly on the borders and
  
  did not even guarantee continuity at the borders. For this reason, a
  
  second interpolation/blending pass was required on the borders to make
  
  them seamless.
  However, since the interpolation algorithm was improved in June 2013,
  
  the border issues no longer exist. The new algorithm does guarantee
  
  continuity at the borders, making the second pass useless. A larger
  
  band always increases the cumulated interpolation error. In most cases
  
  it also increases the average interpolation error, even though the
  
  samples in the band are only partially interpolated.
  For this reason I would like to get rid of the "band" parameter. As a
  
  first step, let’s change its default value from 4 to 1 and document it
  
  as deprecated.
  I have benchmarked this change on a combination of input sources and
  
  realistic logo areas. Lowering the band value from 4 to 1 resulted in
  
  8 to 39 % less interpolation error per frame (or 1 to 34 % less
  
  interpolation error per luma sample.)
  Signed-off-by : Jean Delvare <jdelvare@suse.de>
  
  Signed-off-by : Stefano Sabatini <stefasab@gmail.com>
  

  • [DH] doc/filters.texi
  • [DH] libavfilter/vf_delogo.c

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

  17 février 2020, par RastaPopoulos ♥

  Ben oui la navigation c’est une partie intégrante de l’ergonomie, et c’est tout l’objet de la première partie de mon message (la deuxième étant quoi faire de plus rapide). Je ne comprends pas le "ce sont des pages indépendantes de l’espace privé", je ne vois pas ce que ça veut dire. Une page de config, c’est bien une page de l’espace privé où on configure une fonctionnalité, ça fait partie intégrante de l’espace privé, et donc doit être rangé de manière trouvable, que ça vienne d’un plugin ou pas, c’est une séparation qui n’est compréhensible que par une minorité.

  Il y a deux chemins principaux :

  1) En terme purement fonctionnel : les utilisateurs n’en savent la plupart du temps rien de savoir d’où vient la fonctionnalité, ce qu’ils ont besoin de savoir c’est "On peut configurer les événements", ou "On peut configurer les documents", etc, et dans ce cas de figure il n’y a aucune raison de distinguer où on peut trouver la page de config, suivant d’où vient la fonctionnalité. On a déjà une entrée principale "Configuration", c’est directement là que devraient être listées toutes les configurations pour être cohérent. Sinon dans Configuration on a parfois des trucs du core, parfois des trucs de plugins, parfois faut aller dans une sous-page pour trouver celles d’autres plugins… comment savoir du premier coup ?

  Jean-Michel est admin non-technique. Jean-Michel sait "j’ai des événements dans mon site". Il se demande s’il y a des choses configurables sur cette fonctionnalité, il n’en sait rien d’où ça vient. Il ne doit pas avoir à chercher à plusieurs endroits pour savoir où ça se configure. Il ouvre donc le menu "Configuration" et il regarde dedans s’il y a une entrée "Événements" ou "Agenda".

  2) En terme technique, les admins de plus haut niveau peuvent parfois ajouter des plugins elleux-mêmes. Dans ce cas on sait qu’on a ajouté le plugin Trucmuche, et on veut le configurer tout de suite : il n’y a pas à partir autre part, on a la liste des plugins actifs sous les yeux, et dans chacun ya un raccourci pour le configurer (c’est ce que fait Wordpress et Drupal aussi).

  Martine est admin technique, de temps en temps elle ajoute ou retire des plugins. Là elle vient d’ajouter le plugin "GIS". Dans sa liste de plugin, elle peut voir immédiatement à cet endroit que le plugin a une page de config et s’y rendre.

  Dans les deux cas de figures, il n’y a pas à savoir "quels plugins ont des pages de config" puisque
  - soit on veut configurer une fonctionnalité et non pas un plugin
  - soit on vient d’installer un plugin, ou comme ton exemple de départ une personne au téléphone nous demande de configurer tel plugin précis, et donc on sait déjà d’avance quel plugin on veut configurer.
  Et si vraiment il faut avoir cette liste (mais ça ne me parait pas le besoin courant suivant les deux scénarios), ça me parait plus logique d’ajouter un filtre directement dans l’espace qui existe déjà pour les plugins, puisque cette liste de plugins existe déjà, et qu’il y a déjà une liste de filtres. Pas besoin d’ouvrir un deuxième espace différent parlant des plugins d’une autre manière.

  Pour le scénario 1, c’est une évolution plus importante oui, mais avec une approche globale, non technique (on configure une fonctionnalité, pas un plugin).

  Pour le scénario 2, c’est quand on sait déjà que c’est plugin, et c’est alors une petite amélioration du bloc actuel. Dans ce cas, je disais que l’approche actuelle était déjà problématique en ergo de masquer des actions avec le hover. C’est pourquoi je proposais que si on améliorait un peu ces blocs, on corrige ce problème en même temps (juste ajouter le label pour Configurer, ne résoudrait pas le fait que les autres actions sont cachées). Si le menu ne convient pas, alors je préfère la solution où on affiche tout en permanence, car ça résout tous les problèmes à la fois pour config et pour les autres actions.

• 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