Recherche avancée

Sur d’autres sites (6283)

• Offline tracking in Matomo JavaScript Tracker – We need your feedback

  16 octobre 2020, par Matomo Core Team — Development, Uncategorized

  As part of our Matomo 4 release we are working on adding support for offline tracking using service workers (SW) and IndexedDB. An early version of this new feature is now available as part of our latest Matomo 4 beta and we now need your feedback to fix any outstanding issues.

  How does it work behind the scenes ?

  • The service worker caches the Matomo JavaScript tracker so if a user becomes offline on subsequent requests the JS tracker will be still loaded.
  • If a user is offline, any tracking request will be put into the local IndexedDB.
  • Once the user becomes online, all requests from the IndexedDB will be retried.

  How do I integrate offline tracking into my website or app ?

  Follow the steps in our FAQ on how to set up offline tracking. 

  We need your feedback

  We’d love to hear your feedback if this new feature is working for you or not. Simply leave a comment on the offline tracking issue and let us know if it worked for you, if something didn’t work, whether you miss any options or any other kind of feedback.

  Are you a service worker or IndexedDB pro ? We’d love if you could help us review our implementation. You can check out the code in the offline tracking pull request. We appreciate any feedback to help us improve this feature !

  Thank you for your help !

• Improve ffmpeg scene detection in particular scenario

  17 septembre 2021, par Nobody-Knows-I-am-a-Dog

  I have 50 hours of video where a speaker is in the lower right corner of the video and the by far larger part of the video consists of slides in the center. The speaker moves a bit, the slides transition into the video. I need to detect the time codes of the slide transitions. +- 1 second precision is fine. I am playing around with select filters in ffmpeg such as ffmpeg -i lecture.mp4  -filter:v "select='gt(scene,0.1)',showinfo"   -f null - but I have remaining problems where some help or hint would be highly appreciated.

  


  Problem 1 : Speaker movement occasionally triggers false positives. If there is some possibility to restrict frame comparison to a certain (spatial, cropped) area of the scene then I could focus on the slide area and this would greatly help.

  


  Problem 2 : Speed of slide transition is slow so I occasionally miss a transition since the change from frame(n) to frame(n+1) is too small. It would be great if I could compare, for example, frame(n) to frame(n+10) for threshold detection. ffmpeg scene detection : check only every nth frame ? does not help here, because it only checks every n-th frame but still compares a frame with its immediate neighbor.

  


  Of course, both problems can be solved by producing a cropped version with reduced framerate. However, I am looking for a solution where I can do this in a single pass with some complex filter expression ... and this is exactly the place where my own experience with ffmpeg fails me and where I would appreciate some help.

  


  Problem 3 : Occasionally a single slide transition triggers several times in a row throughout the transition. I have no idea how to solve this in ffmpeg.

  


• FFmpeg : negative video duration

  19 octobre 2020, par quento

  FFmpeg is used to combine images into video and then duration is taken out of this video.

  


  Surprisingly I found out that FFmpeg could return negative duration.

  


  Command to get duration. This command is the most reliable according to this spec

  


  


  You can also use ffmpeg to get the duration by fully decoding the file. The null muxer is used so no output file is created. Refer to time= in the next-to-last line of the console output. In this example the input has a duration of 00:57:28.87.

  


  


  ffmpeg -i input.webm -f null -  


  


  Output ex :

  


  frame=206723 fps=1390 q=-0.0 Lsize=N/A time=00:57:28.87 bitrate=N/A speed=23.2x


  


  Actual example

  


  Generation of mp4 of screenshots :

  


  `/usr/bin/ffmpeg' -framerate 30 -pattern_type glob -i '/app/tmp/ecc0fe7b5ca4d7b20ea54d3ba757cfbf_b4581272-c485-4be2-a210-cbc99d71bd14_0/*.jpeg' -c:v libx264 -vf 'scale=trunc(iw/2)*2:trunc(ih/2)*2' -pix_fmt yuv420p -filter:v 'setpts=1.11*PTS' '/app/tmp/ecc0fe7b5ca4d7b20ea54d3ba757cfbf_b4581272-c485-4be2-a210-cbc99d71bd14_0/ecc0fe7b5ca4d7b20ea54d3ba757cfbf.mp4`


  


  Next, extracting duration :

  


  /usr/bin/ffmpeg' -i '/app/tmp/ecc0fe7b5ca4d7b20ea54d3ba757cfbf_b4581272-c485-4be2-a210-cbc99d71bd14_0/ecc0fe7b5ca4d7b20ea54d3ba757cfbf.mp4  -f null


  


  Output :

  


  time=-577014:32:22.77


  


  Unfortunately I can't reproduce this issue on local machine so far, so there are not many details to share. However, such cases appear on other machines quite frequently. Different videos get exactly the same broken time. There are also enough other inconsistent cases.

  


  One of the suggestions is to parse extraction out of first command, which generates video. I'm not sure that I won't also face negative numbers there, though.

  


  Most probably I miss much more easier solution. The only requirement is that is must be 100% precise.

  


  Thanks in advance !