Recherche avancée

Sur d’autres sites (9531)

• Anomalie #4097 (En cours) : bug HTTPS dans la fonction url_de_base() sur certains serveurs mal con...

  14 février 2018, par Pierre-Aurélien Georges

  Bonjour,

  voici le contexte : le serveur web de mon hébergeur est mal configuré (et je n’ai malheureusement pas réussi à leur faire corriger le problème). Le site web [1] est accessible aussi bien en HTTP qu’en HTTPS, mais en allant sur /ecrire/ ?exec=info je vois que le serveur ne renseigne ni la variable $_SERVER[’HTTPS’] ni la variable $_SERVER["SCRIPT_URI"], et à vrai dire lorsque je compare sur ce serveur un phpinfo() en HTTP et un phpinfo() en HTTPS je vois qu’il y n’a strictement AUCUNE différence entre les deux, et qu’il est donc totalement impossible de savoir (côté serveur) si la requête a été faite en HTTP ou en HTTPS.

  Dans ce contexte bien précis, le code de la fonction url_de_base() situé dans /ecrire/inc/utils.php pose problème, car il se base sur le contenu de ces deux variables $_SERVER[’HTTPS’] et $_SERVER["SCRIPT_URI"] pour choisir entre HTTP et HTTPS et il ne tient absolument pas compte du contenu du champ META, ce qui dans mon cas est bien dommage car j’y ai mis l’url en https:...

  La conséquence de tout ceci est qu’en HTTPS cela entraîne des problèmes d’affichage d’images et de CSS qui ne sont pas bien appliqués, cf. [2]. Sur ce forum, vous verrez que je ne suis pas le seul à avoir affaire à un serveur mal configuré de la sorte, et que nous sommes plusieurs à avoir ce même problème. La solution de bricolage donnée par un des participants du forum est de rajouter dans /config/mes_options.php les deux lignes suivantes :
  

  $_SERVER[’HTTPS’] = "on" ;
  $_SERVER[’SERVER_PORT’]=’443’ ;
  

  
  Ca fonctionne, certes, et c’est donc ce que j’ai fait pour mon site, mais c’est vraiment du bricolage et c’était pas évident de trouver cette astuce !

  Pour faire plus propre et plus simple, serait-il possible à l’avenir de modifier le code de url_de_base() pour qu’en l’absence de ces deux variables $_SERVER[’HTTPS’] et $_SERVER["SCRIPT_URI"], la fonction aille regarder dans META si c’est du http ou du https qui y est renseigné (au lieu de mettre forcément du http) ? En effet, lorsque META commence par "https://" ça veut dire que le serveur gère le HTTPS, et donc s’il ne renseigne pas les variables HTTPS et SCRIPT_URI et bien dans le doute mieux vaut générer des url de base en "https://" plutôt qu’en "http://" car si cette url de base se retrouve mentionnée au sein d’un fichier html ou css, et que le fichier en question est demandé en HTTP, ce n’est pas grave s’il contient des ressources en HTTPS, alors que le contraire pose problème (ne pas mettre de ressources en HTTP au sein d’une page en HTTPS !)

• x86 : Remove X264_CPU_SSE_MISALIGN functions

  5 juillet 2013, par Henrik Gramner

  x86 : Remove X264_CPU_SSE_MISALIGN functions
  Prevents a crash if the misaligned exception mask bit is cleared for some reason.
  Misaligned SSE functions are only used on AMD Phenom CPUs and the benefit is miniscule.
  
  They also require modifying the MXCSR control register and by removing those functions
  
  we can get rid of that complexity altogether.
  VEX-encoded instructions also supports unaligned memory operands. I tried adding AVX
  
  implementations of all removed functions but there were no performance improvements on
  
  Ivy Bridge. pixel_sad_x3 and pixel_sad_x4 had significant code size reductions though
  
  so I kept them and added some minor cosmetics fixes and tweaks.
  

  • [DH] common/cpu.c
  • [DH] common/cpu.h
  • [DH] common/pixel.c
  • [DH] common/x86/cpu-a.asm
  • [DH] common/x86/mc-a.asm
  • [DH] common/x86/mc-a2.asm
  • [DH] common/x86/mc-c.c
  • [DH] common/x86/pixel.h
  • [DH] common/x86/sad-a.asm
  • [DH] common/x86/x86inc.asm
  • [DH] encoder/encoder.c
  • [DH] encoder/lookahead.c
  • [DH] tools/checkasm.c
  • [DH] x264.h

• How can I avoid an ffmpeg out of memory error

  21 mars 2021, par Silentfury

  I use ffmpeg with complex filtering. Input are different sets of FULLHD surveilance camera videos each 10 to 15 seconds long. Set size (number of videos per set) varies. To remove unchanged frames I apply mpdecimate. To avoid being triggered by moving bushes but still keep objects I want to remain, I apply a complex filter :

  


  

  • split the video (the original and a dummy to detect motion/stills)

  


  • scale the dummy down (so the 8x8-block-metric of mpdecimate matches the size of moving objects I want to keep)

  


  • add white boxes to dummy to mask unintendedly moving objects

  


  • apply mpdecimate to dummy to remove non-changing frames

  


  • scale dummy back to original size

  


  • overlay the remaining frames of dummy with matching frames of original

  


  


  All this works fine if the number of input videos is small (less than 100). The memory consupmtion of the ffmpeg process varies somewhere between 2GiB and 5GiB.

  


  If the number of input files gets larger (say 200), the memory consumption suddenly jumps to insane numbers until memory (32GiB plus 33GiB swap) runs out and ffmpeg gets killed. I can not predict if and why this happens. I have one example, where a set of 340 videos worked using 6GiB. Any other set above 100 videos I tried eats all RAM in under two minutes and dies.

  


  There is no particular error message from ffmpeg.

  


  dmesg says :

  


  Out of memory: Kill process 29173 (ffmpeg)
Killed process 29173 (ffmpeg) total-vm:66707800kB


  


  My ffmpeg command :

  


  ffmpeg -f concat -safe 0 -i vidlist -vf 'split=2[full][masked];[masked]scale=w=iw/4:h=ih/4,drawbox=w=51:h=153:x=101:y=0:t=fill:c=white,drawbox=w=74:h=67:x=86:y=49:t=fill:c=white,drawbox=w=51:h=149:x=258:y=0:t=fill:c=white,drawbox=w=13:h=20:x=214:y=103:t=fill:c=white,drawbox=w=29:h=54:x=429:y=40:t=fill:c=white,drawbox=w=35:h=49:x=360:y=111:t=fill:c=white,drawbox=w=26:h=54:x=304:y=92:t=fill:c=white,drawbox=w=48:h=27:x=356:y=105:t=fill:c=white,drawbox=w=30:h=27:x=188:y=124:t=fill:c=white,drawbox=w=50:h=54:x=371:y=7:t=fill:c=white,drawbox=w=18:h=38:x=248:y=107:t=fill:c=white,drawbox=w=21:h=51:x=242:y=33:t=fill:c=white,mpdecimate=hi=64*80:lo=64*40:frac=0.001,scale=w=iw*4:h=ih*4[deduped];[deduped][full]overlay=shortest=1,setpts=N/(15*TB),mpdecimate=hi=64*80:lo=64*50:frac=0.001,setpts=N/(15*TB)' -r 15 -c:v libx265 -preset slower -crf 37 -pix_fmt yuv420p -an result.mkv


  


  ffmpeg version 4.1.6

  


  Debian 4.19.171-2

  


  I hope that my filter can be tuned in some way that achieves the same result but doesn't eat RAM that much - but I have no clue how. Within reasonable limits, I wouldn't mind if processing time suffers. Any hints appreciated.