Sur d’autres sites (4473)

• A *hot* Piwik Community Meetup 2015 !

  10 août 2015, par André Bräkling — Community

  Last weekend I arrived in Germany to attend the Piwik Community Meetup 2015 and now I am in Poland.

  The meetup was HOT in every sense ! Berlin temperatures reached 35 degrees (celsius), as I finally meet in person several long-time, dedicated Piwik community contributors.

  

  Meetup preparation in Berlin, photo by M. Zawadziński, licensed under CC-BY-SA 4.0

  Pictures from the meetup preparation sessions
  

  In the first leg of my trip I was in Berlin to meet Piwik community members to prepare for the 2015 annual Piwik community meetup. These are my notes taken during the meeting at the request of one of my colleagues. I also relayed live on Framasphère, Twitter and IRC.

  

  Community discussion at the meetup, photo by D.Czajka, licensed under CC-BY-SA 4.0

  More pictures from the Piwik meetup
  

  This was harder than I expected, as I took notes with my laptop, pictures with my phone, wrote live to social media (using the Android Diaspora Native Web App), and used my laptop to relay on IRC. Going forward this requires better preparation, I was glad I had a few links and pictures ready before hand but it really requires intense focus to achieve this. I am glad presenters were patient when I requested repeating some of the ideas they shared. I am also a bit disappointed not much happened in IRC.

  Two day preparation sessions

  The discussions and session we had during the two days prior to the meetup are available here.

  We gathered in rented apartments in Berlin, this reminded me very much of similar community gatherings and perhaps of BarCamp and, at a much smaller scale, UDS sessions.

  

  Piwik Pizza !, photo by F. Rodríguez, licensed under CC-BY-SA 4.0

  A list of ideas of topics was initially submitted, we then proceeded to have scheduled sessions for open discussion. Several people shared their concern there was no possible remote participation which led to making public the Trello boards used/linked here.

  Note : The Trello links below still have action items and notes that are pending bug report / feature requests filing which should happen over the coming weeks. Most importantly, many action items will need identifying leads for different community team including Translations and Documentation, and better coordination of coming community engagement.

  Monday sessions consisted of the following subjects :

  • What are Piwik values & how to communicate them ? (see below for details)
  • How to encourage and recognize new external contributors ?
  • How could we double the Piwik userbase ?
  • How Community can organise help resources

  On Tuesday we met again to discuss the following subjects :

  • Piwik Long Term support (LTS)
  • How do Piwik.org (project) and Piwik PRO (company) sit together / are organized ? – An important part of this session was about having better communication channels and improving the new team page (bug #8520 and bug #8519, respectively)
  • Improving usability of Piwik e.g. for new users – this last session was not held has we ran out of time and prepared to go to the meetup venue.

  Some more details about individual preparation sessions

  What are Piwik values & how to communicate them ?

  The main subjects in this session were important changes proposed in the project mission and values. This was edited directly on on the wiki page on GitHub, some of the changes can be seen by comparing revisions.

  Piwik mission statement (bug #7376)

  “To create the leading Free and open source analytics platform, and to support global organisations and communities to keep full control over their data.”

  Our values

  • Openness
  • Freedom
  • Transparency
  • Data ownership
  • Privacy
  • Kaizen (改善) : continuous improvement

  This was also presented by Matthieu Aubry at the meetup and is published in the Roadmap page. Bringing more visibility and perhaps having a top page for Mission and Values was also brought up.

  Meetup agenda and notes

  The official agenda is available here.

  Many Piwik PRO employees stayed in Berlin for the meetup, and we had good participation although less than last year in Munich as my colleagues told me. Some were consultants, others staff from public organizations, universities, etc. In retrospect considering the very hot weather and summer holidays the attendance was good. I was very happy to arrive at the beautiful Kulturbrauerei and enter the air-conditioned Soda Club. T-Shirts were waiting for all attendees and free drinks (non-alcohol !) were welcome

• FFmpeg : What re-encoding settings can be used to achieve results similar to Google Drive's video processing ?

  4 août 2023, par Mycroft_47

  Context :

  


  I have a large collection of videos recorded by my phone's camera, which is taking up a significant amount of space. Recently, I noticed that when I uploaded a video to Google Drive and then downloaded it again using IDM (by clicking on the pop-up that IDM displays when it detects something that can be downloaded here's what i mean), the downloaded video retained the same visual quality but occupied much less space. Upon further research, I discovered that Google re-encodes uploaded videos using H.264 video encoding, and I believe I can achieve similar compression using FFmpeg.

  


  Problem :

  


  Despite experimenting with various FFmpeg commands, I haven't been able to replicate Google Drive's compression. Every attempt using -codec:v libx264 option alone resulted in videos larger than the original files.

  


  While adjusting the -crf parameter to a higher value and opting for a faster -preset option did yield smaller file sizes, it unfortunately came at the cost of a noticeable degradation in visual quality and the appearance of some visible artifacts in the video.

  


  Google Drive's processing, on the other hand, strikes a commendable balance, achieving a satisfactory file size without compromising visual clarity, (I should note that upon zooming in on this video, I observed some minor blurring, but it was acceptable to me).

  


  Note :

  


  I'm aware that using the H.265 video encoder instead of H.264 may give better results. However, to ensure fairness and avoid any potential bias, I think the optimal approach is first to find the best command using the H.264 video encoder. Once identified, I can then replace -codec:v libx264 with -codec:v libx265. This approach will ensure that the chosen command is really the best that FFMPEG can achieve, and that it is not solely influenced by the superior performance of H.265 when used from the outset.

  


  Here's the FFMPEG command I am currently using :

  


  ffmpeg -hide_banner -loglevel verbose ^
    -i input.mp4 ^
    -codec:v libx264 ^
    -crf 36 -preset ultrafast ^
    -codec:a libopus -b:a 112k ^
    -movflags use_metadata_tags+faststart -map_metadata 0 ^
    output.mp4


  


  





  


  


  


  


  


  


  


  



  


  


  


  


  


  


  


  


  


  


  


  


  


  


  


  


  


  


  


  


  


  


  


  


  


  


  


  


  Video file	Size (bytes)	Bit rate (bps)	Encoder	FFPROB - JSON
  Original (named 'raw 1.mp4')	31,666,777	10,314,710	!!!	link
  Without crf	36,251,852	11,805,216	Lavf60.3.100	link
  With crf	10,179,113	3,314,772	Lavf60.3.100	link
  Gdrive	6,726,189	2,190,342	Google	link

  


  


  Those files can be found here.

  


  Update :

  


  I continued my experiments with the video "raw_1.mp4" and found some interesting results that resemble those shown in this blog post, (I recommend consulting this answer).

  


  In the following figure, I observed that using the -preset set to veryfast provided the most advantageous results, striking the optimal balance between compression ratio and compression time, (Note that a negative percentage in the compression variable indicates an increase in file size after processing) :


  


  In this figure, I used the H.264 encoder and compared the compression ratio of different outputted files resulting from seven different values of the -crf parameter (CRF values used : 25, 27, 29, 31, 33, 35, 37),


  


  For this figure, I've switched the encoder to H.265 while maintaining the same CRF values used in the previous figure :


  


  Based on these results, the -preset veryfast and a -crf value of 31 are my current preferred settings for FFmpeg, until they are proven to be suboptimal choices.
As a result, the FFmpeg command I'll use is as follows :

  


  ffmpeg -hide_banner -loglevel verbose ^
    -i input.mp4 ^
    -codec:v libx264 ^
    -crf 31 -preset veryfast ^
    -codec:a libopus -b:a 112k ^
    -movflags use_metadata_tags+faststart -map_metadata 0 ^
    output.mp4


  


  Note that these choices are based solely on the compression results obtained so far, and they do not take into account the visual quality of the outputted files.

  


• lavfi/vf_libplacebo : support blending multiple inputs

  15 juin 2023, par Niklas Haas

  lavfi/vf_libplacebo : support blending multiple inputs
  Subsequent inputs require frame blending to be enabled, in order to not
  
  overwrite the existing frame contents.
  For output metadata, we implicitly copy the metadata of the *first*
  
  available stream (falling back to the second stream if the first has
  
  already reached EOF, and so on). This is done to resolve any conflicts
  
  between inputs with differing metadata. So when e.g. input 1 is HDR and
  
  output 2 is SDR, the output will be HDR, and vice versa. This logic
  
  could probablly be improved by dynamically determining some "superior"
  
  set of metadata, but I don't want to handle that complexity in this
  
  series.
  

  • [DH] libavfilter/vf_libplacebo.c