Recherche avancée

Sur d’autres sites (7290)

• Unwrapping Matomo 5.2.0 – Bringing you enhanced security and performance

  25 décembre 2024, par Daniel Crough — Latest Releases

   As we tie a bow on 2024, we’re delighted to share our final gift of the year. Matomo 5.2.0 comes wrapped with new security features, privacy controls, and performance improvements to enhance your analytics experience.

   Enhanced security and privacy controls

  

  We’ve strengthened Matomo’s security framework with several key updates :

  • A new installer timestamp mechanism for on-premise installations creates a secure 72-hour installation window, preventing unauthorised access during setup
  • Enhanced account security features including a “This Wasn’t Me” link in password reset emails and location-based login alerts
  • The new Global List of Query URL parameters feature lets you refine tracking by excluding sensitive or unnecessary parameters from collection

  Tag manager improvements for better efficiency

  

  The Matomo Tag Manager now includes several features to streamline your workflow :

  • New Consent Management Platform (CMP) tags for CookieYes, OneTrust, and Axeptio, simplifying consent tracking implementatio.
  • A new copy feature for containers, tags, and triggers that reduces setup time and ensures consistency across multiple properties
  • Improved management tools for maintaining standardised tracking across websites

  Performance and reliability updates

  We’ve made technical improvements to enhance Matomo’s performance :

  • Full PHP 8.4 compatibility for improved performance and reliability
  • Optimised archiving processes including smarter handling of recent data
  • New recovery options for interrupted archiving processes
  • Specific improvements for TiDB compatibility, enhancing database performance for users of this engine

  Important to note : This release does not require any major database upgrade, making it easier to implement these improvements.

  Looking forward to 2025

  As we prepare to enter a new year, these updates reflect our ongoing commitment to providing privacy-focused analytics. We’re grateful to all our community contributors who have helped make this release possible. Special thanks to the Matomo community for their contributions to this release.

  Ready to explore these new features ? Update to Matomo 5.2.0 today and start the new year with enhanced security, efficiency, and control over your analytics data.

  From all of us at Matomo, thank you for being part of our journey. Here’s to another year of protecting privacy and empowering insights together !

  ---

  For a detailed overview of all changes and improvements, see our complete release notes or join the discussion in our community forums. If you’d like to contribute to making Matomo even better, learn more about getting involved with our open-source project.

• configure : update copyright year

  1er janvier, par Lynne

  configure : update copyright year
  On 01/01/2025 19:05, Peter Ross wrote :
  
  > FFmpeg turns 25 this year.
  

  • [DH] configure

• FFMPEG encoding with Intel Quick Sync, throwing "Access violation reading location "

  22 octobre 2015, par Paul Knopf

  I am using FFMPEG ffmpeg-20150610-git-913685f, from here.

  Using this library, I setup a application that captures UYVY frames from my frame grabber and encodes/muxes them to an MP4 file, using libx264. Works without issues.

  Now, I wanted to try to enabling Intel Quick Sync, so I changed the encoder.

  // old (libx264)
  
  //AVCodec* codec = avcodec_find_encoder(AV_CODEC_ID_H264);
  
  // new (Intel Quick Sync)
  
  AVCodec* codec = avcodec_find_encoder_by_name("h264_qsv");

  It finds the encoder ok. However, at the time of encoding a frame, I get the following exception.

  Unhandled exception at 0x000000005D4DDC9E (avcodec-56.dll) in
  MedXChangeDecLinkTest.exe : 0xC0000005 : Access violation reading
  location 0x0000000000000048.

  The exact API call is :

  avcodec_encode_video2(_internals->videoStream.stream->codec, &pkt, _internals->videoStream.frame, &got_packet);

  Is there more I need to do ? I noticed that there was a commit that added some additional pixel formats for QSV here. Do I have to do something differently, compared to how things were done with libx264 ?

  UPDATE : I also just realized that I am getting an error on the stdout.

  [h264_qsv @ 000000c7e6d8e680] Specified pixel format yuv420p is invalid or not supported