1. 02 Jun, 2020 1 commit
  2. 01 Jun, 2020 1 commit
  3. 10 May, 2020 1 commit
  4. 02 May, 2020 1 commit
  5. 10 Apr, 2020 2 commits
    • Anton Khirnov's avatar
      lavc: do not implicitly share the frame pool between threads · 9d6785d4
      Anton Khirnov authored
      Currently the frame pool used by the default get_buffer2()
      implementation is a single struct, allocated when opening the decoder.
      A pointer to it is simply copied to each frame thread and we assume that
      no thread attempts to modify it at an unexpected time. This is rather
      fragile and potentially dangerous.
      
      With this commit, the frame pool is made refcounted, with the reference
      being propagated across threads along with other context variables. The
      frame pool is now also immutable - when the stream parameters change we
      drop the old reference and create a new one.
      9d6785d4
    • Anton Khirnov's avatar
      lavc: replace AVCodecInternal.allocate_progress with an internal cap · 665e5b0f
      Anton Khirnov authored
      This is a constant codec property, so a capability flag is more appropriate.
      665e5b0f
  6. 04 Feb, 2020 1 commit
  7. 22 Jan, 2020 1 commit
  8. 16 Jan, 2020 1 commit
  9. 04 Sep, 2019 1 commit
    • James Almer's avatar
      avcodec/decode: add a flags parameter to ff_reget_buffer() · 9ea6d214
      James Almer authored
      Some decoders may not need a writable buffer in some specific cases, but only
      a reference to the existing buffer with updated frame properties instead, for
      the purpose of returning duplicate frames. For this, the
      FF_REGET_BUFFER_FLAG_READONLY flag is added, which will prevent potential
      allocations and buffer copies when they are not needed.
      Signed-off-by: 's avatarJames Almer <jamrial@gmail.com>
      9ea6d214
  10. 20 Aug, 2019 1 commit
  11. 20 Apr, 2019 1 commit
  12. 04 Dec, 2018 1 commit
  13. 13 Jul, 2018 1 commit
  14. 14 Feb, 2018 1 commit
  15. 26 Dec, 2017 2 commits
    • wm4's avatar
      lavc: remove complex debug code around avcodec init locking · 4ed66517
      wm4 authored
      This is just a lot of complicated and confusing code that had no purpose
      anymore.
      
      Also, the functions return values were checked only sometimes. Locking
      shouldn't fail anyway, so remove the return values. Barely any other
      pthread lock calls check the return value (including more important code
      that is more likely to fail horribly if locking fails).
      
      It could be argued that it might be helpful in some debugging
      situations, or when the user built FFmpeg without thread support against
      all good advice.
      
      But there are dummy atomics too, so the atomic check won't help with
      ensuring correctness absolutely. You gain very little.
      
      Also, for debugging, you can just raise the ASSERT_LEVEL, and then
      libavutil/thread.h will redefine the locking functions to explicitly
      check the return values.
      4ed66517
    • wm4's avatar
      lavc, lavf: move avformat static mutex from avcodec to avformat · 86a13bf2
      wm4 authored
      It's completely absurd that libavcodec would care about libavformat
      locking, but it was there because the lock manager was in libavcodec.
      
      This is more stright forward. Changes ABI, but we don't require ABI
      compatibility currently.
      86a13bf2
  16. 24 Dec, 2017 1 commit
  17. 19 Dec, 2017 1 commit
    • Mark Thompson's avatar
      lavc: Use hardware config information in ff_get_format() · 39056b52
      Mark Thompson authored
      This removes the dependency that hardware pixel formats previously had on
      AVHWAccel instances, meaning only those which actually do something need
      exist after this patch.
      
      Also updates avcodec_default_get_format() to be able to choose hardware
      formats if either a matching device has been supplied or no additional
      external configuration is required, and avcodec_get_hw_frames_parameters()
      to use the hardware config rather than searching the old hwaccel list.
      39056b52
  18. 11 Dec, 2017 1 commit
  19. 26 Nov, 2017 2 commits
    • Mark Thompson's avatar
      lavc: Use hardware config information in ff_get_format() · 67e81d79
      Mark Thompson authored
      This removes the dependency that hardware pixel formats previously had on
      AVHWAccel instances, meaning only those which actually do something need
      exist after this patch.
      
      Also updates avcodec_default_get_format() to be able to choose hardware
      formats if either a matching device has been supplied or no additional
      external configuration is required, and avcodec_get_hw_frames_parameters()
      to use the hardware config rather than searching the old hwaccel list.
      
      The FF_CODEC_CAP_HWACCEL_REQUIRE_CLASS mechanism is deleted because it
      no longer does anything (the codec already contains the pointers to the
      matching hwaccels).
      67e81d79
    • Rostislav Pehlivanov's avatar
      libavcodec/utils.c: simplify avcodec locking with atomics · 590136e7
      Rostislav Pehlivanov authored
      Also makes it more robust than using volatiles.
      Signed-off-by: 's avatarRostislav Pehlivanov <atomnuker@gmail.com>
      590136e7
  20. 19 Nov, 2017 1 commit
    • Martin Storsjö's avatar
      libavcodec: Don't use dllexport, only dllimport when building DLLs · 3152058b
      Martin Storsjö authored
      The only purpose of dllexport (which is set while building the library
      that exports the symbols) is to have the linker automatically
      export such symbols into a DLL without using a def file - it doesn't
      affect the generated code.
      
      For both MSVC and mingw builds, this isn't essential since we override
      what symbols to export via an autogenerated def file instead.
      
      Update a comment in configure to refer to the right concept.
      
      With lld, this avoids warnings about duplicate export directives,
      when some symbols are requested to be exported both via dllexport
      attributes and via the autogenerated def file.
      
      This also reduces the number of lines of code marginally.
      Signed-off-by: 's avatarMartin Storsjö <martin@martin.st>
      3152058b
  21. 10 Nov, 2017 1 commit
    • wm4's avatar
      avcodec: allow multiple hwaccels for the same codec/pixfmt · ae5046e4
      wm4 authored
      Currently, AVHWAccels are looked up using a (codec_id, pixfmt) tuple.
      This means it's impossible to have 2 decoders for the same codec and
      using the same opaque hardware pixel format.
      
      This breaks merging Libav's CUVID hwaccel. FFmpeg has its own CUVID
      support, but it's a full stream decoder, using NVIDIA's codec parser.
      The Libav one is a true hwaccel, which is based on the builtin software
      decoders.
      
      Fix this by introducing another field to disambiguate AVHWAccels, and
      use it for our CUVID decoders. FF_CODEC_CAP_HWACCEL_REQUIRE_CLASS makes
      this mechanism backwards compatible and optional.
      ae5046e4
  22. 22 Oct, 2017 1 commit
  23. 08 Sep, 2017 1 commit
  24. 01 Sep, 2017 1 commit
  25. 31 Aug, 2017 2 commits
  26. 06 May, 2017 1 commit
  27. 01 May, 2017 1 commit
  28. 29 Apr, 2017 1 commit
  29. 23 Mar, 2017 1 commit
  30. 17 Mar, 2017 1 commit
  31. 16 Mar, 2017 1 commit
  32. 09 Mar, 2017 1 commit
    • wm4's avatar
      aacdec: do not mutate input packet metadata · fcfc78cb
      wm4 authored
      Apparently the demuxer outputs the wrong padding for HE-AAC (based on
      the raw sample rate, or so). aacdec contains a hack to adjust the muxer
      padding accordingly before it's used to trim the decoder output. This
      modified the packet side data, which in combination with the old
      decoding API would change the packet the user passed to the decoder.
      This is clearly not allowed, and it breaks running some gapless fate
      tests with "-fflags +keepside" applied (without keepside, the packet
      metadata is typically newly allocated, essentially making a copy and not
      modifying the user's input packet).
      
      This should probably be fixed in the demuxer (and consequently also the
      muxer), but for now only fix the immediate problem.
      
      Regression since 946ed78f (2012).
      fcfc78cb
  33. 12 Jan, 2017 1 commit
  34. 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
    • Anton Khirnov's avatar
      decode: be more explicit about storing the last packet properties · 549d0bdc
      Anton Khirnov authored
      The current code stores a pointer to the packet passed to the decoder,
      which is then used during get_buffer() for timestamps and side data
      passthrough. However, since this is a pointer to user data which we do
      not own, storing it is potentially dangerous. It is also ill defined for
      the new decoding API with split input/output.
      
      Fix this problem by making an explicit internally owned copy of the
      packet properties.
      549d0bdc