1. 14 Jun, 2017 1 commit
  2. 11 Jun, 2017 2 commits
  3. 16 May, 2017 1 commit
  4. 12 May, 2017 1 commit
  5. 23 Apr, 2017 1 commit
  6. 18 Apr, 2017 2 commits
  7. 06 Apr, 2017 2 commits
  8. 05 Apr, 2017 1 commit
  9. 04 Apr, 2017 1 commit
  10. 03 Apr, 2017 1 commit
    • Ronald S. Bultje's avatar
      codec_desc: mark some lossless audio codecs as intraonly. · 467a0538
      Ronald S. Bultje authored
      Fixes tsan warnings in several audio codecs (flac, alac, wavpack, tta
      and tak) that look like this:
      
      WARNING: ThreadSanitizer: data race (pid=14340)
        Read of size 4 at 0x7d64000169d8 by main thread (mutexes: write M1335):
          #0 update_context_from_thread src/libavcodec/pthread_frame.c:284 (ffmpeg+0x000000dc795f)
      [..]
        Previous write of size 4 at 0x7d64000169d8 by thread T1 (mutexes: write M1333):
          #0 wavpack_decode_block src/libavcodec/wavpack.c:1012 (ffmpeg+0x00000112b175)
      467a0538
  11. 29 Mar, 2017 1 commit
  12. 26 Mar, 2017 1 commit
  13. 23 Mar, 2017 1 commit
    • wm4's avatar
      lavc: Add hwaccel_flags field to AVCodecContext · 156bd827
      wm4 authored
      This "reuses" the flags introduced for the av_vdpau_bind_context() API
      function, and makes them available to all hwaccels. This does not affect
      the current vdpau API, as av_vdpau_bind_context() should obviously
      override the AVCodecContext.hwaccel_flags flags for the sake of
      compatibility.
      
      Cherry-picked from Libav commit 16a163b5.
      Reviewed-by: 's avatarMark Thompson <sw@jkqxz.net>
      156bd827
  14. 21 Mar, 2017 3 commits
    • Marton Balint's avatar
    • Anton Khirnov's avatar
      pthread_frame: do not run hwaccel decoding asynchronously unless it's safe · e0cd598b
      Anton Khirnov authored
      Certain hardware decoding APIs are not guaranteed to be thread-safe, so
      having the user access decoded hardware surfaces while the decoder is
      running in another thread can cause failures (this is mainly known to
      happen with DXVA2).
      
      For such hwaccels, only allow the decoding thread to run while the user
      is inside a lavc decode call (avcodec_send_packet/receive_frame).
      
      Merges Libav commit d4a91e65.
      Signed-off-by: 's avatarwm4 <nfxjfg@googlemail.com>
      Tested-by: 's avatarMichael Niedermayer <michael@niedermayer.cc>
      e0cd598b
    • wm4's avatar
      avcodec, avformat: deprecate anything related to side data merging · d682ae70
      wm4 authored
      This patch deprecates anything that has to do with merging/splitting
      side data. Automatic side data merging (and splitting), as well as all
      API symbols involved in it, are removed completely.
      
      Two FF_API_ defines are dedicated to deprecating API symbols related to
      this: FF_API_MERGE_SD_API removes av_packet_split/merge_side_data in
      libavcodec, and FF_API_LAVF_KEEPSIDE_FLAG deprecates
      AVFMT_FLAG_KEEP_SIDE_DATA in libavformat.
      
      Since it was claimed that changing the default from merging side data to
      not doing it is an ABI change, there are two additional FF_API_ defines,
      which stop using the side data merging/splitting by default (and remove
      any code in avformat/avcodec doing this): FF_API_MERGE_SD in libavcodec,
      and FF_API_LAVF_MERGE_SD in libavformat.
      
      It is very much intended that FF_API_MERGE_SD and FF_API_LAVF_MERGE_SD
      are quickly defined to 0 in the next ABI bump, while the API symbols are
      retained for a longer time for the sake of compatibility.
      AVFMT_FLAG_KEEP_SIDE_DATA will (very much intentionally) do nothing for
      most of the time it will still be defined. Keep in mind that no code
      exists that actually tries to unset this flag for any reason, nor does
      such code need to exist. Code setting this flag explicitly will work as
      before. Thus it's ok for AVFMT_FLAG_KEEP_SIDE_DATA to do nothing once
      side data merging has been removed from libavformat.
      
      In order to avoid that anyone in the future does this incorrectly, here
      is a small guide how to update the internal code on bumps:
      
      - next ABI bump (probably soon):
        - define FF_API_LAVF_MERGE_SD to 0, and remove all code covered by it
        - define FF_API_MERGE_SD to 0, and remove all code covered by it
      - next API bump (typically two years in the future or so):
        - define FF_API_LAVF_KEEPSIDE_FLAG to 0, and remove all code covered
          by it
        - define FF_API_MERGE_SD_API to 0, and remove all code covered by it
      
      This forces anyone who actually wants packet side data to temporarily
      use deprecated API to get it all. If you ask me, this is batshit fucked
      up crazy, but it's how we roll. Making AVFMT_FLAG_KEEP_SIDE_DATA to be
      set by default was rejected as an ABI change, so I'm going all the way
      to get rid of this once and for all.
      Reviewed-by: 's avatarJames Almer <jamrial@gmail.com>
      Reviewed-by: 's avatarRostislav Pehlivanov <atomnuker@gmail.com>
      Reviewed-by: 's avatarMichael Niedermayer <michael@niedermayer.cc>
      d682ae70
  15. 17 Mar, 2017 1 commit
  16. 16 Mar, 2017 1 commit
  17. 12 Mar, 2017 1 commit
  18. 09 Mar, 2017 1 commit
    • wm4's avatar
      avcodec: clarify some decoding/encoding API details · f940492b
      wm4 authored
      Make it clear that there is no timing-dependent behavior. In particular,
      there is no state in which both input and output are denied, and where
      you have to wait for a while yourself to make progress (apparently some
      hardware decoders like to do this).
      
      Avoid wording that makes references to time. It shouldn't be mistaken
      for some kind of asynchronous API (like POSIX read() can return EAGAIN
      if there is no new input yet). It's a state machine, so try to use
      appropriate terms.
      Signed-off-by: 's avatarDiego Biurrun <diego@biurrun.de>
      
      Merges Libav commit 8a60bba0.
      f940492b
  19. 02 Mar, 2017 2 commits
  20. 22 Feb, 2017 1 commit
  21. 13 Feb, 2017 1 commit
  22. 12 Feb, 2017 1 commit
  23. 11 Feb, 2017 1 commit
  24. 19 Jan, 2017 1 commit
  25. 12 Jan, 2017 1 commit
  26. 11 Jan, 2017 1 commit
    • Steinar H. Gunderson's avatar
      avcodec: add Newtek SpeedHQ decoder · 2a293ec7
      Steinar H. Gunderson authored
      This decoder can decode all existing SpeedHQ formats (SHQ0–5, 7, and 9),
      including correct decoding of the alpha channel.
      
      1080p is decoded in 142 fps on one core of my i7-4600U (2.1 GHz Haswell),
      about evenly split between bitstream reader and IDCT. There is currently
      no attempt at slice or frame threading, even though the format trivially
      supports both.
      
      NewTek very helpfully provided a full set of SHQ samples, as well as
      source code for an SHQ2 encoder (not included) and assistance with
      understanding some details of the format.
      2a293ec7
  27. 22 Dec, 2016 2 commits
  28. 19 Dec, 2016 1 commit
    • Anton Khirnov's avatar
      pthread_frame: do not run hwaccel decoding asynchronously unless it's safe · d4a91e65
      Anton Khirnov authored
      Certain hardware decoding APIs are not guaranteed to be thread-safe, so
      having the user access decoded hardware surfaces while the decoder is
      running in another thread can cause failures (this is mainly known to
      happen with DXVA2).
      
      For such hwaccels, only allow the decoding thread to run while the user
      is inside a lavc decode call (avcodec_send_packet/receive_frame).
      d4a91e65
  29. 14 Dec, 2016 3 commits
    • Anton Khirnov's avatar
    • Anton Khirnov's avatar
      decode: restructure the core decoding code · 061a0c14
      Anton Khirnov authored
      Currently, the new decoding API is pretty much just a wrapper around the
      old deprecated one. This is problematic, since it interferes with making
      full use of the flexibility added by the new API. The old API should
      also be removed at some future point.
      
      Reorganize the code so that the new send_packet/receive_frame functions
      call the actual decoding directly and change the old deprecated
      avcodec_decode_* functions into wrappers around the new API.
      
      The new internal API for decoders is now changing as well. Before this
      commit, it mirrors the public API, so the decoders need to implement
      send_packet() and receive_frame() callbacks. This turns out to require
      awkward constructs in both the decoders and the generic code. After this
      commit, the decoders only implement the receive_frame() callback and
      call a new internal function, ff_decode_get_packet() to obtain input
      data, in the same manner to how the bitstream filters now work.
      
      avcodec will now always make a reference to the input packet, which means
      that non-refcounted input packets will be copied. Keeping the previous
      behaviour, where this copy could sometimes be avoided, would make the
      code significantly more complex and fragile for only dubious gains,
      since packets are typically small and everyone who cares about
      performance should use refcounted packets anyway.
      061a0c14
    • Martin Vignali's avatar
      libavcodec : add decoder for Photoshop PSD image files · 90af9629
      Martin Vignali authored
      Decode the Image Data Section (which contains merged pictures).
      Support RGB/A and Grayscale/A in 8bits and 16 bits per channel.
      Support uncompress and rle decompression in Image Data Section.
      Signed-off-by: 's avatarMichael Niedermayer <michael@niedermayer.cc>
      90af9629
  30. 10 Dec, 2016 1 commit
  31. 07 Dec, 2016 1 commit