Recherche avancée

Sur d’autres sites (6001)

• lavd : deprecate the bktr device

  28 janvier 2024, par Anton Khirnov

  lavd : deprecate the bktr device
  It implements BSD-specific support for very old analog capture cards,
  
  which are highly unlikely to be useful today. After being added in 2005,
  
  there were never any commits to it beyond compilation fixes and generic
  
  maintenance. There have also been zero trac tickets for this device, and
  
  the only related web search result I found concludes that it does not
  
  work.
  The code also does some unacceptable things, like messing with signal
  
  handlers and storing its state in global variables.
  

  • [DH] doc/indevs.texi
  • [DH] libavdevice/bktr.c
  • [DH] libavdevice/version_major.h

• Google Lato Font Display discrepancies between platforms/software [closed]

  5 juin 2024, par CRAIG

  Using Google's Lato font with 400 weight, is giving me some inconsistent results between Photoshop/Web on MacOS and Linux Imagemagick & Linux ffmpeg.

  


  I have printed out some text on my linux server using the font using both imagemagick (v6.9.10-68) and ffmpeg's (v6.0) drawtext feature and in both cases, I get some extra space between the T and the e. (Image below)

  


  At first I was only testing ffmpeg and thought it was related to drawtext, but now that imagemagick is doing the same, I am thinking it may be somehow related to how the server is managing the font ?

  


  I did download the exact same font to test on my Mac and installed it, but I still get the original photoshop results I was getting before. So I don't think it is inherently the font unless I missed a step. I did completely uninstall the font and then install the downloaded one to be sure.

  


  However, the same word, font, font-size combo used in Photoshop and on the web does not produce the same space between the T and the e.

  


  Here is an image I put together showing the results :

  


  

  


  For reference, here is the imagemagick command :

  


  convert -size 900x900 xc:black -font /fonts/Lato:400.ttf -pointsize 261.6 -fill white -gravity center -annotate +0+0 'Text' testoutput.png

  


  And the ffmpeg command :

  


  /usr/local/bin/ffmpeg -f  lavfi  -i  color=c=black@0.0:s=953x953:r=30:d=5,format=rgba  -filter_complex  "drawtext=expansion=none:enable='between(t,0,5)':fontfile='/fonts/Lato\:400.ttf':fontcolor=0xffffffff:fontsize=294:text='Text':x=(w-text_w)/2+0:y=476.5-(max_glyph_a)+(294/2.8)"  -copyts  -threads  1  -c:v  png  -pix_fmt  rgba  -movflags  faststart  -r  30  -t  8  -y  testoutput.mov

  


• swscale/output : fix bilinear yuv2rgb chroma interpolation

  17 décembre 2024, par Niklas Haas

  swscale/output : fix bilinear yuv2rgb chroma interpolation
  These functions were divided into two special cases ; one assuming that
  
  uvalpha == 0, and the other assuming that uvalpha == 2048. This worked fine
  
  for simple 2x chroma upscaling but broke for e.g. yuv410p, non-centered chroma,
  
  or other special cases that involved non-aligned chroma filters.
  Fix it by instead dividing this check into two cases, a uvalpha==0 fast path
  
  and a uvalpha>0 general path. Instead of (A+B)/2 the general path now multiplies
  
  in the true uvalpha weight.
  I tried preserving the old fast path for the case of uvalpha == 2048, but this
  
  was significantly slower in practise versus having just one general path.
  
  However, we still need a uvalpha == 0 path for the unscaled case.
  Fixes : ticket #5083
  
  Signed-off-by : Niklas Haas <git@haasn.dev>
  
  Sponsored-by : Sovereign Tech Fund
  

  • [DH] libswscale/output.c