Recherche avancée

Sur d’autres sites (15748)

• 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.

• Shortcut to open command prompt with preloaded command

  13 janvier 2019, par Lemons

  I use FFMPEG to convert MP4s to WEBMs. This involves me constantly copying over my preferred script into the command prompt every single time. Is there a way to open a commant prompt with a certain command already set up and ready to go without executing the commmand immediately so that it is still editable ? Many times I need to change parameters of the script to match the specific file I will be converting...so simply having a pre-loaded script that runs by itself doesn’t make sense.

  Tried making a CMD shortcut but couldn’t find a way to do this without automatically running the command. Tried making a batch file, got the script to copy in, but it wasn’t editable.

  Here is the FFMPEG script I use : ffmpeg -i "in.mp4" -b:v 3000k -b:a 128k -threads 6 out.webm

• Recording usb cam on raspberry pi with ffmpeg - usb troubleshooting

  18 septembre 2017, par Hwy2Hell

  I want to save video from an external usb cam on the raspberry pi 3. In order to avoid voltage drop issues, I use the offical raspberry power supply (2.5 Amp) and connected all usb devices by a separetely powered usb hub :

  pi@raspi:~/appdev/ffmpeg $ lsusb
  
  Bus 001 Device 037: ID 046d:09a1 Logitech, Inc. QuickCam Communicate MP/S5500
  
  Bus 001 Device 036: ID 046d:c03f Logitech, Inc. M-BT85 [UltraX Optical Mouse]
  
  Bus 001 Device 035: ID 04d9:1503 Holtek Semiconductor, Inc. Shortboard Lefty
  
  Bus 001 Device 012: ID 1a40:0101 Terminus Technology Inc. 4-Port HUB
  
  Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
  
  Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. 
  
  Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

  When I try to test the functionality by running the following bash script (snippet) :

  function capture
  
  {
  
      capfile=$(date +%F_%Hh%Mm%Ss)
  
      echo saving to $wdir/$capfile.mp4
  
      echo $PATH
  
      ffmpeg -video_size 320x240 -i /dev/video0 \
  
      -vf drawtext="fontsize=18:x=10:y=220:fontcolor=red:\
  
      fontfile=/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf:\
  
      text=%{localtime}" -t 10 $wdir/$capfile.mp4
  
      # change -t to 3600 = 1h
  
  }
  
  
  
  for i in $(seq 1 10)
  
  do
  
      echo
  
      echo Pass $i ...
  
      capture
  
  done

  After a few loop-runs I always see device errors :

  Pass 5 ...
  
  saving to /home/pi/appdev/ffmpeg/2017-09-16_13h31m00s.mp4
  
  /usr/local/bin:/usr/bin/ffmpeg:/usr/bin:/bin:/sbin
  
  ffmpeg version 3.3.3 Copyright (c) 2000-2017 the FFmpeg developers
  
    built with gcc 4.9.2 (Raspbian 4.9.2-10)
  
    configuration: --arch=armhf --target-os=linux --enable-gpl --enable-libfreetype --enable-mmal --enable-nonfree --enable-omx --enable-omx-rpi
  
    libavutil      55. 58.100 / 55. 58.100
  
    libavcodec     57. 89.100 / 57. 89.100
  
    libavformat    57. 71.100 / 57. 71.100
  
    libavdevice    57.  6.100 / 57.  6.100
  
    libavfilter     6. 82.100 /  6. 82.100
  
    libswscale      4.  6.100 /  4.  6.100
  
    libswresample   2.  7.100 /  2.  7.100
  
    libpostproc    54.  5.100 / 54.  5.100
  
  /dev/video0: Input/output error

  The kernel message log shows that the usb cam has been resetted :

  pi@raspi:~/appdev/ffmpeg $ dmesg | grep usb
  
  [ 4497.358195] usb 1-1.2.4: new high-speed USB device number 37 using dwc_otg
  
  [ 4497.573440] usb 1-1.2.4: New USB device found, idVendor=046d, idProduct=09a1
  
  [ 4497.573466] usb 1-1.2.4: New USB device strings: Mfr=0, Product=0, SerialNumber=2
  
  [ 4497.573481] usb 1-1.2.4: SerialNumber: A032D310
  
  [ 4497.605698] input: UVC Camera (046d:09a1) as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2.4/1-1.2.4:1.0/input/input15
  
  [ 4497.625582] usb 1-1.2.4: Warning! Unlikely big volume range (=3072), cval->res is probably wrong.
  
  [ 4497.625606] usb 1-1.2.4: [5] FU [Mic Capture Volume] ch = 1, val = 4608/7680/1
  
  [ 5268.123764] usb 1-1.2.4: reset high-speed USB device number 37 using dwc_otg

  Next time I start the script, the usb cam gets disconnected and /dev/viedo0 disappears :

  pi@raspi:~/appdev/ffmpeg $ dmesg | grep usb
  
  [ 5621.216896] usb 1-1.2.4: USB disconnect, device number 37
  
  [ 5621.586804] usb 1-1.2.4: new full-speed USB device number 38 using dwc_otg
  
  [ 5621.686694] usb 1-1.2.4: device descriptor read/64, error -32
  
  [ 5621.896583] usb 1-1.2.4: device descriptor read/64, error -32
  
  [ 5622.106572] usb 1-1.2.4: new full-speed USB device number 39 using dwc_otg
  
  [ 5622.206574] usb 1-1.2.4: device descriptor read/64, error -32
  
  [ 5622.416577] usb 1-1.2.4: device descriptor read/64, error -32
  
  [ 5622.626586] usb 1-1.2.4: new full-speed USB device number 40 using dwc_otg
  
  [ 5623.046583] usb 1-1.2.4: device not accepting address 40, error -32
  
  [ 5623.146583] usb 1-1.2.4: new full-speed USB device number 41 using dwc_otg
  
  [ 5623.566603] usb 1-1.2.4: device not accepting address 41, error -32
  
  [ 5623.566670] usb 1-1.2-port4: unable to enumerate USB device

  Has anybody experienced similar problems and can provide a fix for it ?

  What tools can I use to troubleshoot the usb communication on the pi ?