Recherche avancée

Sur d’autres sites (11444)

• swscale/cms : add color management subsystem

  29 novembre 2024, par Niklas Haas

  swscale/cms : add color management subsystem
  The underlying color mapping logic was ported as straightforwardly as possible
  
  from libplacebo, although the API and glue code has been very heavily
  
  refactored / rewritten. In particular, the generalization of gamut mapping
  
  methods is replaced by a single ICC intent selection, and constants have been
  
  hard-coded.
  To minimize the amount of overall operations, this gamut mapping LUT now embeds
  
  a direct end-to-end transformation to the output color space ; something that
  
  libplacebo does in shaders, but which is prohibitively expensive in software.
  In order to preserve compatibility with dynamic tone mapping without severely
  
  regressing performance, we add the ability to generate a pair of "split" LUTS,
  
  one for encoding the input and output to the perceptual color space, and a
  
  third to embed the tone mapping operation. Additionally, this intermediate
  
  space could be used for additional subjective effect (e.g. changing
  
  saturation or brightness).
  The big downside of the new approach is that generating a static color mapping
  
  LUT is now fairly slow, as the chromaticity lobe peaks have to be recomputed
  
  for every single RGB value, since correlated RGB colors are not necessarily
  
  aligned in ICh space. Generating a split 3DLUT significantly alleviates this
  
  problem because the expensive step is done as part of the IPT input LUT, which
  
  can share the same hue peak calculation at least for all input intensities.
  

  • [DH] libswscale/Makefile
  • [DH] libswscale/cms.c
  • [DH] libswscale/cms.h

• lavfi/vf_drawtext : fix memory management when destroying font face

  31 octobre 2024, par Leandro Santiago

  lavfi/vf_drawtext : fix memory management when destroying font face
  Ref https://trac.ffmpeg.org/ticket/11152
  According to harfbuzz docs, hb_ft_font_set_funcs() does not need to be
  
  called, as, quoted :
  ```
  
  An #hb_font_t object created with hb_ft_font_create()
  
  is preconfigured for FreeType font functions and does not
  
  require this function to be used.
  
  ```
  Using this function seems to cause memory management issues between
  
  harfbuzz and freetype, and could be eliminated.
  This commit also call hb_ft_font_changed() when the underlying FC_Face
  
  changes size, as stated on hardbuzz :
  ```
  
  HarfBuzz also provides a utility function called hb_ft_font_changed() that you should call
  
  whenever you have altered the properties of your underlying FT_Face, as well as a hb_ft_get_face()
  
  that you can call on an hb_font_t font object to fetch its underlying FT_Face.
  
  ```
  Finally, the execution order between hb_font_destroy() and
  
  hb_buffer_destroy() is flipped to match the order of creation of
  
  the respective objects.
  Signed-off-by : Leandro Santiago <leandrosansilva@gmail.com>
  
  Signed-off-by : Marton Balint <cus@passwd.hu>
  

  • [DH] libavfilter/vf_drawtext.c

• FFMPEG syntax clarification question for the "between" function [closed]

  31 octobre 2024, par user2571504

  I've been using a crop filter script to hold the crop in one place for the first 750 frames, then automate a moving crop to follow some action in the clip. It's working great for chunky moves (5 pixel jumps as shown below) :

  


  -filter_script:v:0 crop-filter-script.txt

crop='1500:1000:100:
if(between(n,0,750),100,
if(between(n,751,756),105,
if(between(n,757,762),110,
if(between(n,763,768),115,
if(between(n,769,774),120,
if(between(n,775,780),125,
if(between(n,781,786),130,etc


  


  My question is about how "between" is interpreted. Does "between(n,751,756)" mean "frames 751, 752, 753, 754, 755 & 756" ? or does it exclude the start and ending frames, so that it's "between" those two numbers ? Like : 752, 753, 754 & 755 only ?

  


  Thanks !