1. 07 Mar, 2017 1 commit
    • Aman Gupta's avatar
      avcodec/h264, videotoolbox: fix crash after VT decoder fails · b6eaa392
      Aman Gupta authored
      The way videotoolbox hooks in as a hwaccel is pretty hacky. The VT decode
      API is not invoked until end_frame(), so alloc_frame() returns a dummy
      frame with a 1-byte buffer. When end_frame() is eventually called, the
      dummy buffer is replaced with the actual decoded data from
      VTDecompressionSessionDecodeFrame().
      
      When the VT decoder fails, the frame returned to the h264 decoder from
      alloc_frame() remains invalid and should not be used. Before
      97472199, it was accidentally being
      returned all the way up to the API user. After that commit, the dummy
      frame was unref'd so the user received an error.
      
      However, since that commit, VT hwaccel failures started causing random
      segfaults in the h264 decoder. This happened more often on iOS where the
      VT implementation is more likely to throw errors on bitstream anomolies.
      A recent report of this issue can be see in
      http://ffmpeg.org/pipermail/libav-user/2016-November/009831.html
      
      The issue here is that the dummy frame is still referenced internally by the
      h264 decoder, as part of the reflist and cur_pic_ptr. Deallocating the
      frame causes assertions like this one to trip later on during decoding:
      
        Assertion h->cur_pic_ptr->f->buf[0] failed at src/libavcodec/h264_slice.c:1340
      
      With this commit, we leave the dummy 1-byte frame intact, but avoid returning it
      to the user.
      
      This reverts commit 97472199.
      Signed-off-by: 's avatarwm4 <nfxjfg@googlemail.com>
      b6eaa392
  2. 12 Sep, 2016 1 commit
  3. 17 Aug, 2016 1 commit
  4. 19 Jul, 2016 1 commit
  5. 10 Jul, 2016 1 commit
  6. 21 Jun, 2016 5 commits
  7. 14 Jun, 2016 1 commit
  8. 12 Jun, 2016 7 commits
  9. 02 Jun, 2016 2 commits
  10. 04 May, 2016 1 commit
  11. 24 Apr, 2016 5 commits
  12. 28 Mar, 2016 1 commit
  13. 18 Feb, 2016 1 commit
  14. 04 Jan, 2016 2 commits
  15. 03 Jan, 2016 1 commit
  16. 01 Jan, 2016 1 commit
    • Anton Khirnov's avatar
      h264: improve behaviour with invalid reference lists · 9d740127
      Anton Khirnov authored
      Before 741b494f, when the reference list
      modification description was invalid, the code would substitute the
      corresponding reference from the initial ("default") reference list.
      After that commit, it will just return an error.
      
      Since there are apparently invalid samples in the wild that used to play
      fine with the old code, it is a good idea to re-add some sort of error
      resilience here. So, when the reference list modification results in a
      missing frame, substitute a previous reference frame for it. The
      relevant sample again decodes fine with the same output as previously.
      9d740127
  17. 29 Dec, 2015 1 commit
    • Mark Harris's avatar
      avcodec: Use get_ue_golomb_long() when needed · c51c08e0
      Mark Harris authored
      get_ue_golomb() cannot decode values larger than 8190 (the maximum
      value that can be golomb encoded in 25 bits) and produces the error
      "Invalid UE golomb code" if a larger value is encountered.  Use
      get_ue_golomb_long() instead (which supports 63 bits, up to 4294967294)
      when valid h264/hevc values can exceed 8190.
      
      This updates decoding of the following values:   (maximum)
        first_mb_in_slice                                36863* for level 5.2
        abs_diff_pic_num_minus1                         131071
        difference_of_pic_nums_minus1                   131071
        idr_pic_id                                       65535
        recovery_frame_cnt                               65535
        frame_packing_arrangement_id                4294967294
        frame_packing_arrangement_repetition_period      16384
        display_orientation_repetition_period            16384
      
      An alternative would be to modify get_ue_golomb() to handle encoded
      values of up to 49 bits as was done for get_se_golomb() in a92816c4.
      In that case get_ue_golomb() could continue to be used for all of
      these except frame_packing_arrangement_id.
      Signed-off-by: 's avatarMichael Niedermayer <michael@niedermayer.cc>
      c51c08e0
  18. 19 Dec, 2015 1 commit
  19. 06 Dec, 2015 1 commit
    • Anton Khirnov's avatar
      h264: eliminate default_ref_list · 741b494f
      Anton Khirnov authored
      According to the spec, the reference list for a slice should be
      constructed by first generating an initial (what we now call "default")
      reference list and then optionally applying modifications to it.
      
      Our code has an optimization where the initial reference list is
      constructed for the first inter slice and then rebuilt for other slices
      if needed. This, however, adds complexity to the code, requires an extra
      2.5kB array in the codec context and there is no reason to think that it
      has any positive effect on performance. Therefore, simplify the code by
      generating the reference list from scratch for each slice.
      741b494f
  20. 29 Nov, 2015 1 commit
  21. 20 Nov, 2015 1 commit
    • wm4's avatar
      avcodec/h264, videotoolbox: do not return invalid frames on failure · 97472199
      wm4 authored
      If videotoolbox_common_end_frame failed, then the AVFrame was returned
      to the API user with the dummy buffer (in AVFrame.buf[0]) still set, and
      the decode call indicating success.
      
      These "half-set" AVFrames with dummy buffer are a videotoolbox specific
      hack, because the decoder requires an allocated AVFrame for its internal
      logic. Videotoolbox on the other hand allocates its frame itself
      internally, and outputs it only on end_frame. At this point, the dummy
      buffer is replaced with the real frame (unless decoding fails).
      97472199
  22. 29 Jul, 2015 2 commits
  23. 30 Jun, 2015 1 commit