Recherche avancée

Sur d’autres sites (14127)

• avformat/matroskadec : Improve forward compability

  25 mars 2020, par Andreas Rheinhardt

  avformat/matroskadec : Improve forward compability
  Matroska is built around the principle that a reader does not need to
  
  understand everything in a file in order to be able to make use of it ;
  
  it just needs to ignore the data it doesn't know about.
  Our demuxer typically follows this principle, but there is one important
  
  instance where it does not : A Block belonging to a TrackEntry with no
  
  associated stream is treated as invalid data (i.e. the demuxer will try
  
  to resync to the next level 1 element because it takes this as a sign
  
  that it has lost sync). Given that we do not create streams if we don't
  
  know or don't support the type of the TrackEntry, this impairs this
  
  demuxer's forward compability.
  Furthermore, ignoring Blocks belonging to a TrackEntry without
  
  corresponding stream can (in future commits) also be used to ignore
  
  TrackEntries with obviously bogus entries without affecting the other
  
  TrackEntries (by not creating a stream for said TrackEntry).
  Finally, given that matroska_find_track_by_num() already emits its own
  
  error message in case there is no TrackEntry with a given TrackNumber,
  
  the error message (with level AV_LOG_INFO) for this can be removed.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavformat/matroskadec.c

• Evolution #4102 : Ordre des inclures dans cache/charger_plugins_options.php

  26 février 2018, par placido .

  le define() doit être défini dans le inc/truc, action/truc, etc, ce qui permet bien à d’autres de le définir en amont dans leur options.php.

  Euh, oui, enfin à un autre. Premier arrivé, premier servi.

  Exemple d’un cas vécu : un squelette basé sur Zcore et qui se veut plutôt générique. Un sous-plugin qui fait principalement de la personnalisation de ce squelette (genre content/rubrique-2.html, etc ...). Et bien pas possible à son niveau de redefinir _Z_AJAX_PARALLEL_LOAD sur d’autres zblocs puisque déjà définit plus haut. Bon c’est un cas de figure pas si courant, mais ça existe.

  (et ça m’avait bien saoulé pour le surcharger, j’avais fini par le définir dans les mes_options.php du projet alors que je ne l’utilise jamais et que je voulais le faire dans le plugin de mon projet)

  Oui, c’est précisement ce que je cherche à éviter aussi.

  Ta suggestion est donc de corriger les plugins qui déclarent leurs define() dans leur propre fichier options.php, soit. (Tiens, un autre cas ici)
  Au passage, sans doute serait-il judicieux de rajouter une mention explicite à ce sujet dans la documentation et, tant qu’à faire, recommander l’usage de lire_config/ecrire_config plutôt que l’emploi de constantes de personnalisation.

  Donc on oublie l’insertion de trigger_pre_plugins_options() en tête du fichier charger_plugins_options.php ?
  Dommage, car cela apportait un point d’entrée, ouvrant la voie à une solution pour les (rares mais avérés) cas de définition à n+2.

  Si j’en reviens à ma suggestion B), on aurait pu y faire usage d’un pipeline véhiculant un tableau clé/valeur, modifiable suivant l’ordre de surcharge des plugins,et au final boucler sur chaque rangée ainsi :
  

  defined($cle) or define($cle,$valeur) ;
  

  
  Une solution assez classique en somme.

  Dommage aussi qu’un des principes emblématiques de SPIP (la surcharge en cascade) ne propose pas de gestion homogène pour cette délicate question des constantes.

  Concernant ta proposition de pipeline spip_initialisation, tu as déjà évoqué le sujet il me semble. À quel niveau penses-tu mettre le déclencheur ? Il y a un ticket à ce sujet ?

• avformat/matroskadec : Check min_luminance more thoroughly

  16 février 2021, par Andreas Rheinhardt

  avformat/matroskadec : Check min_luminance more thoroughly
  In the absence of an explicitly coded minimal luminance, the current
  
  code inferred it to be -1, an invalid value. Yet it did not check the
  
  value lateron at all, so that if a valid maximum luminance is
  
  encountered, but no minimal luminance, an invalid minimal luminance of
  
   1 is exported. If an minimal luminance element with a negative value is
  
  present, it is exported, too. This can be simply fixed by adding a check
  
  for the value of the element.
  Yet given that a minimal luminance of zero Cd/m² is legal and can be
  
  coded with a length of zero, we must not use a fake default value to
  
  find out whether the element is present or not. Therefore this patch
  
  uses an explicit counter for it.
  While just at it, also check for max_luminance > min_luminance.
  Reviewed-by : Ridley Combs <rcombs@rcombs.me>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavformat/matroskadec.c