1. 05 May, 2018 1 commit
  2. 03 May, 2018 1 commit
  3. 30 Apr, 2018 2 commits
  4. 27 Apr, 2018 1 commit
  5. 26 Apr, 2018 2 commits
  6. 19 Apr, 2018 1 commit
    • Jacob Trimble's avatar
      avformat/mov: Increase support for common encryption. · f7221d8e
      Jacob Trimble authored
      - Parse schm atom to get different encryption schemes.
      - Allow senc atom to appear in track fragments.
      - Allow 16-byte IVs.
      - Allow constant IVs (specified in tenc).
      - Allow only tenc to specify encryption (i.e. no senc/saiz/saio).
      - Use sample descriptor to detect clear fragments.
      
      This doesn't support:
      - Different sample descriptor holding different encryption info.
        - Only first sample descriptor can be encrypted.
      - Encrypted sample groups (i.e. seig).
      - Non-'cenc' encryption scheme when using -decryption_key.
      Signed-off-by: 's avatarJacob Trimble <modmaker@google.com>
      Signed-off-by: 's avatarMichael Niedermayer <michael@niedermayer.cc>
      f7221d8e
  7. 16 Apr, 2018 2 commits
  8. 14 Apr, 2018 1 commit
  9. 09 Apr, 2018 1 commit
  10. 08 Apr, 2018 1 commit
    • Maxym Dmytrychenko's avatar
      qsv: adding Multi Frame Encode support · cca5e4f0
      Maxym Dmytrychenko authored
      Starting from API 1.25 helps to improve performance of the simultaneous
      encode, 1:N scenario, like:
      
      ./avconv  -y -hwaccel qsv -c:v h264_qsv -r 30000/1001 -i
      ~/bbb_sunflower_1080p_60fps_normal.mp4  -vframes 600 -an \
          -filter_complex "split=2[s1][s2]; [s1]scale_qsv=1280:720[o1];
      [s2]scale_qsv=960:540[o2]" \
          -map [o1] -c:v h264_qsv -b:v 3200k -minrate 3200k -maxrate 3200k -f
      rawvideo /tmp/3200a.264 \
          -map [o2] -c:v h264_qsv -b:v 1750k -minrate 1750k -maxrate 1750k -f
      rawvideo /tmp/1750a.264
      Signed-off-by: 's avatarMaxym Dmytrychenko <maxim.d33@gmail.com>
      cca5e4f0
  11. 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
  12. 30 Mar, 2018 1 commit
  13. 27 Mar, 2018 1 commit
  14. 24 Mar, 2018 1 commit
  15. 22 Mar, 2018 5 commits
  16. 21 Mar, 2018 2 commits
  17. 18 Mar, 2018 4 commits
    • Mark Thompson's avatar
      hwcontext_vaapi: Always include DRM hwcontext header · 0f3d1c69
      Mark Thompson authored
      Fixes building with VAAPI but not libdrm, which was broken by
      389f4c3e.  Just unconditionally include
      the header, since it doesn't depend on libdrm being present.
      0f3d1c69
    • Mark Thompson's avatar
      hwcontext_vaapi: Fix condition for DRM device derivation · 389f4c3e
      Mark Thompson authored
      vaGetDisplayDRM() is required for this code to work, libdrm is not.
      389f4c3e
    • 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
  18. 16 Mar, 2018 4 commits
  19. 10 Mar, 2018 1 commit
  20. 09 Mar, 2018 1 commit
  21. 07 Mar, 2018 1 commit
  22. 05 Mar, 2018 1 commit
  23. 02 Mar, 2018 1 commit
  24. 01 Mar, 2018 1 commit
  25. 23 Feb, 2018 1 commit
  26. 22 Feb, 2018 1 commit