Recherche avancée

Sur d’autres sites (7280)

• Anomalie #3991 : Erreur compression CSS et base64

  29 août 2017, par tcharlss (*´_ゝ｀)

  La ligne fautive se trouve ici : https://zone.spip.org/trac/spip-zone/browser/_core_/plugins/compresseur/inc/compresseur_minifier.php#L100

  // zero est zero, quelle que soit l’unite (sauf pour % car casse les @keyframes cf https://core.spip.net/issues/3128)
  $contenu = preg_replace("/([^0-9.]0)(em|px|pt)/ms", "$1", $contenu) ;
  

  Ça cherche le nombre zéro précédé de n’importe quel caractère (autre qu’un chiffre) ou d’un point.
  Du coup ça peut matcher avec les data URIs :
  

  @font-facefont-family :’spip’ ;src:url("data:application/font-woff ;base64,abc0pxyz") ;
  

  Pour éviter ce souci, on pourrait préciser exactement quels caractères peuvent précéder le zéro pour considérer qu’il s’agit d’une unité. On peut avoir :

  1) deux points
  

  font-size:0px ;
  

  2) un ou plusieurs espaces
  

  font-size : 0px ;
  font-size : calc(10px + 0px) ;
  

  3) une parenthèse dans le cas de calc()
  

  font-size : calc(0px) ;
  

  4) Autres unités

  À noter qu’il y a aussi pas mal d’autres unités qui ne sont pas prises en compte dans la regex actuelle : https://www.w3schools.com/cssref/css_units.asp
  

  rem ex pc
  vh vw vmin vmax 
  cm mm in
  ch 
  

  ---

  Ce qui donne au final la regex suivante, qui laisse mes data URIs tranquilles :
  

  $contenu = preg_replace("/((?: :|\s+|\()0)(em|px|pt|rem|ex|pc|vh|vw|vmin|vmax|cm|mm|in|ch)/ms", "$1", $contenu) ;
  

• Evolution #3996 (Nouveau) : Y a t-il une limite de taille de cache dans SPIP ?

  9 septembre 2017, par Julien -

  Ticket qui fait suite à des observations sur #3843.

  cedric :

  1/ il n’y a plus de quota cache en SPIP 3.1+ (aucune taille limite, c’est un nombre de slots qui fixe la limite)
  2/ les images stockées dans local/ n’ont jamais été comptées dans la taille du cache et n’ont aucune influence

  marcimat :

  Notons que le génie ’invalideur’ est toujours appelé et utilise ’quota_cache’ ; le formulaire de vidage de cache affiche aussi le quota.
  Probablement du code mort dans les 2 cas.

  Ref dans le code :
  https://core.spip.net/projects/spip/repository/entry/spip/ecrire/inc_version.php#L286
  https://core.spip.net/projects/spip/repository/entry/spip/ecrire/inc/genie.php#L141
  https://core.spip.net/projects/spip/repository/entry/spip/ecrire/inc/invalideur.php#L226

  dans la doc :
  https://programmer.spip.net/Configurer-le-cache

• Different video players showing incorrect mp4 resolution after ffmpeg conversion

  18 novembre 2016, par Nova

  After getting help from http://stackoverflow.com/a/40601020/6318164 on how to convert webm to mp4. The result avoiding losing the video ratio by setting the height resolution with -vf scale=-2:720.

  I then came across another problem. I’ve found both width and height had to be supported for the video players, when I thought it was just the height that had to be specified.

  After browsing around I found this script http://stackoverflow.com/a/35487394/6318164 were I can change the video’s canvas to a common width and height standard. It shrinks the video to fit inside the center of specified canvas without losing the ratio while filling the empty space with black padding if I’m correct, which is the result I want.

  However, although it solved the playback problems in all the players, I’ve found different video players show different resolution information of the same video.

  I’ve modified the script here for Linux terminal use.

  X=1280; Y=720; ffmpeg -i old.webm -t 5 -vf "scale=min(iw*$Y/ih\,$X):min($Y\,ih*$X/iw),pad=$X:$Y:($X-iw)/2:($Y-ih)/2" new.mp4

  This is the research on the resolution differences I’ve found for value I set.

  X=1280; Y=720;
  
  
  
  webm          -> mp4
  
  =========================================================
  
  1280x752      -> 1280x720 X-plore (Android)
  
  Not supported -> 1339x720 Telegram (Android)
  
  1338x752      -> 1340x720 GNOME MPlayer (Linux)
  
  Not supported -> ???????? Built-in Video Player (Android)

  The question is, I’m I doing anything wrong with the ffmpeg conversion to return incorrect resolutions for different players ? I checked out some other videos I have and they show the correct resolutions except this converted one.

  Edit

  With the help of the accepted answer. This was my working output if anyone needs it :

  X=1280; Y=720; ffmpeg -i input.webm -vf "scale='if(gt(a*sar,16/9),${X},${Y}*iw*sar/ih)':'if(gt(a*sar,16/9),${X}*ih/iw/sar,${Y})',pad=${X}:${Y}:(ow-iw)/2:(oh-ih)/2,setsar=1" output.mp4