Recherche avancée

Sur d’autres sites (10424)

• FFMPEG re-broadcast/proxy MJPEG stream

  10 septembre 2022, par Ollie Pugh

  I have an MJPEG stream coming from an RPI on my home network and have an NGINX acting as a proxy on an EC2.

  


  For the camera access the flow of stream to the user is the following

  


  RPi -> mjpeg-proxy (running on EC2) -> NGINX (running on same EC2) -> user

  


  the point of mjpeg-proxy is to reduce the load on the RPi and only have one stream to the Pi and allow the EC2 to distribute that one stream.

  


  Now this work fine-ish from my PC (on same network as Pi) the streams work perfectly. But when it comes to my phone on roaming data, the stream is super choppy and the latency grows massively (this project needs minimal latency, like sub 300ms).

  


  I can't understand why this would happen ? Because even when running of my local PC its going through the Proxy hosted in the cloud, so its not as if its an advantage to it being local ?

  


  the stream is fine on another device, e.g. my laptop, but thats on the same network as the RPi. But like I said, it shouldn't makea difference as its going through a proxy !

  


  I was wondering if using FFMPEG to re-stream the mjpeg stream would be beneficial as node is notoriously slow. But I don't really want to be writing my own mjpeg-proxy in C++ to speed this all up.

  


  I have looked online for answers to FFMPEG MJPEG proxy and have been very unsuccesful

  


• avcodec/dvdsubdec : fix accessing dangling pointers

  8 janvier 2015, par wm4

  avcodec/dvdsubdec : fix accessing dangling pointers
  dvdsub_decode() can call append_to_cached_buf() 2 times, the second time
  
  with ctx->buf as argument. If the second append_to_cached_buf() reallocs
  
  ctx->buf, the argument will be a pointer to the previous, freed block.
  
  This can cause invalid reads at least with some fuzzed files - and
  
  possibly with valid files.
  Since packets can apparently not be larger than 64K (even if packets are
  
  combined), just use a fixed size buffer. It will be allocated as part of
  
  the DVDSubContext, and although some memory is "wasted", it’s relatively
  
  minimal by modern standards and should be acceptable.
  Signed-off-by : Michael Niedermayer <michaelni@gmx.at>
  

  • [DH] libavcodec/dvdsubdec.c

• Best approach to stream RTSP IP Cam feed to React app and node.js express server

  17 juillet 2024, par JuicyPhan

  I am trying to build a set-up whereby I stream multiple IP Cam RTSP Video feeds to multiple users.
It needs to have minimal latency.

  


  Server Hardware : Static IP Synology NAS
  
Front-End : React
  
Back-End : Node.js Express
  
STUN/TURN server : Coturn
  
Video Feed : Multiple IP Camera's RTSP feeds
  
Video Encoder : ffmpeg(?)
  
Video Decoder : ?
  
Video Format : ?
  
Streaming Protocol : WebRTC

  


  I have every individual component up however am struggling with the part whereby I encode the RTSP feed.

  


  What video format do I encode it to and how do I use WebRTC to stream to viewers on the front-end ?