Recherche avancée

Sur d’autres sites (12598)

• avcodec/ffv1dec_template : Optimize common case in run mode

  23 mai 2019, par Michael Niedermayer

  avcodec/ffv1dec_template : Optimize common case in run mode
  Fixes : Timeout (14sec -> 9sec)
  
  Fixes : 13398/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FFV1_fuzzer-5664106709778432
  decode_line() becomes 1% faster for fate/vsynth2-ffv1.avi
  
  for another fate sample there is a 0.5% speedup
  
  the effect should be bigger for files with "flat" colored areas
  
  the new faster branch is used in 97-100% of the cases in fate samples
  
  compared to the older more complex (which i tested)
  vsynth3-ffv1-v3-bgr0.avi had the lowest percentual useage of about 97%
  Found-by : continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavcodec/ffv1dec_template.c

• Revision 3606b78108 : Modified test for auto key frame detection. The existing test was triggering a

  16 avril 2015, par paulwilkins

  Changed Paths :
   Modify /vp9/encoder/vp9_firstpass.c

  
  
  Modified test for auto key frame detection.

  The existing test was triggering a lot of false positives on some types
  of animated material with very plain backgrounds. These were triggering
  code designed to catch key frames in letter box format clips.

  This patch tightens up the criteria and imposes a minimum requirement
  on the % blocks coded intra in the first pass and the ratio between the
  % coded intra and the modified inter % after discounting neutral (flat)
  blocks that are coded equally well either way.

  On a particular problem animation clip this change eliminated a large
  number of false positives including some cases where the old code
  selected kf several times in a row. Marginal false negatives are less
  damaging typically to compression and in the problem clip there are now
  a couple of cases where "visual" scene cuts are ignored because of well
  correlated content across the scene cut.

  Replaced some magic numbers related to this with #defines and added
  explanatory comments.

  Change-Id : Ia3d304ac60eb7e4323e3817eaf83b4752cd63ecf

• Anomalie #3686 : formulaire_editer_article_verifier : vérification incomplète

  21 février 2016, par Peet du

  La ligne https://core.spip.net/projects/spip/repository/entry/spip/prive/formulaires/editer_article.php#L157, vient de
  https://core.spip.net/issues/2508.

  L’avantage (?) de https://core.spip.net/projects/spip/repository/revisions/19075, c’est que ça gère aussi bien les cas de création et de modification d’un article dans une rubrique interdite.

  J’ai donc testé mon patch avec le cas d’un admin restreint et il n’y a pas d’effet de bord : ceci grâce à autoriser_article_modifier().

  Il est donc question ici de compléter/corriger cette demande : il doit être possible de voir et de modifier, même si il est interdit de créer.

  Le bug que j’ai trouvé :¶

  C’est le cas qui se présente avec le plugin LIM

  1- un article ou des articles ont été créés dans une rubrique ;
  2- puis le webmestre décide plus tard d’interdire la création de nouveaux articles dans cette même rubrique, ceci grâce à une fonction du plugin LIM ;
  3- Mais si il n’est plus possible de créer un article dans cette rubrique, LIM gère le cas où l’auteur veut les modifier ses articles présents dans cette rubrique.

  Donc le bug soulevé vient du fait que le plugin LIM surcharge l’autorisation autoriser_rubrique_publierdans(). Plus exactement, il ajoute une condition.
  voir http://zone.spip.org/trac/spip-zone/changeset/95014/_plugins_/lim/trunk/lim_autorisations.php.

  Je précise que cette fonctionnalité du plugin LIM pose un problème seulement avec l’objet Article. Pas avec les autres objets éditoriaux.

  Voilà. J’espère n’avoir rien oublié.