Recherche avancée

Sur d’autres sites (8416)

• lavfi : generalize colorspace coefficent helpers

  9 avril 2022, par Niklas Haas

  lavfi : generalize colorspace coefficent helpers
  These are needed beyond just vf_colorspace, so give them a new home in
  
  colorspace.h.
  In addition to moving code around, also merge the white point and
  
  primary coefficients into a single struct to slightly increase the
  
  convenience and shrink the size of the new API by avoiding the need
  
  to introduce an extra function just to look up the white point as well.
  
  The only place the distinction matters is in a single enum comparison,
  
  which can just as well be a single memcpy - the difference is
  
  negligible.
  Signed-off-by : Niklas Haas <git@haasn.dev>
  

  • [DH] libavfilter/colorspace.c
  • [DH] libavfilter/colorspace.h
  • [DH] libavfilter/vf_colorspace.c

• 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

  


• ffmpeg : transmission problems / artifacts in rtsp screen grab - might be a WiFi problem

  1er décembre 2022, par Jo Kerner

  In short : Is there a way to "force" ffmpeg to not save a grabbed frame if there are transmission problems ? Or any other software that does the same and I just don't know of ?

  


  Long story :

  


  Updating my house surveillance from almost 10 years old DCS-932L cameras to Tapo C100 Cameras, I changed the image delivery method from ftp push to rtsp grab via ffmpeg.

  


  I had written a program in C++ to check for "bad" pictures from the old cameras, where parts of the picture tended to be simply black once every minute or so (I'm grabbing a pic every 2 seconds). The Tapo C100 doesn't feature ftp-push, thus I tried (after a few days trying)

  


  ffmpeg.exe -y -i rtsp://user:pass@10.0.0.%ld:554/stream1 -vframes 1 %scamera\rtsp.jpg -loglevel quiet


  


  This works absolutely perfect in my main house, which features a Fritz !Box 7590 and a set of Fritz !Powerline (510/and two 540e) repeaters, plus one WiFi repeater Fritz 600) as my phone line and the router are in the basement.

  


  In my holiday home, though, it doesn't. The Wifi is managed by a Hybrid DSL/5G - box I have no alternative to, which is a Huawei DN9245W and works as DHCP Server, because this is almost impossible to change. Everything "real" is managed by another Fritz !Box 7590, connected via ethernet, and another set of Fritz !Powerline 510 and two 540e repeaters plus half a dozen Wifi Repeaters, mostly Fritz ! 310, 450E and 600. The house was partially built with local stones, which are very iron-y, and there's a lot of metallized glass. Full set is show in Image

  


  Now, this does produce different artifacts, about two per minute or in every 15th picture, see
Image with artifacts No. 1

  


  Thinking this might be a transmission problem, I tried forcing the streamgrab via TCP, because while rtsp doesn't have error correction, TCP does :

  


  ffmpeg.exe -rtsp_transport tcp -i
rtsp://user:pass@10.0.0.%ld:554/stream1 -y -f image2 -update 1 -r
1 -vframes 1 -qscale:v 30 %scamera\rtsp.jpg -loglevel quiet


  


  Which didn't change the artifacts much, see Image with artifacts No. 2

  


  The house now has a total of 12 Cameras, six of which are each "managed" by an older Dell Optiplex Desktop bought used off ebay with an i3 or i5 processor from about 2015, which goes to about 65% load. My software will check if the grabbed picture is finished saving (to RAMdisk), rename it, check if there are artifacts, if so, drop it, if not, convert to bitmap and then compare it to previous image, guess if there's a change, mark that change with a rhombus and rate it, save that as a jpeg file, and then some other stuff that's not relevant here. See : Image of my program running with six cameras

  


  I did try grabbing keyframes only, but a bunny or deer or burglar hopping through my property doesn't produce a keyframe, so that turned out to be missing the point.

  


  I'm out of ideas here. It does work flawlessly in the main house. It doesn't in the holiday house. I can hardly install more repeaters ; I already tried mesh and not-mesh, and the problem isn't exactly wifi overload, because even with just one camera running, it still persists. In certain places. Some have no problems. Reasons ? No clue. I really hope someone has a good idea.