1. 21 Mar, 2017 18 commits
    • Clément Bœsch's avatar
      Merge commit '0e8d1fc1' · 876e32f7
      Clément Bœsch authored
      * commit '0e8d1fc1':
        lavu: Bump version for the 12bit Planar YUV support
        pixfmt: Add yuv444p12 pixel format
        pixfmt: Add yuv422p12 pixel format
        pixfmt: Add yuv420p12 pixel format
      
      This merge is a noop, we already have all these pixel formats.
      Merged-by: 's avatarClément Bœsch <u@pkh.me>
      876e32f7
    • Clément Bœsch's avatar
      lavc/hwaccel: fix header copyright · 6476bb84
      Clément Bœsch authored
      It was done on a whim because of the FATE header check and was actually
      meant to be removed before pushing.
      
      Also, nobody in review spotted it.
      
      Reviewed-by: wm4
      6476bb84
    • Clément Bœsch's avatar
      Merge commit '2b5b1e1e' · 51f88ac5
      Clément Bœsch authored
      * commit '2b5b1e1e':
        swscale: Rename is9_OR_10 to match what it does
      
      This commit is a noop. We use isNBPS() in these places instead since
      d736b52a. is9_15BPS() wouldn't be a good name in our codebase due to
      supporting only up to 14 (see 2ea585b8).
      Merged-by: 's avatarClément Bœsch <u@pkh.me>
      51f88ac5
    • Clément Bœsch's avatar
      Merge commit 'e87a501e' · 2ea585b8
      Clément Bœsch authored
      * commit 'e87a501e':
        swscale: Update bitdepth range check
      
      This commit is a noop.
      
      Up to 14 bits is supported since fa36f334. This commits pushes the
      limit to 15 bits but we don't seem to have pixel formats that enters in
      that category.
      
      12:03 <ubitux> so what's your opinion? should we move to 15 even if unused currently to make it consistent with libav and the function names, or keep our 14 suggesting there might be an issue with 15?
      12:05 <ubitux> (functions are called hScale8To15_c, hScale16To15_c, ff_hscale8to15, ...)
      12:06 <michaelni> I prefer to keep 14 until theres a case that allows us to test this and i suspect it will not work with 15 at least not all the code
      Merged-by: 's avatarClément Bœsch <u@pkh.me>
      2ea585b8
    • Diego Biurrun's avatar
      b4da4307
    • Clément Bœsch's avatar
      Merge commit 'de8e096c' · fa8db3f5
      Clément Bœsch authored
      * commit 'de8e096c':
        swscale: Consistently order input YUV pixel formats
      Merged-by: 's avatarClément Bœsch <u@pkh.me>
      fa8db3f5
    • Carl Eugen Hoyos's avatar
      ffmpeg: Initialize two stack variables. · 4b192ffd
      Carl Eugen Hoyos authored
      Avoids reading from uninitialized memory, regression since af1761f7
      4b192ffd
    • wm4's avatar
      avcodec: remove warning against using frame threading with hwaccels · 66963d4b
      wm4 authored
      libavcodec now automatically serializes decoding for hwaccels which
      are not thread-safe. This means API users, which rely on the libavcodec
      native software fallback mechanism, can now simply enable threading
      without running into problems.
      66963d4b
    • wm4's avatar
      pthread_frame: remove some dead code · 2e5c5289
      wm4 authored
      Whatever it was supposed to do.
      2e5c5289
    • Anton Khirnov's avatar
      pthread_frame: do not run hwaccel decoding asynchronously unless it's safe · e0cd598b
      Anton Khirnov authored
      Certain hardware decoding APIs are not guaranteed to be thread-safe, so
      having the user access decoded hardware surfaces while the decoder is
      running in another thread can cause failures (this is mainly known to
      happen with DXVA2).
      
      For such hwaccels, only allow the decoding thread to run while the user
      is inside a lavc decode call (avcodec_send_packet/receive_frame).
      
      Merges Libav commit d4a91e65.
      Signed-off-by: 's avatarwm4 <nfxjfg@googlemail.com>
      Tested-by: 's avatarMichael Niedermayer <michael@niedermayer.cc>
      e0cd598b
    • Anton Khirnov's avatar
      pthread_frame: ensure the threads don't run simultaneously with hwaccel · 14bb15bf
      Anton Khirnov authored
      Merges Libav commit 8dfba25c.
      Signed-off-by: 's avatarwm4 <nfxjfg@googlemail.com>
      14bb15bf
    • Wan-Teh Chang's avatar
      pthread_frame: use better memory orders for frame progress · c358c625
      Wan-Teh Chang authored
      This improves commit 59c70227.
      
      In ff_thread_report_progress(), the fast code path can load
      progress[field] with the relaxed memory order, and the slow code path
      can store progress[field] with the release memory order. These changes
      are mainly intended to avoid confusion when one inspects the source code.
      They are unlikely to have measurable performance improvement.
      
      ff_thread_report_progress() and ff_thread_await_progress() form a pair.
      ff_thread_await_progress() reads progress[field] with the acquire memory
      order (in the fast code path). Therefore, one expects to see
      ff_thread_report_progress() write progress[field] with the matching
      release memory order.
      
      In the fast code path in ff_thread_report_progress(), the atomic load of
      progress[field] doesn't need the acquire memory order because the
      calling thread is trying to make the data it just decoded visible to the
      other threads, rather than trying to read the data decoded by other
      threads.
      
      In ff_thread_get_buffer(), initialize progress[0] and progress[1] using
      atomic_init().
      Signed-off-by: 's avatarWan-Teh Chang <wtc@google.com>
      Signed-off-by: 's avatarAnton Khirnov <anton@khirnov.net>
      
      Merges Libav commit 343e2833.
      Signed-off-by: 's avatarwm4 <nfxjfg@googlemail.com>
      c358c625
    • Mark Thompson's avatar
      pthread_frame: Unreference hw_frames_ctx on per-thread codec contexts · fb69a8e1
      Mark Thompson authored
      When decoding with threads enabled, the get_format callback will be
      called with one of the per-thread codec contexts rather than with the
      outer context.  If a hwaccel is in use too, this will add a reference
      to the hardware frames context on that codec context, which will then
      propagate to all of the other per-thread contexts for decoding.  Once
      the decoder finishes, however, the per-thread contexts are not freed
      normally, so these references leak.
      
      Merges Libav commit fd0fae60.
      Signed-off-by: 's avatarwm4 <nfxjfg@googlemail.com>
      fb69a8e1
    • Anton Khirnov's avatar
      98f89d61
    • Anton Khirnov's avatar
      pthread_frame: use atomics for frame progress · b6587421
      Anton Khirnov authored
      Merges Libav commit 59c70227.
      Signed-off-by: 's avatarwm4 <nfxjfg@googlemail.com>
      b6587421
    • Anton Khirnov's avatar
      pthread_frame: use atomics for PerThreadContext.state · 74926269
      Anton Khirnov authored
      Merges Libav commit 64a31b28.
      Signed-off-by: 's avatarwm4 <nfxjfg@googlemail.com>
      74926269
    • wm4's avatar
      ffmpeg: don't unnecessarily use a deprecated API function · 87c082c4
      wm4 authored
      Since we've disabled side data merging in ffmpeg.c, this really changes
      nothing.
      87c082c4
    • wm4's avatar
      avcodec, avformat: deprecate anything related to side data merging · d682ae70
      wm4 authored
      This patch deprecates anything that has to do with merging/splitting
      side data. Automatic side data merging (and splitting), as well as all
      API symbols involved in it, are removed completely.
      
      Two FF_API_ defines are dedicated to deprecating API symbols related to
      this: FF_API_MERGE_SD_API removes av_packet_split/merge_side_data in
      libavcodec, and FF_API_LAVF_KEEPSIDE_FLAG deprecates
      AVFMT_FLAG_KEEP_SIDE_DATA in libavformat.
      
      Since it was claimed that changing the default from merging side data to
      not doing it is an ABI change, there are two additional FF_API_ defines,
      which stop using the side data merging/splitting by default (and remove
      any code in avformat/avcodec doing this): FF_API_MERGE_SD in libavcodec,
      and FF_API_LAVF_MERGE_SD in libavformat.
      
      It is very much intended that FF_API_MERGE_SD and FF_API_LAVF_MERGE_SD
      are quickly defined to 0 in the next ABI bump, while the API symbols are
      retained for a longer time for the sake of compatibility.
      AVFMT_FLAG_KEEP_SIDE_DATA will (very much intentionally) do nothing for
      most of the time it will still be defined. Keep in mind that no code
      exists that actually tries to unset this flag for any reason, nor does
      such code need to exist. Code setting this flag explicitly will work as
      before. Thus it's ok for AVFMT_FLAG_KEEP_SIDE_DATA to do nothing once
      side data merging has been removed from libavformat.
      
      In order to avoid that anyone in the future does this incorrectly, here
      is a small guide how to update the internal code on bumps:
      
      - next ABI bump (probably soon):
        - define FF_API_LAVF_MERGE_SD to 0, and remove all code covered by it
        - define FF_API_MERGE_SD to 0, and remove all code covered by it
      - next API bump (typically two years in the future or so):
        - define FF_API_LAVF_KEEPSIDE_FLAG to 0, and remove all code covered
          by it
        - define FF_API_MERGE_SD_API to 0, and remove all code covered by it
      
      This forces anyone who actually wants packet side data to temporarily
      use deprecated API to get it all. If you ask me, this is batshit fucked
      up crazy, but it's how we roll. Making AVFMT_FLAG_KEEP_SIDE_DATA to be
      set by default was rejected as an ABI change, so I'm going all the way
      to get rid of this once and for all.
      Reviewed-by: 's avatarJames Almer <jamrial@gmail.com>
      Reviewed-by: 's avatarRostislav Pehlivanov <atomnuker@gmail.com>
      Reviewed-by: 's avatarMichael Niedermayer <michael@niedermayer.cc>
      d682ae70
  2. 20 Mar, 2017 22 commits