Recherche avancée

Sur d’autres sites (10987)

• Revision 69dc876b4e : Set uv_crop_height/width in all the places When configuring the buffer make sur

  15 août 2014, par Johann

  Changed Paths :
   Modify /vp8/vp8_cx_iface.c

  
   Modify /vp8/vp8_dx_iface.c

  
  
  Set uv_crop_height/width in all the places

  When configuring the buffer make sure to set all the (now) required
  fields. Use the canonical variables and match the style from vpx_scale.

  https://code.google.com/p/webm/issues/detail?id=841

  Change-Id : I71b43d4a03756b8b2d6d60fdf8d7bf41b8041787

• lavc/vc1dsp : R-V V vc1_unescape_buffer

  12 mai 2024, par Rémi Denis-Courmont

  lavc/vc1dsp : R-V V vc1_unescape_buffer
  Notes :
  
   The loop is biased toward no unescaped bytes as that should be most common.
  
   The input byte array is slid rather than the (8 times smaller) bit-mask,
  
    as RISC-V V does not provide a bit-mask (or bit-wise) slide instruction.
  
   There are two comparisons with 0 per iteration, for the same reason.
  
   In case of match, bytes are copied until the first match, and the loop is
  
    restarted after the escape byte. Vector compression (vcompress.vm) could
  
    discard all escape bytes but that is slower if escape bytes are rare.
  Further optimisations should be possible, e.g. :
  
   processing 2 bytes fewer per iteration to get rid of a 2 slides,
  
   taking a short cut if the input vector contains less than 2 zeroes.
  
  But this is a good starting point :
  T-Head C908 :
  
  vc1dsp.vc1_unescape_buffer_c :      12749.5
  
  vc1dsp.vc1_unescape_buffer_rvv_i32 : 6009.0
  SpacemiT X60 :
  
  vc1dsp.vc1_unescape_buffer_c :      11038.0
  
  vc1dsp.vc1_unescape_buffer_rvv_i32 : 2061.0
  

  • [DH] libavcodec/riscv/vc1dsp_init.c
  • [DH] libavcodec/riscv/vc1dsp_rvv.S

• Anomalie #4612 (Nouveau) : copie_locale() et non-ASCII

  4 décembre 2020, par RastaPopoulos ♥

  Il semblerait que copie_locale() n’aime pas les chemins avec du non-ASCII. Mais parce que curl n’aime pas non plus.

  Exemple d’URL que j’avais, qui marche bien dans le navigateur, Firefox s’en sortant comme il faut :
  http://www.sppef.fr/wp-content/uploads/2018/10/sppef_chapelle-sainte-anne-mh-tign®.apr¿s-le-supplice-de-la-croix-le-supplice-des-pales..jpg

  Quand on recopie depuis Firefox, il a modifié et a encodé en % les non-ASCII, ce qui donne :
  http://www.sppef.fr/wp-content/uploads/2018/10/sppef_chapelle-sainte-anne-mh-tign%C2%AE.apr%C2%BFs-le-supplice-de-la-croix-le-supplice-des-pales..jpg

  Et là cette URL transformée fonctionne parfaitement avec curl et copie_locale().

  Il n’y a pas de fonction pour ça en PHP, n’encode que les caractères chelous, mais pas les " :" "/" etc. Stackoverflow donne comme solution en PHP :
  $url = preg_replace_callback('/[^\x20-\x7f]/', function($match) { return urlencode($match[0]); }, $url);

  Et ça marche parfaitement avec ça !

  Ne faudrait-il donc pas intégrer en permanence cette transformation dans notre copie_locale() ?