Recherche avancée

Sur d’autres sites (4714)

• avdevice/xcbgrab : don't assume xserver endianness

  31 janvier 2021, par Andriy Gelman

  avdevice/xcbgrab : don't assume xserver endianness
  xserver defines the endianness of the grabbed images. Use this information
  
  to set the correct pixel format.
  This also fixes format selection in configuration depth=32/bpp=32 with
  
  xserver on a little endian machine. Before the patch, the big endian
  
  layout 0RGB was always selected which is incorrect because BGR0 should
  
  be used. RGB24 was also incorrectly assumed (but this format was removed
  
  in xserver 1.20).
  The big-endian settings can be tested using docker+qemu from a little-endian
  
  machine :
  $ docker run —rm —privileged multiarch/qemu-user-static —reset -p yes
  
  $ docker run —rm -it -v /tmp :/tmp powerpc64/debian /bin/bash
  In docker container
  
  $ apt-get update
  
  $ apt-get install xvfb
  
  $ apt-get install x11-apps
  To test AV_PIX_FMT_0RGB32
  
  $ Xvfb :2 -screen 0 720x480x24 &
  
  $ export DISPLAY=:2
  
  $ xclock -geometry 720x480 -bg green #test different colors
  On your host machine grab the frames using the following
  
  command. View output to check that colors are rendered correctly
  
  $ ./ffmpeg -y -f x11grab -i :2.0 -codec:v mpeg2video out.mp4
  Other pixel formats can be tested by modifying how Xvfb is started in the docker
  
  container :
  AV_PIX_FMT_RGB565
  
  $ Xvfb :2 -screen 0 720x480x16
  AV_PIX_FMT_RGB555
  
  $ Xvfb :2 -screen 0 720x480x15
  AV_PIX_FMT_BGR24 / AV_PIX_FMT_RGB24
  
  This is difficult to test because bpp=24 support was removed in xserver 1.20
  
  https://lists.x.org/archives/xorg-devel/2018-February/056175.html?hmsr=joyk.com&utm_source=joyk.com&utm_medium=referral
  
  However, I was able to run previous version of Xvfb (with some
  
  modifications to force 24bpp) to check that images are rendered correctly.
  Reviewed-by : Carl Eugen Hoyos <ceffmpeg@gmail.com>
  
  Signed-off-by : Andriy Gelman <andriy.gelman@gmail.com>
  

  • [DH] libavdevice/xcbgrab.c

• slicing and seeking extremeley small sections of video in ffmpeg

  20 février 2021, par Zarc Rowden

  I am writing a program that maps midi data to timestamps in a video. The end result is a kind of automatic generation of audio visuals for beat making or techno heads. The program takes in midi, slices a video into chunks based on the midi events and mappings and finally joins the slices into a video with 1:1 timing of monophonic midi notes to sections of a video.

  


  When it is successful, the result is very cool and watching the video jump around and lock in to midi notes is very interesting

  


  However, I am affraid that the ffmpeg commands I use are not giving exact results.

  


  The code I feed to ffmpeg looks like this

  


  EVENTS : left is midinote number, right is time from start of recording in which note occurs.

  


    [{"note"=>"start", "timestamp"=>0.0},
   {"note"=>48, "timestamp"=>0.5700000037904829},
   {"note"=>51, "timestamp"=>383.7100000018836},
   {"note"=>45, "timestamp"=>884.3500000002678},
   {"note"=>48, "timestamp"=>999.0449999968405},
   {"note"=>51, "timestamp"=>1383.544999996957},
   {"note"=>45, "timestamp"=>1884.2599999989034},
   {"note"=>48, "timestamp"=>1998.890000002575},
   {"note"=>51, "timestamp"=>2383.4199999982957},
   {"note"=>45, "timestamp"=>2884.1000000029453},
   {"note"=>48, "timestamp"=>2998.7200000032317},
   {"note"=>51, "timestamp"=>3383.2800000018324},
   {"note"=>45, "timestamp"=>3883.894999999029},
   {"note"=>48, "timestamp"=>3998.6250000001746},
   {"note"=>51, "timestamp"=>4384.550000002491},
   {"note"=>45, "timestamp"=>4883.780000003753},
   {"note"=>48, "timestamp"=>4998.404999998456},
   {"note"=>51, "timestamp"=>5384.39500000095},
   {"note"=>45, "timestamp"=>5883.565000003728},
   {"note"=>48, "timestamp"=>5998.464999996941},
   {"note"=>51, "timestamp"=>6384.254999997211},
   {"note"=>45, "timestamp"=>6883.4550000028685},
   {"note"=>48, "timestamp"=>6998.585000001185},
   {"note"=>51, "timestamp"=>7384.055000002263},
   {"note"=>45, "timestamp"=>7883.249999998952},],


  


  MAPPINGS : left side is midi note, right is timestamp in seconds

  


  {
 48=>234.3489,
 45=>124.334489,
 51=>2789.34,
}


  


  That Events are a sequential array of midi notes and time taken from recordings or standard midi file. The number is in milliseconds but I convert for ffmpeg before feeding the arguments.

  


  The mappings are just in seconds and tell the program what to show when certain midi notes are encountered as we loop through the events and begin slicing the video.

  


  The command I send to ffmpeg is constructed like this :

  


  "ffmpeg -an -y -ss #{begin_at} -i #{project_tempfile_url} -t #{slice_duration} -c:v libx264 #{temp_url}"


  


  When I concatenate these slices, they only look exact when my notes are very consistent like a kickdrum doing 4/4 rythms. Anything too fast or varied creates unpleasant results.

  


  Is there a specific set of commands that will tell ffmpeg to cut down to the frame ? I think keyframe are not an ideal answer but not sure. I also think I can adjust by making sure that I only ever map the notes to keyframes, I can settle for it but it would be great if I could just cut almost anywhere between start and end like ANYWHERE like

  


    rand(0...video.length)
  # and then have
  332.3253613134


  


  But I may just be dreaming :P

  


  Do you think that I would be better off writing a custom c program to cut frames like this ? I understand that frame rates could be an issue and that there may actually not be any data at 7.34667898999 seconds and that it might be here instead : 7.356788722342 and that ffmpeg probably searches for the nearest frame from whatever timestamp you input, but I feel like there must be a way to get good results still despite these limitations.

  


  Thank you so much in advance for those who take the time to read this and understand this issue.

  


• Matomo to end support for Internet Explorer 11

  21 septembre 2021, par Matomo Core Team — Community

  A lot of the Matomo user interface is built on top of a programming framework called “Angular.js”. The support for this framework will end very soon, meaning we have to migrate the Matomo user interface to an alternative framework. The Matomo development team has chosen this new framework to be “Vue.js 3”.

  Unfortunately, Vue.js does not support Internet Explorer 11 (IE 11). Therefore, we have to drop the support for IE 11. Many other popular services like Microsoft and WordPress recently did the same. This is happening because IE 11 was released about 8 years ago and is now used by less than 0.5% of the internet. 

  When will this change happen ?

  Our next release (Matomo 4.5) will still support IE 11. It will show a notification in the user interface if you are using Internet Explorer to make you aware of this upcoming change. 

  When Matomo 4.6 is released around November 2021, then IE 11 will no longer be supported.

  What does “end support” mean ?

  The Matomo user interface will work less and less over time for people using IE 11 as a browser. While Matomo 4.6 might still mostly work with IE 11, once we migrate more of the user interface the functionality will stop working completely. It’s possible that even Matomo 4.6 will no longer be functional with IE 11 at all.

  What should I do now ?

  If you are impacted by this, then we strongly recommend that you switch to a more modern browser. Preferably a privacy-friendly browser like Mozilla Firefox or Brave. But any modern browser including Microsoft Edge, Safari and Google Chrome will work just fine.

  If you can’t use a different browser and you are using Matomo On-Premise, then you can install and configure this new plugin which lets you only receive Matomo core updates that are compatible with IE 11. This will prevent you from accidentally upgrading to a Matomo core release that doesn’t work with IE 11, and you can still receive critical security updates and bug fixes until February 2022.

  Will this affect the Matomo JavaScript tracker ?

  No, all visitors using IE 11 will still be tracked and Matomo tracker will support the same browsers as before. Meaning also some older versions of Internet Explorer are still supported.

  Have any questions about this ?

  Get in touch with us