1. 07 Mar, 2017 3 commits
    • Muhammad Faiz's avatar
      avcodec/allcodecs: make avcodec_register_all thread safe · e85e8408
      Muhammad Faiz authored
      use ff_thread_once
      Suggested-by: 's avatarwm4 <nfxjfg@googlemail.com>
      Signed-off-by: 's avatarMuhammad Faiz <mfcc64@gmail.com>
      e85e8408
    • Vittorio Giovara's avatar
      avcodec/pixlet: fix architecture-dependent code and values · a6b1180e
      Vittorio Giovara authored
      The constants used in the decoder used floating point precision,
      and this caused different values to be generated on different
      architectures.
      
      So, eradicate floating point numbers and use fixed point (32.32)
      arithmetics everywhere, replacing constants with precomputed integer
      values.
      
      Signed-off-by: Vittorio Giovara <vittorio.giovara at gmail.com>
      Signed-off-by: 's avatarPaul B Mahol <onemda@gmail.com>
      a6b1180e
    • 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. 06 Mar, 2017 8 commits
  3. 05 Mar, 2017 6 commits
  4. 04 Mar, 2017 6 commits
  5. 03 Mar, 2017 17 commits