Recherche avancée

Sur d’autres sites (8018)

• Live Video Encoding and Streaming on a Webpage

  9 mars 2016, par Ockhius

  I am trying to show live webcam video stream on webpage and I have a working draft. However, I am not satisfied with the performance and looking for a better way to do the job.

  I have a webcam connected to Raspberry PI and a web server which is a simple python-Flask server. Webcam images are captured by using OpenCV and formatted as JPEG. Later, those JPEGs are sent to one of the server’s UDP ports. What I did up to this point is something like a homemade MJPEG(motion-jpeg) streaming.

  At the server-side I have a simple python script that continuously reads UDP port and put JPEG image in the HTML5 canvas. That is fast enough to create a perception of a live stream.

  Problems :

  • This compress the video very little. Actually it does not compress the video. It only decreases the size of a frame by formatting as JPEG.

  • FPS is low and also quality of the stream is not that good.

  • It is not a major point for now but UDP is not a secure way to stream video.

  • Server is busy with image picking from UDP. Needs threaded server design.

  Alternatives :

  • I have used FFMPEG before to convert video formats and also stream pre-recorded video. I guess, it is possible to encode(let say H.264) and stream WebCam live video using ffmpeg or avconv. (Encoding)

  Is this applicable on Raspberry PI ?

  • VLC is able to play live videos streamed on network. (Stream)

  Is there any Media Player to embed on HTML/Javascript to handle
  network stream like the VLC does ?

  • I have read about HLS (HTTP Live Stream) and MPEG-DASH.

  Does these apply for this case ? If it does,how should I use them ?

  Is there any other way to show live stream on webpage ?

  • RTSP is a secure protocol.

  What is the best practice for transport layer protocol in video
  streaming ?

• Matomo 2 reaches end of life soon (December 2017), update now !

  7 décembre 2017, par Matomo Core Team — Community

  In less than three weeks, Matomo (Piwik) 2 will be no longer supported. This means that no further (security) updates will be released for this version. As per our Long Term Support announcement, Matomo 2.X is supported for 12 months after the initial release of Matomo 3.0.0 which was on December 18th 2016. Therefore, Matomo 2 will no longer receive any updates after December 18th 2017.

  It has been almost a year since we released Matomo (Piwik) 3 and we highly recommend updating to Matomo 3 ASAP. The major new release came with a new UI, performance and security improvements. If you are still on Matomo 2, the security improvements alone should be worth updating your Matomo to Matomo 3 now. We cannot recommend this enough.

  The update to Matomo (Piwik) 3 should be smooth, but may take a while depending on the amount of data you have.

  • If you have any problem with the update, feel free to get in touch with us, or ask in the forums.
  • If you are currently using Matomo (Piwik) self-hosted and would like to be upgraded, plus your Matomo managed in the official Cloud-hosted service, contact InnoCraft Cloud and they will migrate your database.

  At Matomo (Piwik) and InnoCraft, the company of the makers of Matomo, we have seen many thousands of Matomo installations upgraded over the past year and look forward to an exciting future for Matomo 3 and beyond !

• What's FFmpeg doing with avcodec_send_packet() ?

  4 avril, par Jim

  I'm trying to optimise a piece of software for playing video, which internally uses the FFmpeg libraries for decoding. We've found that on some large (4K, 60fps) video, it sometimes takes longer to decode a frame than that frame should be displayed for ; sadly, because of the problem domain, simply buffering/skipping frames is not an option.

  


  However, it appears that the FFmpeg executable is able to decode the video in question fine, at about 2x speed, so I've been trying to work out what we're doing wrong.

  


  I've written a very stripped-back decoder program for testing ; the source is here (it's about 200 lines). From profiling it, it appears that the one major bottleneck during decoding is the avcodec_send_packet() function, which can take up to 50ms per call. However, measuring the same call in FFmpeg shows strange behaviour :

  


  

  


  (these are the times taken for each call to avcodec_send_packet() in milliseconds, when decoding a 4K 25fps VP9-encoded video.)

  


  Basically, it seems that when FFmpeg uses this function, it only really takes any amount of time to complete every N calls, where N is the number of threads being used for decoding. However, both my test decoder and the actual product use 4 threads for decoding, and this doesn't happen ; when using frame-based threading, the test decoder behaves like FFmpeg using only 1 thread. This would seem to indicate that we're not using multithreading at all, but we've still seen performance improvements by using more threads.

  


  FFmpeg's results average out to being about twice as fast overall as our decoders, so clearly we're doing something wrong. I've been reading through FFmpeg's source to try to find any clues, but it's so far eluded me.

  


  My question is : what's FFmpeg doing here that we're not ? Alternatively, how can we increase the performance of our decoder ?

  


  Any help is greatly appreciated.