1. 14 Dec, 2017 2 commits
    • wm4's avatar
      avcodec: add metadata to identify wrappers and hardware decoders · b945fed6
      wm4 authored
      Explicitly identify decoder/encoder wrappers with a common name. This
      saves API users from guessing by the name suffix. For example, they
      don't have to guess that "h264_qsv" is the h264 QSV implementation, and
      instead they can just check the AVCodec .codec and .wrapper_name fields.
      
      Explicitly mark AVCodec entries that are hardware decoders or most
      likely hardware decoders with new AV_CODEC_CAPs. The purpose is allowing
      API users listing hardware decoders in a more generic way. The proposed
      AVCodecHWConfig does not provide this information fully, because it's
      concerned with decoder configuration, not information about the fact
      whether the hardware is used or not.
      
      AV_CODEC_CAP_HYBRID exists specifically for QSV, which can have software
      implementations in case the hardware is not capable.
      
      Based on a patch by Philip Langdale <philipl@overt.org>.
      
      Merges Libav commit 47687a2f.
      b945fed6
    • wm4's avatar
      avcodec: add metadata to identify wrappers and hardware decoders · 47687a2f
      wm4 authored
      Explicitly identify decoder/encoder wrappers with a common name. This
      saves API users from guessing by the name suffix. For example, they
      don't have to guess that "h264_qsv" is the h264 QSV implementation, and
      instead they can just check the AVCodec .codec and .wrapper_name fields.
      
      Explicitly mark AVCodec entries that are hardware decoders or most
      likely hardware decoders with new AV_CODEC_CAPs. The purpose is allowing
      API users listing hardware decoders in a more generic way. The proposed
      AVCodecHWConfig does not provide this information fully, because it's
      concerned with decoder configuration, not information about the fact
      whether the hardware is used or not.
      
      AV_CODEC_CAP_HYBRID exists specifically for QSV, which can have software
      implementations in case the hardware is not capable.
      
      Based on a patch by Philip Langdale <philipl@overt.org>.
      Signed-off-by: 's avatarLuca Barbato <lu_zero@gentoo.org>
      47687a2f
  2. 31 Dec, 2016 1 commit
  3. 18 Oct, 2016 1 commit
  4. 12 Dec, 2015 1 commit
  5. 09 Sep, 2015 1 commit
  6. 27 Jul, 2015 3 commits
  7. 19 Apr, 2015 1 commit
  8. 17 Jan, 2015 1 commit
  9. 30 Nov, 2014 1 commit
  10. 29 Oct, 2014 1 commit
  11. 13 Oct, 2014 1 commit
    • Anton Khirnov's avatar
      lavc: use a separate field for exporting audio encoder padding · 2df0c32e
      Anton Khirnov authored
      Currently, the amount of padding inserted at the beginning by some audio
      encoders, is exported through AVCodecContext.delay. However
      - the term 'delay' is heavily overloaded and can have multiple different
        meanings even in the case of audio encoding.
      - this field has entirely different meanings, depending on whether the
        codec context is used for encoding or decoding (and has yet another
        different meaning for video), preventing generic handling of the codec
        context.
      
      Therefore, add a new field -- AVCodecContext.initial_padding. It could
      conceivably be used for decoding as well at a later point.
      2df0c32e
  12. 15 Aug, 2014 1 commit
  13. 23 Jun, 2014 1 commit
  14. 19 May, 2014 1 commit
  15. 30 Mar, 2014 3 commits
  16. 09 Dec, 2013 1 commit
  17. 02 Nov, 2013 1 commit
  18. 24 Oct, 2013 2 commits
  19. 03 Oct, 2013 1 commit
  20. 02 Apr, 2013 1 commit
  21. 09 Mar, 2013 1 commit
  22. 08 Mar, 2013 1 commit
  23. 06 Mar, 2013 1 commit
  24. 14 Jan, 2013 2 commits
  25. 26 Nov, 2012 1 commit
  26. 11 Nov, 2012 1 commit
  27. 17 Oct, 2012 1 commit
    • Justin Ruggles's avatar
      libmp3lame: resize the output buffer if needed · abd8b9e7
      Justin Ruggles authored
      The LAME API documentation for the required buffer size refers to the size for
      a single encode call. However, we store multiple frames in the same output
      buffer but only read 1 frame at a time out of it. As a result, the buffer size
      given in lame_encode_buffer() is actually smaller than what it should be.
      Since we do not know how many frames it will end up buffering, it is best to
      just reallocate if needed.
      abd8b9e7
  28. 06 Oct, 2012 1 commit
  29. 04 Sep, 2012 1 commit
  30. 15 Aug, 2012 1 commit
  31. 07 Aug, 2012 1 commit
  32. 10 Jun, 2012 1 commit
  33. 31 May, 2012 1 commit