Recherche avancée

Sur d’autres sites (5157)

• Anomalie #4261 : Vider l’opcache au recalcul et à l’upgrade

  22 novembre 2019, par jluc -

  L’opcache foire aussi les installations de plugins : cf https://www.mail-archive.com/spip-zone@rezo.net/msg49046.html

  Mise à jour du contournement proposé plus haut : il faut aussi vider le cache apcu.

  if (isset($_REQUEST[’var_mode’]) and ($_REQUEST[’var_mode’] == ’recalcul’))

  if (function_exists('spip_clear_varnish_cache'))<br />        spip_clear_varnish_cache();

  include_spip ('inc/invalideur');<br />    suivre_invalideur('recalcul');

  if (function_exists('opcache_reset'))<br />        opcache_reset();

  if (function_exists('apc_clear_cache')) {<br />        apc_clear_cache();<br />        apc_clear_cache('user'); <br />    }

  if (function_exists('apcu_clear_cache')) {<br />        apcu_clear_cache();<br />    }

  spip_log("recalcul a vidé varnish, SPIP, opcache et apc_cache");<br />}

  Mais le mieux serait de mettre ça dans une fonction appelée lors des différentes mise à jour le nécessitant (et pas seulement au recalcul via l’url)

• Gstreamer video increases latency with decreased FPS

  19 novembre 2024, par Ri Di

  I am using RPI 5 to stream the video :

  


  rpicam-vid -t 0 --camera 0 --nopreview --mode 2304:1296:10:P --codec yuv420 
           --width 640 --height 360 --framerate 10 --rotation 0 
           --autofocus-mode manual --inline --listen -o - | 
     ffmpeg -f rawvideo -pix_fmt yuv420p -s:v 640x360 -r 10 -i /dev/stdin 
            -c:v libx264 -preset ultrafast -tune zerolatency -maxrate 300k 
            -bufsize 50k -g 30000 -f mpegts tcp://192.168.0.147:1234


  


  View it with :

  


  gst-launch-1.0 -v tcpserversrc host=0.0.0.0 port=1234 ! queue ! 
    tsdemux ! h264parse ! avdec_h264 ! videorate ! video/x-raw,framerate=10/1 !  
    videoconvert ! autovideosink sync=false


  


  Problem is that with 10 FPS I get around 2s of latency ! While 56 or 120 FPS results in below 300ms latency.

  


  Is the problem in sender or reader side ? Or both ?

  


  I am not planning to use the 10 FPS, its only for demonstration of problem. But I would like to get lower latency at 56 FPS - just like at 120 FPS (around 80-100 ms difference) or maybe even better, as it seems to get lower with higher FPS.

  


  Maybe there is some kind of buffering parameter which holds frames ?

  


  (of course, when testing with higher FPS I change both numbers in sender and the one in reader command. The camera is v3 RPI official)

  


  Also I'd like to mention that same thing happens with ffplay :

  


  ffplay -i -probesize 3000 tcp://0.0.0.0:1234/?listen


  


• Gstreamer video increases latency with decresed FPS

  19 novembre 2024, par Ri Di

  I am using RPI 5 to stream the video :

  


  rpicam-vid -t 0 --camera 0 --nopreview --mode 2304:1296:10:P --codec yuv420 --width 640 --height 360 --framerate 10 --rotation 0 --autofocus-mode manual --inline --listen -o - | ffmpeg -f rawvideo -pix_fmt yuv420p -s:v 640x360 -r 10 -i /dev/stdin -c:v libx264 -preset ultrafast -tune zerolatency -maxrate 300k -bufsize 50k -g 30000 -f mpegts tcp://192.168.0.147:1234


  


  View it with :

  


  gst-launch-1.0 -v tcpserversrc host=0.0.0.0 port=1234 ! queue ! tsdemux ! h264parse ! avdec_h264 ! videorate ! video/x-raw,framerate=10/1 ! videoconvert ! autovideosink sync=false


  


  Problem is that with 10 FPS I get around 2s of latency ! While 56 or 120 FPS results in below 300ms latency.

  


  Is the problem in sender or reader side ? Or both ?

  


  I am not planning to use the 10 FPS, its only for demonstration of problem. But I would like to get lower latency at 56 FPS - just like at 120 FPS (around 80-100 ms difference) or maybe even better, as it seems to get lower with higher FPS.

  


  Maybe there is some kind of buffering parameter which holds frames ?

  


  (of course, when testing with higher FPS I change both numbers in sender and the one in reader command. The camera is v3 RPI official)

  


  Also I'd like to mention that same thing happens with ffplay :

  


  ffplay -i -probesize 3000 tcp://0.0.0.0:1234/?listen