Recherche avancée

Sur d’autres sites (10363)

• avutil/mem : Handle fast allocations near UINT_MAX properly

  5 juillet 2022, par Andreas Rheinhardt

  avutil/mem : Handle fast allocations near UINT_MAX properly
  av_fast_realloc and av_fast_mallocz ? store the size of
  
  the objects they allocate in an unsigned. Yet they overallocate
  
  and currently they can allocate more than UINT_MAX bytes
  
  in case a user has requested a size of about UINT_MAX * 16 / 17
  
  or more if SIZE_MAX > UINT_MAX (and if the user increased
  
  max_alloc_size via av_max_alloc). In this case it is impossible
  
  to store the true size of the buffer via the unsigned* ;
  
  future requests are likely to use the (re)allocation codepath
  
  even if the buffer is actually large enough because of
  
  the incorrect size.
  Fix this by ensuring that the actually allocated size
  
  always fits into an unsigned. (This entails erroring out
  
  in case the user requested more than UINT_MAX.)
  Reviewed-by : Tomas Härdin <tjoppen@acc.umu.se>
  
  Reviewed-by : Anton Khirnov <anton@khirnov.net>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavutil/mem.c

• avcodec/decode : Reset MMX state for receive_frame decoders, too

  14 mars 2023, par Andreas Rheinhardt

  avcodec/decode : Reset MMX state for receive_frame decoders, too
  FFmpeg's assembly code currently does not abide by the
  
  plattform-specific ABIs wrt its handling of the X86 MMX flag :
  
  Resetting the MMX state is deferred to avoid doing it multiple times
  
  instead of ensuring that the CPU is in floating point state
  
  upon return from any function.
  Furthermore, resetting said state is sometimes done generically,
  
  namely for all the decoders using the ordinary decode callback ;
  
  yet this is not done for the decoders using the receive_frame API.
  This led to problems when MJPEG (and the MJPEG-based decoders)
  
  were switched to the receive_frame API in commit
  
  e9a2a8777317d91af658f774c68442ac4aa726ec, because ff_mjpeg_decode_sos()
  
  only resets the MMX state on success, not on failure.
  
  Such issues are probably still possible with SMVJPEG, which still
  
  uses the receive_frame API. See issue #10210.
  This commit therefore also resets the MMX state for
  
  the receive_frame API to avoid any more surprises of this sort.
  Reviewed-by : Anton Khirnov <anton@khirnov.net>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavcodec/decode.c

• Anomalie #3017 : Gestion des versions de plugins

  22 mars 2021, par RastaPopoulos ♥

  Pour complément : c’est donc prévu dans les maquettes, qui sont déjà implémentés à 90% en SPIP 3.3 mais… ce point n’est pas du tout prévu dans l’API de SVP ! Et donc pour ce point, la première étape, c’est que l’API doit savoir gérer plusieurs versions, pas juste "la dernière".

  C’est notamment très (très !) important si on veut juste mettre à jour pour la sécu et petites améliorations, mais qu’on ne veut absolument pas changer de branche X qui casse la compat. Ce point est donc indispensable pour arrêter de faire des faux plugins différents avec préfixes différents, pour changer des grosses choses sans que les gens mettent à jour et que ça casse chez eux (bootstrap, etc) : ça devrait dans le futur bien rester le même préfixe, et les gens doivent pouvoir rester sur la même branche fonctionnelle.