Recherche avancée

Sur d’autres sites (9474)

• Piwik Analytics becomes Matomo to reflect Users’ Privacy Focus

  10 janvier 2018, par Matomo Core Team

  One of the world’s leading analytics software platforms is changing its name. Piwik is the sixth most-used web and mobile analytics computer solution worldwide. It is now changing its name to Matomo.

  The name change comes after 10 years of Piwik building its top analytics software, with great success. It is already used on over one million websites in more than 170 countries. Matomo will build on that success, and focus even more on privacy.

  ‘Privacy has become a huge concern worldwide’, says Matomo’s creator, Matthieu Aubry. ‘Privacy legislation is being developed in Europe, and we will be ahead of the game in being ready for those changes. We’ll grow in line with the law and regulation changes.’

  Matomo will lead the way in openness and transparency for its users. Its new name means honesty in Japanese.
  ‘Matomo will always be free and community-driven, just as Piwik was’, says Matthieu Aubry. ‘We have worked with hundreds of people to create the best open digital analytics solution in the world. We’re committed to giving every user full control of their data.’

  The change of name is appropriate as the Matomo platform moves into a new stage of growth. But for its community, little will obviously change. The same people will still be involved, and users will still get useful data to improve their own website. That data includes who visits their site, what they do there, how long they stay, and what they buy.
  Matomo is an all-in-one analytics solution that gives companies a 360 degree view of their users.

  ‘They can grow their business while still keeping 100% ownership of their data, and being fully compliant with privacy laws’, says Matthieu Aubry. ‘We’re more motivated than ever to building on that, so that Matomo stays ahead of the pack.’

  The platform can be fully customised with hundreds of plug-ins, integrations and configurations.

  Matomo’s updated website and new logo is now available on https://matomo.org.
  For further information, please contact the Matomo Team on hello@matomo.org

  The post Piwik Analytics becomes Matomo to reflect Users’ Privacy Focus appeared first on Analytics Platform - Matomo.

• aacenc : use the fast coder as the default

  13 janvier 2018, par Rostislav Pehlivanov

  aacenc : use the fast coder as the default
  The twoloop coder sounds decent at low bitrates, however at higher bitrates
  
  it sounds worse than the fast coder (which used to be the old twoloop coder
  
  before October 2015) and needs quite a lot more CPU.
  
  Change the default to fast. It has been well tested and has had little changes
  
  over the years so its been confirmed to be quite stable.
  
  Also change its description (not valid for more than a year) and the
  
  documentation.
  Signed-off-by : Rostislav Pehlivanov <atomnuker@gmail.com>
  

  • [DH] doc/encoders.texi
  • [DH] libavcodec/aacenc.c
  • [DH] tests/fate/aac.mak

• avcodec_encode_video2 crash on MinGW32 (but not on MinGW64)

  27 février 2018, par ksb496

  I have been testing for years a software that I am developing, compiled only for 64-bit systems through Qt-MinGW64, without experiencing any kind of issue regarding video encoding (which is one of the features of such application). Recently, I have been attempting to build the corresponding x86 version of my software by compiling it with Qt-MingGW32.

  However, after bulding the same ffmpeg and x264 library versions to create the 32-bit versions and successfully linking them to my project, the application keeps crashing after few frames are encoded, due to segmentation fault error. This is very strange because, as I indicated before, it works flawlessly when compiled for 64-bit systems.

  I have also lost a considerable amount hours trying to combine a big amount of different versions of both ffmpeg and x264 libraries, but with no luck either. Neither it works when disabling threads both for x264 and ffmpeg libraries, hence it does not seem to be a win32 threading issue. Therefore, I have concluded that the error is most likely in my code, which by some chance beyond my comprehension tells ffmpeg to allocate the right amount of memory in the x64 version, but not in the x86 version.

  It must be pointed out also that before the avcodec_encode_video2 call, I do the following calls, among others, in order to allocate the memory associated to the corresponding items (AVFrame, AVCodec, etc.), such as

  avcodec_open2( my_codec_context, my_codec, &opt );
  
  my_av_frame=av_frame_alloc();

  More precisely, the details involving the code structure that I am using can be found here.

  Therefore, the error appears to be more subtle than just issues regarding uninitialized memory.

  Many thanks in advance.

  UPDATE :

  I have discovered the focus of the problem. For some reason, FFmpeg/x264 libraries behave abnormally in Win32 GUI applications compiled with Qt-MinGW32, while they run correctly in Win32 console applications, also compiled with Qt-WinGW32. I have proven this claim performing two dummy tests, in which the exact same piece of code is run through a console application and on a GUI application, succeeding in the first case and failing in the latter one. The code for such tests can be found below, along with the x264 and FFmpeg libraries used in my projects, together with instructions to build them in msys2 with MinGW32 :

  https://takeafile.com/?f=hisusinivi

  I have no idea whether it can be solved by simply tweaking the code or it is a serious bug involving an incompatibility issue. If it is the latter, should it be reported to the Qt/FFmpeg/x264 staff as a major bug ?