Recherche avancée

Sur d’autres sites (11107)

• What is the future of Piwik ?

  16 avril 2014, par Matthieu Aubry — About, Community

  In this post we will explain the key values that drive the Piwik project, and expand upon our goals and roadmap for both the short and long term future.

  What are Piwik’s goals ?

  Piwik will :

  • Enable you to make Data driven decisions
  • Let you focus on what matters most to you
  • Gather in one place all your important metrics (Key Performance Indicators)
  • Be the best open alternative to Google Universal Analytics
  • Support Developers and provide opportunities for them to innovate on Piwik platform

  The Piwik Roadmap

  To achieve our goals, the Piwik team along with Piwik PRO have prepared the Piwik Roadmap.

  We have created this Roadmap based on hundreds of emails sent by users, tickets, along with thousands of forums posts. Feel free to send us feedback about this roadmap.

  What are Piwik values ?

  Our strong values govern all that we do :

  • Open Platform
  • Privacy
  • Reliability
  • Security
  • Usability
  • No data limit
  • Freedom
  • Engineered to last

  Summary

  It is our mission to provide an open and innovative alternative for people who prefer not to use (or cannot use) Google Analytics to analyse and measure their users.

  It is a fun and epic mission which we are proud to be a part of.

  Thank you for trusting us and the project, and keep in touch,

  Matthieu
  Piwik founder

• aacenc_is : add a flag to use pure coefficients instead

  5 septembre 2015, par Rostislav Pehlivanov

  aacenc_is : add a flag to use pure coefficients instead
  This commit adds a flag to use the pure coefficients instead
  
  of the processed ones (sce->coeffs). This is needed because
  
  IS will apply the changes to the coefficients immediately
  
  before the adjust_common_prediction function and it doesn’t
  
  make sense to measure stereo channel coefficient difference
  
  when one of the channels coefficients are all zero.
  Therefore add a flag to use pure coefficients in that case.
  
  TNS is the only thing touching the coefficients before IS
  
  so common window prediction will not take that into account
  
  but the effect of the TNS filter per coefficient can be small
  
  (a few percent) so to some approximation it’s fine to just
  
  ignore that.
  Also fixed a small error which doesn’t alter the results
  
  that much. pow(sqrt(number), 3.0/4.0) == pow(number, 3.0/8.0) !=
  
  pow(number, 3.0/4.0).
  Signed-off-by : Rostislav Pehlivanov <atomnuker@gmail.com>
  

  • [DH] libavcodec/aacenc_is.c
  • [DH] libavcodec/aacenc_is.h
  • [DH] libavcodec/aacenc_pred.c

• FPS from RTSP stream info does not match actual framerate

  17 mai 2021, par Krapow

  I have a 25FPS RTSP stream coming from an IP-camera. I can successfully display the video stream. But when analyzing the stream with ffmpeg (ffprobe actually), I observe fewer frames per second rate :

  


  $ ffprobe -rtsp_transport tcp -i rtsp://camera_ip:554/stream -select_streams v:0 -show_frames -show_entries frame=coded_picture_number,pkt_pts_time -of csv=p=0
Stream #0:0: Video: h264 (Main), yuvj420p(pc, bt709, progressive), 640x480, 25 fps, 25 tbr, 90k tbn, 50 tbc
0.400000,0
0.080000,1
0.120000,2
0.200000,3
0.240000,4
0.320000,5
0.360000,6
0.440000,7
0.480000,8
0.560000,9
0.600000,10
0.680000,11
0.720000,12
0.800000,13
0.840000,14
0.920000,15
0.960000,16
1.040000,17
1.080000,18
1.160000,19
1.200000,20
1.280000,21
1.320000,22
1.400000,23
1.440000,24
1.520000,25
1.560000,26
1.640000,27
1.680000,28
1.760000,29
1.800000,30
1.880000,31
1.920000,32
2.000000,33


  


  We can clearly see the 80ms gap between some of the frames, resulting in a 16fps stream.

  


  I have observed the same framerate issue with GStreamer (printing information in the rtpjitterbuffer indicates the frame gap is sometimes 80ms and sometimes 40ms). But the weird thing is, I encountered the same issue with an HDMI-RJ45 decoder, and I doubt the same issue comes from 2 different devices.
I didn't get much more informations using -loglevel debug or trace.
Does anybody have an idea about what is going wrong in the stream ?

  


  (I used ffprobe 4.2.3 and the last "2021-05-09-git-8649f5dca6-full_build-www.gyan.dev" with the same results, and GStreamer 1.16.2 with a pipeline like "urisourcebin ! h264depay ! h264parse ! fakesink")

  


  EDIT : The camera skipping of frames was caused by the activation of a third stream in the options. I find it really weird that it skips exactly the same frames every seconds. However, I still haven't found the cause of the downrate on my RTSP encoder.
Anyway, this was actually hardware related and not software related.