1. 28 Aug, 2019 1 commit
  2. 29 Jul, 2019 2 commits
    • Andreas Rheinhardt's avatar
      cbs_h264: Improve adding SEI messages · ae49993c
      Andreas Rheinhardt authored
      Up until now, if an SEI messages was to be added to a fragment, it was
      tried to add said SEI message to the first SEI NAL unit of the fragment
      and if this SEI NAL unit already contained H264_NAL_SEI SEI messages (an
      arbitrary limit imposed by cbs_h264), adding failed; if there was no SEI
      NAL unit, a new one has been added.
      With this commit, the fragment is searched for further NAL units to add
      the SEI messages to. If all of them are full, a new SEI NAL unit is added.
      Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      ae49993c
    • Andreas Rheinhardt's avatar
      cbs: Don't set AVBuffer's opaque · 4e7e30bb
      Andreas Rheinhardt authored
      cbs is currently inconsistent regarding the opaque field that can be
      used as a special argument to av_buffer_create in order to be used
      during freeing the buffer: ff_cbs_alloc_unit_content and all the free
      functions used name this parameter as if it should contain a pointer to
      the unit whose content is about to be created; but both
      ff_cbs_alloc_unit_content as well as ff_cbs_h264_add_sei_message
      actually use a pointer to the CodedBitstreamContext as opaque. It should
      actually be neither, because it is unneeded (as is evidenced by the fact
      that none of the free functions use this pointer at all) and because it
      ties the unit's content to the lifetime of other objects, although a
      refcounted buffer is supposed to have its own lifetime that only ends
      when its reference count reaches zero. This problem manifests itself in
      the pointer becoming dangling.
      The pointer to the unit can become dangling if another unit is added to
      the fragment later as happens in the bitstream filters; in this case,
      the pointer can point to the wrong unit (if the fragment's unit array
      needn't be relocated) or it can point to where the array was earlier.
      It can also become dangling if the unit's content is meant to survive
      the resetting of the fragment it was originally read with. This applies
      to the extradata of H.264 and HEVC.
      The pointer to the context can become dangling if the context is closed
      before the content is freed. Although this doesn't seem to happen right
      now, it could happen, in particular if one uses different
      CodedBitstreamContexts for in- and output.
      Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      4e7e30bb
  3. 27 Jul, 2019 1 commit
    • Andreas Rheinhardt's avatar
      cbs: Remove useless initializations · b71a0367
      Andreas Rheinhardt authored
      Up until now, a temporary variable was used and initialized every time a
      value was read in CBS; if reading turned out to be successfull, this
      value was overwritten (without having ever been looked at) with the
      value read if reading was successfull; on failure the variable wasn't
      touched either. Therefore these initializations can be and have been
      removed.
      Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      b71a0367
  4. 20 Jul, 2019 2 commits
    • James Almer's avatar
      avcodec/cbs_h265: add support for Alpha Channel Info SEI messages · e460dcc8
      James Almer authored
      As defined in sections F.14.2.8 and F.14.3.8
      Reviewed-by: 's avatarMark Thompson <sw@jkqxz.net>
      Signed-off-by: 's avatarJames Almer <jamrial@gmail.com>
      e460dcc8
    • Andreas Rheinhardt's avatar
      cbs_h2645: Fix infinite loop in more_rbsp_data · d4035ca8
      Andreas Rheinhardt authored
      cbs_h2645_read_more_rbsp_data does not handle malformed input very well:
      1. If there were <= 8 bits left in the bitreader, these bits were read
      via show_bits. But show_bits requires the number of bits to be read to
      be > 0 (internally it shifts by 32 - number of bits to be read which is
      undefined behaviour if said number is zero; there is also an assert for
      this, but it is only an av_assert2). Furthermore, in this case a shift
      by -1 was performed which is of course undefined behaviour, too.
      2. If there were > 0 and <= 8 bits left and all of them were zero
      (this can only happen for defective input), it was reported that there
      was further RBSP data.
      
      This can lead to an infinite loop in H.265's cbs_h265_read_extension_data
      corresponding to the [vsp]ps_extension_data_flag syntax elements. If the
      relevant flag indicates the (potential) occurence of these syntax elements,
      while all bits after this flag are zero, cbs_h2645_read_more_rbsp_data
      always returns 1 on x86. Given that a checked bitstream reader is used,
      we are also not "saved" by an overflow in the bitstream reader's index.
      Signed-off-by: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      d4035ca8
  5. 08 Jul, 2019 3 commits
  6. 03 Jun, 2019 1 commit
  7. 28 Apr, 2019 1 commit
  8. 16 Apr, 2019 1 commit
  9. 23 Jan, 2019 2 commits
  10. 22 Nov, 2018 1 commit
  11. 18 Nov, 2018 1 commit
  12. 12 Nov, 2018 1 commit
    • Andreas Rheinhardt's avatar
      cbs_h2645: Improve performance of writing slices · ee47ac97
      Andreas Rheinhardt authored
      Instead of using a combination of bitreader and -writer for copying data,
      one can byte-align the (obsolete and removed) bitreader to improve performance.
      With the right alignment one can even use memcpy. The right alignment
      normally exists for CABAC and hence for H.265 in general.
      For aligned data this reduced the time to copy the slicedata from
      776520 decicycles to 33889 with 262144 runs and a 6.5mb/s H.264 video.
      For unaligned data the number went down from 279196 to 97739 decicycles.
      Signed-off-by: 's avatarMark Thompson <sw@jkqxz.net>
      ee47ac97
  13. 22 Oct, 2018 2 commits
  14. 15 Oct, 2018 1 commit
  15. 10 May, 2018 4 commits
  16. 09 May, 2018 1 commit
  17. 02 May, 2018 1 commit
  18. 01 May, 2018 1 commit
  19. 30 Apr, 2018 1 commit
  20. 05 Mar, 2018 1 commit
  21. 20 Feb, 2018 6 commits
  22. 17 Dec, 2017 1 commit
  23. 02 Dec, 2017 1 commit
  24. 12 Nov, 2017 1 commit
  25. 18 Oct, 2017 2 commits