Advanced search

On other websites (11990)

• How can I convince ffserver to save a locally-sourced webcam stream to a file in high resolution AND stream it in lower resolution?

  2 November 2015, by Dominic Jacobssen

  We have a remote Linux machine, accessible over VPN, which has a USB webcam. We want to use this for video conferencing, but we also want to store the stream for archiving.

  Since the streaming bandwidth is limited, it makes sense to capture the stream on the same machine as the webcam and rsync that across after-the-fact, rather than trying to capture the streamed content, which is necessarily going to be poor quality.

  We’re trying to use ffmpeg and ffserver to achieve this, but with little success. Most of the articles on the internet either deal with just streaming a webcam, or rebroadcasting a remote stream. We found we had to recompile ffserver because of a missing "my_addr->sin_family = AF_INET;" in the version of ffserver.c we had been using, since fixed in git.

  Here’s the ffserver.conf we’re trying to use:

  Port 43688
  
  BindAddress 127.0.0.1
  
  MaxHTTPConnections 2000
  
  MaxClients 1000
  
  MaxBandwidth 1000
  
  CustomLog -
  
  NoDaemon
  
  <feed>
  
  ReadOnlyFile /tmp/feed.ffm
  
  FileMaxSize 20M
  
  ACL allow 127.0.0.1
  
  </feed>
  
  <stream>
  
  Feed feed.ffm
  
  Format mp4
  
  VideoSize qvga
  
  VideoGopSize 12
  
  VideoHighQuality
  
  Video4MotionVector
  
  VideoCodec libx264
  
  VideoBitRate 100
  
  VideoBufferSize 40
  
  VideoFrameRate 5
  
  VideoQMin 3
  
  VideoQMax 31
  
  AudioCodec libfaac
  
  AudioBitRate 32
  
  AudioChannels 2
  
  AudioSampleRate 22050
  
  ACL allow localhost
  
  </stream>

  When we fire this up, we get the error:

  Unable to create feed file '/tmp/feed.ffm' as it is marked readonly

  Fair enough, but this is not what is implied in the docs. Changing the directive to:

  File /tmp/feed.ffm

  allows ffserver to fire up and appear to sit and wait for ffmpeg to connect to it. However, when we fire up ffmpeg with the command:

  ffmpeg -f alsa -i pulse -r 16000 -f video4linux2 -s qvga -i /dev/video0 -r 5 -f mp4 -vcodec libx264 -sameq -acodec libfaac -ab 32k http://127.0.0.1:43688/feed.ffm

  then the webcam lights up and ffserver acknowledges the connection with the messages:

  New connection: POST /feed.ffm
  
  [POST] "/feed.ffm HTTP/1.1" 200 0

  but after a few seconds we get the errors:

  [mp4 @ 0x264b160] muxer does not support non seekable output
  
  Could not write header for output file #0 (incorrect codec parameters ?)

  We’ve tried various other formats (mpeg, mpegts, avi) and codecs (mpeg1video, mpeg2video, mpeg4), all without success.

  Moreover, we were under the impression that ffserver could reencode input format to a lower resolution for streaming, but if the stream resolution doesn’t match the feed resolution, we get an error about the resolutions not matching.

  Has anyone ever managed to get this working correctly? I’ve read about vlc being able to do something like this, but the vlc command lines are well nigh impenetrable.

  Thanks!

  Dominic

• Evolution #3967 (Fermé): Suivre les redirections http/https/proxy

  27 June 2017, by goldstein goldstein

  De Willy Destrez (via spip-zone)

  pour faire suite à la discussion sur le forum http://forum.spip.net/fr_267345.html, je lance ce nouveau fil de discussion.

  Comme je le disais, le RSSI a effectué des tests et sa conclusion est la suivante :

  Alors pour faire court, le spip_loader construit ses connexions réseaux "à la main" (sans être péjoratif du tout) au travers d’appels de fsockopen.

  Le type de flux désiré (UDP, TCP, SSL/TLS) se fait au moment de l’ouverture de la socket réseau.
  fsockopen("www.ac-amiens.fr", 80, ... ) pour http
  fsockopen("udp://dns.ac-amiens.fr", 53, ... ) pour DNS
  fsockopen("ssl://www.ac-amiens.fr", 443, ... ) pour https
  fsockopen("tls://smtp.ac-amiens.fr", 465, ... ) pour du smtps
  etc...

  Dans le cas d’un proxy, la connexion ne se fait pas vers le serveur de destination mais on ouvre une socket simple (tcp) vers le serveur proxy et ensuite, on effectue des demandes de connexions au "vrai" serveur au travers de cette socket.

  Là où ça se complique trop, c’est dans dans connexions "mixtes" : bascule http vers https lors d’une redirection (type 301 redirect) car le mode connexion pour un flux chiffré (TLS ou SSL) réclame de nombreuses opération supplémentaires (helo, handshake, vérification des certificats sources et destinations etc...) et toutes ces opérations ne sont pas implémentées dans les fonctions utilisées par spip_loader (et peut être spip aussi...).
  Bref, c’est une implémentation complète d’un client http qu’il faudrait intégrer.

  Ce qui était parfaitement suffisant dans le cas d’une connexion "en clair" se révèle maintenant inopérant.
  A moins de vouloir réinventer la roue, il semblerait bien plus efficace d’abandonner le mode "à la main" pour privilégier un client http plus complet (via la libcurl par exemple, exhaustive de ce point de vue).
  C’est, à ne pas douter, ce que les devs de spip vont prochaine devoir implémenter.

  En mode transitoire, la solution serait de ne pas faire de renvoi http=>https tant que les mises à jours ne sont pas disponibles, ou, à défaut, créer un miroir local des dépôts SPIP accessible en http.

  La dessus, il à modifier le spip_loader (fichier joint) pour prendre en charge les serveurs hébergés derrière un proxy.

  Cela permet de suivre un redirect (301) de http vers https qui n’est pas implémenter dans la version actuelle.

  Le script ne change rien à ceux qui n’ont pas php5-curl (ou php-curl en php7) ou qui n’ont pas de proxy de défini.

  Il continue ses investigations afin de permettre à nouveau le fonctionnement de la mise à jour des dépôts non fonctionnelle également (tout comme "mise à jour auto" de Couteau Suisse)
  Cordialement

• How to re-encode a 120fps (or higher) MP4 from my Samsung Galaxy to a 30fps (example) so it plays on Windows like it does on the Samsung

  21 September 2022, by remark70

  I have some high fps slow-motion videos (mp4) that I've recorded on my phone, but when I copy them to windows and play them back, they play at the normal speed (or they play really fast), unless I slow down playback but this isn't a good result.

  


  What I'd like to do is re-encode (if that's the right word) the video to a standard fps (such as 30) to get a longer video (keeping all the frames), i.e. a 10 second 120fps would end up being a 40 second video at 30fps.