Recherche avancée

Sur d’autres sites (5366)

• Matomo’s new story : our stronger vision for the future

  31 octobre 2018, par Matthieu Aubry — Community

  

  Over the past year, the team here at Matomo have been working on a very exciting project we’d love to share with you.

  It’s to do with the impact we hope for Matomo to have.

  As you all know, the world changes at too fast a pace. New technologies, new phones, new everything in the blink of an eye. That’s not what will be happening here.

  Instead, we’d like to believe it’s a refresh. Taking stock of how far we’ve come, what we’ve achieved so far, and how far we still have to go.

  So we’re rebranding.

  The rebrand

  Like a caterpillar emerging from a cocoon, we hope to be a reborn analytics butterfly.

  As a result of some careful planning and reflection we’ll be updating our logo, website and reasserting our voice.

  It’s our chance to look at ourselves in a new light. We are a mighty analytics platform and it should be known we’re comparable to the likes of Google Analytics 360.

  Along with the refresh of imagery, we listened to your feedback about the confusion between our two identities, so we’re also taking this opportunity to unite both the business brand of Innocraft with the community brand Matomo into one website.

  It makes it easier for people from all walks of life, either as individuals or in large companies, to see us as being able to get down to business with a powerful analytics tool, as well as think on behalf of our community.

  We’re the same, but with slight changes in our appearance and a stronger vision for the future.

  How far we’ve come …

  When we started out, it was about building a community around a movement. From the beginning we were concerned about data ownership, privacy and all things that came with that.

  With the help of our community and contributors, we turned Matomo (formerly Piwik) into the trusted #1 open source analytics tool it is today. We’re committed to our community. But we also need to do more.

  We’ve been niche and happy staying small, but now we need to take action and start shouting far and wide about what we do.

  We once said we need : “To create, as a community, the leading international open source digital analytics platform, that gives every user full control of their data.”

  We believe we’ve done that, so we’ll take it one step further.

  A web analytics revolution has begun …

  Begun ?

  The line signifies a new beginning.

  This is us standing up and reasserting our voice.

  Our new chapter.

  The rebrand is our chance to show that, yes, the world is changing, but when it comes to privacy, there are matters meant to be sacred. Privacy is a human right.

  What makes it worse in this ever-changing landscape, with data breaches and stolen information, is that losing control of our data is scary, we have a right to know what’s going on with our information and this must start with us.

  We know we need to champion this cause for privacy and data ownership.

  We came together as a community and built something powerful, a free open-source analytics platform, that kept the integrity of the people using it.

  It’s important for us now to feel more empowered to believe in our right to privacy, information and our ability to act independently of large corporations.

  The time is here for us to speak up and take back control.

  Once more, we need to come together to build something even more powerful, a safer online society.

  Join us.

  Sincerely,
  Matthieu Aubry on behalf of the Matomo team

• avcodec/mpegaudiodec_template : Check CRCs for layer1 and layer2

  3 août 2020, par Michael Niedermayer

  avcodec/mpegaudiodec_template : Check CRCs for layer1 and layer2
  This differs from the MPEG specification as the actual real world
  
  files do compute their CRC over variable areas and not the fixed
  
  ones listed in the specification. This is also the reason for
  
  the complexity of this code and the need to perform the CRC
  
  check for layer2 in the middle of layer2 decoding.
  Reviewed-by : Lynne <dev@lynne.ee>
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavcodec/mpegaudiodec_template.c

• avcodec/vdpau : Support for VDPAU accelerated HEVC decoding

  13 juin 2015, par Philip Langdale

  avcodec/vdpau : Support for VDPAU accelerated HEVC decoding
  This change introduces basic support for HEVC decoding through vdpau.
  
  Right now, there are problems with the nvidia driver/library implementation
  
  that mean that frames are incorrectly laid out in memory when they are
  
  returned from the decoder, and it is normally impossible to recover the
  
  complete decoded frame due to loss of data from alignment inconsistencies.
  I obviously hope that nvidia will be fixing it in due course - I’ve verified
  
  the problems exist with their example application.
  As such, this support is not useful for any real world application, but I
  
  believe that it is correct (with the caveat that the mangled frames may hide
  
  problems) and will work properly once the nvidia problem is fixed.
  Right now it appears that any file encoded by x265 or nvenc is decoded
  
  correctly, but that’s because these files don’t use a bunch of HEVC
  
  features.
  Quick summary :
  Features that seem to work :
  1) Short Term References
  
  2) Scaling Lists
  
  3) Tiling
  Features with known problems :
  1) Long Term References
  It’s hard to tell what’s going on here. After I read the nvidia example
  
  app that does not set the IsLongTerm flag on LTRs, and changed my code,
  
  a bunch of frames using LTR started to display correctly, but there
  
  are still samples with glitches that are related to LTRs.
  In terms of real world files, both x265 and nvenc only use short term
  
  refs from this list. The divx encoder seems similar.
  Signed-off-by : Philip Langdale <philipl@overt.org>
  

  • [DH] configure
  • [DH] libavcodec/Makefile
  • [DH] libavcodec/allcodecs.c
  • [DH] libavcodec/hevc.c
  • [DH] libavcodec/vdpau_hevc.c
  • [DH] libavcodec/vdpau_internal.h