Recherche avancée

Sur d’autres sites (13865)

• Different ways of embedding the Piwik tracking code for faster website performance

  18 avril 2017, par InnoCraft — Community, Development

  Many studies have shown that performance matters a lot. For each 100ms a websites takes longer to load, a business may lose about 0.1% to 1% in revenue. It also matters because Google judges page speed as a ranking factor for search results page. At InnoCraft, we help our clients optimizing their Piwik integration and recommend different ways of embedding the tracking code tailored to their needs. The best way to embed the tracking code depends on your website, what you want to achieve, and how important tracking is to you.

  This technical blog post mainly focuses on improving the time to load your website. This is an important metric as for example Google usually measures the time it took to load a page. Many businesses therefore want to get to the page load event as quickly as possible.

  The regular way of embedding the tracking code

  By default, Piwik is embedded in the header or footer of your website. This is a sensible default. While it is loaded asynchronously and deferred, it still does delay the onload event. Depending on the performance of your Piwik, how fast your website loads, how your website’s resources are embedded, and other factors you may want to consider alternatives. Three of them I will introduce below.

  Embedding the tracker after the load event

  To ensure that your website will always load even if the Piwik server is un-available, you may want to load the tracking code only after the website is loaded like this :

  var _paq = _paq || [];
  
  _paq.push(["trackPageView"]);
  
  _paq.push(["enableLinkTracking"]);
  
  
  
  function embedTrackingCode() {
  
     var u="https://your.piwik.domain/";
  
     _paq.push(["setTrackerUrl", u+"piwik.php"]);
  
     _paq.push(["setSiteId", "1"]);
  
  
  
     var d=document, g=d.createElement("script"), s=d.getElementsByTagName("script")[0]; g.type="text/javascript";
  
     g.defer=true; g.async=true; g.src=u+"piwik.js"; s.parentNode.insertBefore(g,s);    
  
  }
  
  
  
  if (window.addEventListener) { 
  
      window.addEventListener("load", embedTrackingCode, false); 
  
  } else if (window.attachEvent) { 
  
      window.attachEvent("onload",embedTrackingCode); 
  
  } else {
  
      embedTrackingCode();
  
  }

  The downside is you won’t track all of your visitors because some will have already left your website by the time your website is fully loaded. Especially when you have a JavaScript-heavy website or when your website takes longer to load in general. To detect the load event correctly cross browser, you may want to use a library like jQuery.

  Delaying the tracking

  Another technique is to load the tracking with a little delay at the end of your website like this :

  setTimeout(function () {
  
      embedTrackingCode();
  
  }, 5);

  This time the tracking script will still track most of your visitors but does not slow down loading the rest of your website as much as it would do by default (at least perceived). In some cases, you will notice a performance improvement when looking at the “time to load” but it depends on your website.

  Not loading the JavaScript Tracker at all

  With Piwik you also have the option to not embed the tracking code into your websites at all and instead generate reports from the webserver logs using Piwik Log Analytics. This works very well but some data might not be available like the device resolution which can be only captured using JavaScript. On the bright side this solution also captures users with ad blockers or tracking blockers.

  Questions ?

  We invite you to test different ways to see what makes sense for you and how it affects your website performance as well as the perceived performance. If you have any questions, feel free to get in touch with us.

  Read on

  The last post in this series is Performance optimizations you can apply today to load the Piwik JavaScript tracker faster.

• How does one correctly avoid the avcodec_alloc_context3 leak from avformat_new_stream ?

  14 avril 2017, par Tom Seddon

  This maddening thread describes the problem I’m having : a memory leak on shutdown due to some stuff allocated when avformat_new_stream is called.

  Here’s the valgrind stack trace from the leak :

  • 1,447 (1,440 direct, 7 indirect) bytes in 1 blocks are definitely lost in loss record 2 of 4
  • at 0x4C2FFC6 : memalign (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
  • by 0x4C300D1 : posix_memalign (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
  • by 0x690DEFF : av_malloc (mem.c:87)
  • by 0x690E09D : av_mallocz (mem.c:224)
  • by 0x533D28A : init_context_defaults (options.c:128)
  • by 0x533D325 : avcodec_alloc_context3 (options.c:164)
  • by 0x663D09E : avformat_new_stream (utils.c:4384)
  • by 0x4204B6 : main (test_ffmpeg.cpp:918)

  So clearly the problem is that when a AVFormatContext’s stream’s codec context’s priv_data field is somehow not being freed.

  My code frees the AVFormatContext with avformat_free_context. This calls ff_free_stream, which calls free_stream, which frees a few of the stream’s codec context fields itself - but not the priv_data field !

  Compared and contrast with the corresponding code in avcodec_close.

  The suggested solution to the problem from the thread : "close the codec firstly before calling av_format_free_context". Presumably this refers to calling avcodec_free_context ? - but I’m already doing this ! Roughly following the structure in the muxing example, I have an encoder context created by my code, that’s used to track the uncompressed input data. Then there’s another encoder context created internally by avformat_new_stream (as above), which is used internally by FFmpeg. I close the former, because it was opened using avcodec_open2, but I don’t close the latter, because it wasn’t. I am following the maddening thread’s advice, and yet here I am.

  Furthermore, reading between the lines, using avcodec_free_context to free the AVStream’s codec context is no good anyway, because when doing this (a) AVStream’s codec field is deprecated, so this gives a bunch of warnings, and (b) there are no NULL checks in free_stream, so this crashes at runtime.

  What I have done for now is drag in the appropriate bit of code from avcodec_close, and put it in my own code just ahead of the call to avformat_free_context :

  #ifdef __GNUC__
  
  #pragma GCC diagnostic push
  
  #pragma GCC diagnostic ignored "-Wdeprecated-declarations"
  
  #endif
  
      for(unsigned i=0;inb_streams;++i) {
  
          AVStream *st=avf_context->streams[i];
  
  
  
          if(st->codec->priv_data&&
  
             st->codec->codec&&
  
             st->codec->codec->priv_class)
  
          {
  
              av_opt_free(st->codec->priv_data);
  
          }
  
  
  
          av_freep(&st->codec->priv_data);
  
      }
  
  #ifdef __GNUC__
  
  #pragma GCC diagnostic pop
  
  #endif

  So that fixes the leak, and it’s clearly (to my eyes) a bug, and I need to file a bug report or something.

  However the corresponding bug report is marked as fixed and closed... along with a link back to the maddening thread, and no further explanation. (This is why it is maddening !) So maybe I’m just using FFmpeg wrongly ?

  Can anybody confirm whether this is actually a bug in FFmpeg or not ?

  If it isn’t a bug, what’s the right sequence of calls to make ?

  (I’m using FFmpeg built locally from commit 03eb0515c12637dbd20c2e3ca8503d7b47cf583a. I had similar-looking problems with the one you get from the Ubuntu 16 package manager, which prompted me to build it myself with symbols and so on.)

• Process is being paused until I close the program

  27 mai 2017, par user924

  I made a simple program and UI for it.
  It has one button for starting ffmpeg.exe to decode a video :

      button.addActionListener(new ActionListener() {
  
          @Override
  
          public void actionPerformed(ActionEvent e) {
  
              ProcessBuilder pb = new ProcessBuilder("D:\\ffmpeg.exe", "-i", "\"D:\\video\\input.mp4\"", "\"output.mp4\"");
  
              try {
  
                  Process p = pb.start();
  
              } catch (IOException error) {
  
                  //
  
              }
  
          }
  
      }

  The problem is that after clicking the button ffmpeg starts but it doesn’t do anything (in task manager it doesn’t use cpu - 0%) until I close the program (UI) and then ffmpeg process starts to decode a video (only after closing the program ffmpeg starts using cpu - e.g. 24%)

  It’s not duplicate : older questions proposed by Andy Thomas doesn’t have an answer (solution) for my problem