Recherche avancée

Sur d’autres sites (5189)

• configure : Disable linker warnings for common symbols

  23 février 2024, par Andreas Rheinhardt

  configure : Disable linker warnings for common symbols
  Common symbols are not part of ISO-C and therefore not used
  
  by FFmpeg at all. Yet linker warnings to ensure it stays
  
  that way are nevertheless wrong, because the existence of
  
  common symbols does not imply that there is a bug in our code.
  More precisely, Clang's ASAN implementation uses a common symbol
  
  ___asan_globals_registered when used on Elf targets with
  
  the -fsanitize-address-globals-dead-stripping option ;
  
  said option is the default since Clang 17 [1].
  
  This leads to 1883 warnings about ___asan_globals_registered
  
  when linking here.
  
  (Even without that option there were warnings like
  
  _ZN14__interception10real_vforkE being overridden.)
  Said warning is also unnecessary : The proper way to ensure
  
  that our code is free of common symbols is to let the compiler
  
  enforce this. But this is already the default since GCC 10
  
  and Clang 11, so there is no risk of introducing our own
  
  common symbols.
  [1] : https://reviews.llvm.org/D152604
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] configure

• lavc/arm : fix lack of precision in ff_ps_stereo_interpolate_neon

  22 juin 2017, par Clément Bœsch

  lavc/arm : fix lack of precision in ff_ps_stereo_interpolate_neon
  The code originally pre-multiply by 2 the steps, causing the running sum
  
  of the h factors to drift away due to the lack of precision. It quickly
  
  causes an inaccuracy > 0.01.
  I tried diverse approaches such as multiply by 2.0 (instead of adding
  
  the value itself) without success.
  I'm unable to bench the impact of this change, feel free to compare.
  This commit fixes the incoming aacpsdsp tests.
  Following is an alternative simplified function (matching the incoming
  
  AArch64 code) that may be used :
  function ff_ps_stereo_interpolate_neon, export=1
  
          vld1.32         q0, [r2]
  
          vld1.32         q1, [r3]
  
          ldr             r12, [sp]
  
          vmov.f32        q8, q0
  
          vmov.f32        q9, q1
  
          vzip.32         q8, q0
  
          vzip.32         q9, q1
  
  1 :
  
          vld1.32         d4, [r0,:64]
  
          vld1.32         d6, [r1,:64]
  
          vadd.f32        q8, q8, q9
  
          vadd.f32        q0, q0, q1
  
          vmov.f32        d5, d4
  
          vmov.f32        d7, d6
  
          vmul.f32        q2, q2, q8
  
          vmla.f32        q2, q3, q0
  
          vst1.32         d4, [r0,:64] !
  
          vst1.32         d5, [r1,:64] !
  
          subs            r12, r12, #1
  
          bgt             1b
  
          bx              lr
  
  endfunc
  

  • [DH] libavcodec/arm/aacpsdsp_neon.S

• vf_fade : Make sure to not miss the last lines of a frame

  16 février 2017, par Martin Storsjö

  vf_fade : Make sure to not miss the last lines of a frame
  When slice_h is rounded up due to chroma subsampling, there’s
  
  a risk that jobnr * slice_h exceeds frame->height.
  Prior to a638e9184d63, this wasn’t an issue for the last slice
  
  of a frame, since slice_end was set to frame->height for the last
  
  slice.
  a638e9184d63 tried to fix the case where other slices than the
  
  last one would exceed frame->height (which can happen where the
  
  number of slices/threads is very large compared to the frame
  
  height).
  However, the fix in a638e9184d63 instead broke other cases,
  
  where slice_h * nb_threads < frame->height. Therefore, make
  
  sure the last slice always ends at frame->height.
  CC : libav-stable@libav.org
  
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DBH] libavfilter/vf_fade.c