1. 11 Nov, 2019 1 commit
  2. 17 Jan, 2019 1 commit
  3. 21 Dec, 2018 1 commit
  4. 30 Oct, 2018 1 commit
  5. 23 Oct, 2018 1 commit
    • Devin Heitmueller's avatar
      lavc/h264: create AVFrame side data from H.264 timecodes · 4241e44a
      Devin Heitmueller authored
      Create SMPTE ST 12-1 timecodes based on H.264 SEI picture timing
      info.
      
      For framerates > 30 FPS, the field flag is used in conjunction with
      pairs of frames which contain the same frame timestamp in S12M.
      Ensure the field is properly set per the spec.
      4241e44a
  6. 21 Sep, 2018 1 commit
  7. 05 Aug, 2018 1 commit
  8. 06 Jun, 2018 1 commit
  9. 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
  10. 18 Mar, 2018 2 commits
    • wm4's avatar
      lavu/frame: add QP side data · 4b86ac27
      wm4 authored
      This adds a way for an API user to transfer QP data and metadata without
      having to keep the reference to AVFrame, and without having to
      explicitly care about QP APIs. It might also provide a way to finally
      remove the deprecated QP related fields. In the end, the QP table should
      be handled in a very similar way to e.g. AV_FRAME_DATA_MOTION_VECTORS.
      
      There are two side data types, because I didn't care about having to
      repack the QP data so the table and the metadata are in a single
      AVBufferRef. Otherwise it would have either required a copy on decoding
      (extra slowdown for something as obscure as the QP data), or would have
      required making intrusive changes to the codecs which support export of
      this data.
      
      The new side data types are added under deprecation guards, because I
      don't intend to change the status of the QP export as being deprecated
      (as it was before this patch too).
      4b86ac27
    • wm4's avatar
      lavu/frame: fix inconsistent qp_table_buf deprecation · 36855abc
      wm4 authored
      Everything related to the QP data is deprecated, with qp_table_buf being
      an inconsistent exception. Some parts were under the deprecation guards,
      some not. It probably didn't even compile.
      36855abc
  11. 01 Mar, 2018 1 commit
  12. 10 Nov, 2017 1 commit
  13. 29 Oct, 2017 1 commit
  14. 23 Oct, 2017 1 commit
  15. 08 Aug, 2017 1 commit
  16. 26 Jul, 2017 2 commits
  17. 06 Apr, 2017 1 commit
  18. 03 Mar, 2017 1 commit
  19. 25 Feb, 2017 2 commits
  20. 13 Feb, 2017 1 commit
    • wm4's avatar
      AVFrame: add an opaque_ref field · e3af49b1
      wm4 authored
      This is an extended version of the AVFrame.opaque field, which can be
      used to attach arbitrary user information to an AVFrame.
      
      The usefulness of the opaque field is rather limited, because it can
      store only up to 32 bits of information (or 64 bit on 64 bit systems).
      It's not possible to set this field to a memory allocation, because
      there is no way to deallocate it correctly.
      
      The opaque_ref field circumvents this by letting the user set an
      AVBuffer, which makes the user data refcounted.
      Signed-off-by: 's avatarAnton Khirnov <anton@khirnov.net>
      
      Merges Libav commit 04f3bd34.
      e3af49b1
  21. 11 Feb, 2017 2 commits
    • wm4's avatar
      AVFrame: add an opaque_ref field · 04f3bd34
      wm4 authored
      This is an extended version of the AVFrame.opaque field, which can be
      used to attach arbitrary user information to an AVFrame.
      
      The usefulness of the opaque field is rather limited, because it can
      store only up to 32 bits of information (or 64 bit on 64 bit systems).
      It's not possible to set this field to a memory allocation, because
      there is no way to deallocate it correctly.
      
      The opaque_ref field circumvents this by letting the user set an
      AVBuffer, which makes the user data refcounted.
      Signed-off-by: 's avatarAnton Khirnov <anton@khirnov.net>
      04f3bd34
    • Anton Khirnov's avatar
      frame: allow align=0 (meaning automatic) for av_frame_get_buffer() · 4de220d2
      Anton Khirnov authored
      This will avoid every caller from hardcoding some specific alignment,
      which may break in the future with new instruction sets.
      4de220d2
  22. 30 Jan, 2017 1 commit
  23. 12 Jan, 2017 1 commit
  24. 16 Nov, 2016 2 commits
  25. 19 Sep, 2016 1 commit
  26. 25 Jul, 2016 1 commit
  27. 21 Jun, 2016 1 commit
    • Anton Khirnov's avatar
      lavc: export the timestamps when decoding in AVFrame.pts · 32c83590
      Anton Khirnov authored
      Currently it's exported as AVFrame.pkt_pts, which is also the only use
      for that field. The reason it is done like this is that lavc used to
      export various codec-specific "timing" information in AVFrame.pts, which
      is not done anymore.
      
      Since it is confusing to the callers to have a separate field which is
      used only for decoder timestamps and nothing else, deprecate pkt_pts and
      use just AVFrame.pts everywhere.
      32c83590
  28. 05 Jun, 2016 1 commit
  29. 18 Feb, 2016 1 commit
  30. 14 Feb, 2016 1 commit
  31. 13 Feb, 2016 1 commit
  32. 01 Feb, 2016 1 commit
  33. 27 Jan, 2016 1 commit
  34. 22 Jan, 2016 1 commit
  35. 11 Jan, 2016 1 commit