Recherche avancée

Sur d’autres sites (4390)

• Anomalie #3461 (Nouveau) : bug sur les urls à cause d’une mauvaise global $profondeur_url

  4 juin 2015, par Maïeul Rouquette

  Le symptome¶

  de temps en temps (mais assez fréquemment dans mon cas) lorsqu’on a un site dans un sous repertoire, les urls produite par #URL_ARTICLE et co contiennent des "../". Conséquent, lorsqu’on clique on remonte d’un niveau, et du coup on tombe sur une page 404.

  La cause¶

  Visiblement d’après https://core.spip.net/projects/spip/repository/revisions/20729 la cause serait une mauvaise globale $profondeur_url.
  Je cite ESJ

  Enfin compris pourquoi SPIP compile parfois des squelettes où la globale profondeur_url est incorrecte. Lorsqu’on place dans ecrire/.htaccess une redirection comme "ErrorDocument 403 / ?page=403", curieusement Apache met dans $_SERVER[’REQUEST_URI’] l’URL initiale (donc avec .../ecrire/...) tandis qu’il met dans $_SERVER[’SCRIPT_NAME’] l’URL de redirection (dans l’exemple ci-dessus une page à la racine). Du coup, la compilation de cette page à la racine se fait avec une profondeur d’URL qui est celle de ecrire/ et non de la racine. Pour peu que cette page et ses inclusions soient mises en cache, c’est toutes les autres pages qui les partagent qui se retouvent avec de mauvaises URL.

  Les tentatives de résolution¶

  Deux commits en 2.1 ont tenté de résoudre les pb :
  https://core.spip.net/projects/spip/repository/revisions/20729
  et https://core.spip.net/projects/spip/repository/revisions/20762

  Ils ont été reporté en 3.0 par
  - https://core.spip.net/projects/spip/repository/revisions/20744
  - https://core.spip.net/projects/spip/repository/revisions/20745
  puis annulé car visiblement non pleinement fonctionnels en

  - https://core.spip.net/projects/spip/repository/revisions/20746
  - https://core.spip.net/projects/spip/repository/revisions/20747

  à ma connaissance c’est le point mort depuis

• FFMPEG : Can't get audio stream from RTSP Camera IP : V380 Pro

  4 janvier 2023, par Martin

  This is the case :

  



  https://www.banggood.com/10LED-5X-Zoom-HD-2MP-IP-Security-Camera-WiFi-Wireless-1080P-Outdoor-PTZ-Waterproof-Night-Vision-ONVIF-p-1527199.html?rmmds=category&ID=47184&cur_warehouse=CN

  



  It's called V380 Pro probably on shenzen build.

  



  Here you can find some SDK if that help in anything : https://github.com/brusdev/V380-SDK

  



  I'm using this command to record it via ffmpeg :

  



  ffmpeg -use_wallclock_as_timestamps 1 -rtsp_transport tcp -i rtsp://192.168.1.25:554/live/ch00_1 -c copy -acodec copy -map 0 -strict experimental -strftime 1 -flags +global_header -f segment -segment_time 60 -segment_format_options movflags=+faststart -reset_timestamps 1 output_%Y-%m-%d_%H-%M-%S.mp4


  



  Everything works fine except that the audio doesnt recording but of course this camera has an audio output (as the input with microphone)

  



  Tried ffprobe to recognize audio stream but there is none. Looks like ffmpeg doesnt see it or it's somehow combined with video output ?

  



  And here is ffprobe from this same camera but recorded via their windows app :

  



  https://i.stack.imgur.com/xaPUN.png

  



  As you can see now there is some audio output stream.

  


• ffmpeg can not use Android LTE ?

  26 février 2018, par 심상원

  I am using ffmpeg version 3.3.6 to develop an app that displays images of IP cameras on Android.

  The code to process receiving the video is completed. The development environment to date is in the same wifi environment as the camera.

  However, if you attempt to connect to the camera with the same code in the LTE environment, the av_read_frame will terminate with an immediate exit requested error message.

  What is the reason for LTE error ?