1. 19 Dec, 2018 1 commit
  2. 03 Apr, 2018 1 commit
    • wm4's avatar
      avutil/pixdesc: deprecate AV_PIX_FMT_FLAG_PSEUDOPAL · d6fc031c
      wm4 authored
      PSEUDOPAL pixel formats are not paletted, but carried a palette with the
      intention of allowing code to treat unpaletted formats as paletted. The
      palette simply mapped the byte values to the resulting RGB values,
      making it some sort of LUT for RGB conversion.
      
      It was used for 1 byte formats only: RGB4_BYTE, BGR4_BYTE, RGB8, BGR8,
      GRAY8. The first 4 are awfully obscure, used only by some ancient bitmap
      formats. The last one, GRAY8, is more common, but its treatment is
      grossly incorrect. It considers full range GRAY8 only, so GRAY8 coming
      from typical Y video planes was not mapped to the correct RGB values.
      This cannot be fixed, because AVFrame.color_range can be freely changed
      at runtime, and there is nothing to ensure the pseudo palette is
      updated.
      
      Also, nothing actually used the PSEUDOPAL palette data, except xwdenc
      (trivially changed in the previous commit). All other code had to treat
      it as a special case, just to ignore or to propagate palette data.
      
      In conclusion, this was just a very strange old mechnaism that has no
      real justification to exist anymore (although it may have been nice and
      useful in the past). Now it's an artifact that makes the API harder to
      use: API users who allocate their own pixel data have to be aware that
      they need to allocate the palette, or FFmpeg will crash on them in
      _some_ situations. On top of this, there was no API to allocate the
      pseuo palette outside of av_frame_get_buffer().
      
      This patch not only deprecates AV_PIX_FMT_FLAG_PSEUDOPAL, but also makes
      the pseudo palette optional. Nothing accesses it anymore, though if it's
      set, it's propagated. It's still allocated and initialized for
      compatibility with API users that rely on this feature. But new API
      users do not need to allocate it. This was an explicit goal of this
      patch.
      
      Most changes replace AV_PIX_FMT_FLAG_PSEUDOPAL with FF_PSEUDOPAL. I
      first tried #ifdefing all code, but it was a mess. The FF_PSEUDOPAL
      macro reduces the mess, and still allows defining FF_API_PSEUDOPAL to 0.
      
      Passes FATE with FF_API_PSEUDOPAL enabled and disabled. In addition,
      FATE passes with FF_API_PSEUDOPAL set to 1, but with allocation
      functions manually changed to not allocating a palette.
      d6fc031c
  3. 14 Nov, 2017 1 commit
  4. 31 Aug, 2017 1 commit
  5. 10 Apr, 2017 1 commit
  6. 31 Mar, 2017 1 commit
  7. 20 Feb, 2017 1 commit
  8. 19 Feb, 2017 1 commit
  9. 12 Jan, 2017 1 commit
  10. 17 Aug, 2016 1 commit
  11. 03 Aug, 2016 1 commit
  12. 22 Mar, 2016 1 commit
  13. 18 Mar, 2016 1 commit
    • Ganesh Ajjanagadde's avatar
      lavc/aacenc_utils: replace powf(x,y) by expf(logf(x), y) · bccc81df
      Ganesh Ajjanagadde authored
      This is ~2x faster for y not an integer on Haswell+GCC, and should
      generally be faster due to the fact that anyway powf essentially does
      this under the hood. Made an inline function in lavu/internal.h for this
      purpose.
      
      Note that there are some accuracy differences, that should generally be
      negligible. In particular, FATE still passes on this platform.
      
      Results in ~ 7% speedup in aac encoding with -march=native, Haswell+GCC.
      before:
      ffmpeg -i sin.flac -acodec aac -y sin_new.aac  6.05s user 0.06s system 104% cpu 5.821 total
      
      after:
      ffmpeg -i sin.flac -acodec aac -y sin_new.aac  5.67s user 0.03s system 105% cpu 5.416 total
      
      This is also faster than an alternative approach that pulls in powf, gets rid of
      the crufty NaN checks and other special cases, exploits knowledge about the intervals, etc.
      This of course does not exclude smarter approaches; just suggests that
      there would need to be significant work on this front of lower utility than
      searches for hotspots elsewhere.
      Reviewed-by: 's avatarReimar Döffinger <Reimar.Doeffinger@gmx.de>
      Reviewed-by: 's avatarRonald S. Bultje <rsbultje@gmail.com>
      Signed-off-by: 's avatarGanesh Ajjanagadde <gajjanag@gmail.com>
      bccc81df
  14. 12 Mar, 2016 1 commit
  15. 25 Dec, 2015 1 commit
  16. 14 Dec, 2015 1 commit
    • Janne Grunau's avatar
      libavutil: move FFALIGN macro from common.h to macros.h · 50078c1c
      Janne Grunau authored
      Include macros.h explicitly in common.h so that external code using
      FFALIGN does not break. It was already implicitly included through
      version.h. Include macros.h in lls.h and internal.h for FFALIGN.
      lls.h was including common.h only for FFALIGN and internal.h was
      missing the include for FFALIGN. `make checkheaders` did not catch it
      because it's an internal header.
      50078c1c
  17. 07 Dec, 2015 1 commit
  18. 15 Nov, 2015 1 commit
  19. 16 Oct, 2015 1 commit
  20. 05 Sep, 2015 1 commit
  21. 18 Aug, 2015 1 commit
  22. 11 Aug, 2015 1 commit
  23. 07 Jul, 2015 1 commit
  24. 08 Jun, 2015 1 commit
    • Luca Barbato's avatar
      configure: Support MSVC 2015 · a6f19d6a
      Luca Barbato authored
      The C runtime C99 compatibility had been improved a lot and it now
      rejects some of the compatibility defines provided for the older
      versions.
      
      Many thanks to Ray for the time spent testing.
      
      Bug-Id: 864
      CC: libav-stable@libav.org
      a6f19d6a
  25. 06 May, 2015 1 commit
  26. 06 Mar, 2015 1 commit
  27. 10 Feb, 2015 1 commit
  28. 05 Jan, 2015 1 commit
  29. 24 Nov, 2014 1 commit
  30. 15 Aug, 2014 1 commit
  31. 04 Aug, 2014 1 commit
  32. 25 Apr, 2014 1 commit
  33. 24 Apr, 2014 2 commits
  34. 22 Apr, 2014 1 commit
  35. 26 Jan, 2014 1 commit
  36. 25 Jan, 2014 1 commit
  37. 09 Dec, 2013 1 commit
  38. 21 Oct, 2013 1 commit
  39. 17 Oct, 2013 1 commit
    • Stefano Sabatini's avatar
      lavu/channel_layout: change av_get_channel_layout() behavior at the next bump · d96e377c
      Stefano Sabatini authored
      The new syntax is preferred since it allows backward syntax compatibility
      with libswr when switching to the new option handling code with
      AV_OPT_TYPE_CHANNEL_LAYOUT.
      
      With the new parser the string:
      1234
      
      is interpreted as a channel layout mask, rather than as a number of
      channels, and thus it's compatible with the current way to set a channel
      layout as an integer (e.g. for the icl and ocl options) making use of
      integer option values.
      
      ff_get_channel_layout() with compat=0 will be used in the
      AV_OPT_TYPE_CHANNEL handler code.
      
      The user is encouraged to switch to the new forward compatible syntax,
      which requires to put a trailing "c" when specifying a layout as a number
      of channels.
      d96e377c