1. 09 Jul, 2019 1 commit
  2. 06 May, 2019 1 commit
    • Aaron Plattner's avatar
      meson: Remove unnecessary 'install' parameter from configure_file() · d6d8ed23
      Aaron Plattner authored
      The 'install' parameter to the configure_file() function explicitly controls
      whether the file is installed, but omitting it just infers whether to install
      the file based on the presence or absence of the 'install_dir' parameter. This
      parameter requires Meson 0.50 or newer:
      
       WARNING: Project specifies a minimum meson_version '>=0.41' but uses features which were added in newer versions:
        * 0.50.0: {'install arg in configure_file'}
      
      We don't need to specify 'install' for this particular file because
      'install_dir' is not set, so just remove it to drop the Meson requirement back
      down to 0.41.
      Signed-off-by: Aaron Plattner's avatarAaron Plattner <aplattner@nvidia.com>
      d6d8ed23
  3. 18 Apr, 2019 1 commit
  4. 25 Mar, 2019 1 commit
    • Aaron Plattner's avatar
      doc: Don't use line-wrapping backslashes in \defgroup definitions · 7d7ceea5
      Aaron Plattner authored
      On my Arch Linux system with doxygen 1.8.15-1, using line-wrapping backslashes
      in \defgroup definitions ends up putting the backslash into the resulting .dot
      file:
      
       digraph "VdpVideoMixer; Video Post-processing \"
      
      graphviz doesn't like that:
      
       Error: /home/aaron/git/libvdpau/build/doc/html/group___vdp_video_mixer.dot: syntax error in line 1 near 'Helvetica'
       error: Problems running dot: exit code=1, command='dot', arguments='"/home/aaron/git/libvdpau/build/doc/html/group___vdp_video_mixer.dot" -Tpng -o "/home/aaron/git/libvdpau/build/doc/html/group___vdp_video_mixer.png"'
      
      Fix this by just removing the line-wrapping even though these lines exceed 80
      columns now.
      Signed-off-by: Aaron Plattner's avatarAaron Plattner <aplattner@nvidia.com>
      7d7ceea5
  5. 24 Mar, 2019 1 commit
  6. 28 Feb, 2019 3 commits
  7. 04 Feb, 2019 1 commit
    • ManojBonda's avatar
      Add HEVC 444 support in VDPAU API · 1b468dea
      ManojBonda authored
      Added new VdpPictureInfoHEVC444 structure for HEVC444 support.
      having the SPS,PPS range extension variables that are defined for HEVC
      444. VdpPictureInfoHEVC is part of VdpPictureInfoHEVC444.
      
      New VdpYCbCr Formats are added to be used in get/putbits for YUV 4:4:4
      surfaces.
      
      Added the capability bits for chromatypes supported.
      
      Add support to return the supported chroma types in
      VdpDecoderQueryProfileCapability API. The supported chroma types
      are returned in a bitmask.
      Signed-off-by: Aaron Plattner's avatarAaron Plattner <aplattner@nvidia.com>
      1b468dea
  8. 20 Nov, 2018 2 commits
    • Aaron Plattner's avatar
      Fix typos from commit 53eeb07f · 52a6ea26
      Aaron Plattner authored
      Signed-off-by: Aaron Plattner's avatarAaron Plattner <aplattner@nvidia.com>
      52a6ea26
    • ManojBonda's avatar
      Add new frame and field mode chroma types. Add VdpDecoderQueryProfileCapability API · 53eeb07f
      ManojBonda authored
      Chroma types :
          VDP_CHROMA_TYPE_420
          VDP_CHROMA_TYPE_422
          VDP_CHROMA_TYPE_444
      
      already exist, surfaces of these types could be transparently used with
      any VdpVideoDecoder. The implementation is free to internally convert
      the surface between frame/field(NV12/NV24) as required by
      VdpVideoDecoder operation. The interop API would allow registration of
      these surfaces for either field or frame based interop.
      
      This change adds new enums for frame and field chroma types:
          VDP_CHROMA_TYPE_420_FIELD
          VDP_CHROMA_TYPE_422_FIELD
          VDP_CHROMA_TYPE_444_FIELD
          VDP_CHROMA_TYPE_420_FRAME
          VDP_CHROMA_TYPE_422_FRAME
          VDP_CHROMA_TYPE_444_FRAME
      
      So that frame/field based video surfaces can be created and exposed via
      VDPAU OpenGL interop.
      
      The new chroma types could only be used by a VdpVideoDecoder that
      supports output to field/frame surfaces respectively. Internal surface
      convertion is not allowed. The interop API would allow registration
      of these surfaces to field/frame based interop only. This will avoid
      implicit conversions and allocation of shadow surface.
      
      Existing VdpDecoderQueryCapabilities() returns maxlevel, maxwidth,
      height and macro blocks for a given decoder profile. Since it is not
      possible to extend this API to return more capabilities, adding new API
      VdpDecoderQueryProfileCapability(). In this change, new API will be able
      to return supported picture structure along with other existing
      capabilities.
      
      VdpDecoderQueryProfileCapability() can be extended in future to query
      newer capabilities exposed. VdpDecoderCapabilities defines the
      capabilities that can be queried.
      
      This function returns queried capability of the requested profile on the
      underlying h/w. By design, only one capability can be queried at a time.
      Signed-off-by: ManojBonda's avatarManoj Bonda <mbonda@nvidia.com>
      Signed-off-by: Aaron Plattner's avatarAaron Plattner <aplattner@nvidia.com>
      53eeb07f
  9. 15 Sep, 2015 1 commit
  10. 08 Sep, 2015 2 commits
  11. 31 Aug, 2015 2 commits
    • Aaron Plattner's avatar
      Bump version to 1.1.1 · af517f56
      Aaron Plattner authored
      Signed-off-by: Aaron Plattner's avatarAaron Plattner <aplattner@nvidia.com>
      af517f56
    • José Hiram Soltren's avatar
      Use secure_getenv(3) to improve security · d1f9c16b
      José Hiram Soltren authored
      This patch is in response to the following security vulnerabilities
      (CVEs) reported to NVIDIA against libvdpau:
      
      CVE-2015-5198
      CVE-2015-5199
      CVE-2015-5200
      
      To address these CVEs, this patch:
      
      - replaces all uses of getenv(3) with secure_getenv(3);
      - uses secure_getenv(3) when available, with a fallback option;
      - protects VDPAU_DRIVER against directory traversal by checking for '/'
      
      On platforms where secure_getenv(3) is not available, the C preprocessor
      will print a warning at compile time. Then, a preprocessor macro will
      replace secure_getenv(3) with our getenv_wrapper(), which utilizes the check:
      
        getuid() == geteuid() && getgid() == getegid()
      
      See getuid(2) and getgid(2) for further details.
      Signed-off-by: Aaron Plattner's avatarAaron Plattner <aplattner@nvidia.com>
      Reviewed-by: Florian Weimer's avatarFlorian Weimer <fweimer@redhat.com>
      d1f9c16b
  12. 27 May, 2015 1 commit
  13. 11 May, 2015 5 commits
  14. 16 Mar, 2015 3 commits
    • Aaron Plattner's avatar
      Bump version to 1.1 · 0962da95
      Aaron Plattner authored
      Signed-off-by: Aaron Plattner's avatarAaron Plattner <aplattner@nvidia.com>
      0962da95
    • Aaron Plattner's avatar
      Change HEVC profile numbers to 100 through 104 · 0b3d6a03
      Aaron Plattner authored
      libvdpau 1.0 contained an error in its HEVC picture info structures.  Rather
      than try to maintain backward compatibility with the incorrect definition, the
      existing VdpPictureInfoHEVC was updated to contain the fixed definition.  Since
      the new structure is no longer compatible with the ABI defined by libvdpau 1.0,
      change the profile numbers for HEVC so that software built against the incorrect
      definition will not recognize the new profiles.
      Signed-off-by: Aaron Plattner's avatarAaron Plattner <aplattner@nvidia.com>
      Reviewed-by: 's avatarJosé Hiram Soltren <jsoltren@nvidia.com>
      0b3d6a03
    • José Hiram Soltren's avatar
      Fix error in sizes of H265 column width and row height, arrays · 8e1e235c
      José Hiram Soltren authored
      An NVIDIA internal hardware document noted:
      
       #define MAX_TILE_COLS 20
       #define MAX_TILE_ROWS 22
      
      As of this writing the VDPAU API writes:
      
          /** Only need to set 0..num_tile_columns_minus1. The struct
              definition reserves up to the maximum of 22. Invalid values are
              ignored. */
          uint16_t column_width_minus1[22];
          /** Only need to set 0..num_tile_rows_minus1. The struct
              definition reserves up to the maximum of 20. Invalid values are
              ignored.*/
          uint16_t row_height_minus1[20];
      
      This is not correct. The correct definitions ought to be:
      
          uint16_t column_width_minus1[20];
          uint16_t row_height_minus1[22];
      
      The H.265 Specification does not give an explicit range for the sizes
      of these arrays. It is possible to calculate an upper limit for a particular
      video frame implicitly using these equations:
      
      MinCbLog2SizeY = log2_min_luma_coding_block_size_minus3 + 3 (7-10)
      CtbLog2SizeY = MinCbLog2SizeY + log2_diff_max_min_luma_coding_block_size (7-11)
      CtbSizeY = 1 << CtbLog2SizeY (7-13)
      PicWidthInCtbsY = Ceil( pic_width_in_luma_samples ÷ CtbSizeY ) (7-15)
      num_tile_columns_minus1 ϵ [0, PicWidthInCtbsY − 1]
      
      (num_tile_rows_minus1 is similar)
      
      For a video with:
      log2_min_luma_coding_block_size_minus3 = 0
      log2_diff_max_min_luma_coding_block_size = 0
      pic_width_in_luma_samples = 4096
      
      num_tile_columns_minus1 < 512
      
      This seems patological. Perhaps we could cap column_width_minus1[] and
      row_height_minus1[] at 32 or 64 elements apiece if other hardware
      implementations saw a reason to do so.
      
      This change as proposed does not alter the size of VdpPictureInfoHEVC, but
      it *does* change the ABI. We can either add it as a fixup to the just
      released VDPAU 1.0, or create a follow-on patch structure. Since few have
      adopted VdpPictureInfoHEVC since Monday my preference is to fix the
      existing structure.
      Signed-off-by: Aaron Plattner's avatarAaron Plattner <aplattner@nvidia.com>
      Acked-by: Aaron Plattner's avatarAaron Plattner <aplattner@nvidia.com>
      8e1e235c
  15. 09 Mar, 2015 1 commit
  16. 09 Feb, 2015 2 commits
    • Aaron Plattner's avatar
      Use member groups to simplify documentation · 705a8166
      Aaron Plattner authored
      For lists of fields that are copied or derived from the video bitstreams, use
      Doxygen member groups to document them once as a block, rather than copying the
      text "Copy of the <whatever> bitstream field." all over the place.  This groups
      the fields together in the HTML.
      Reviewed-by: Christian König's avatarChristian König <christian.koenig@amd.com>
      v2: Rebase on top of José's HEVC work.
      Signed-off-by: Aaron Plattner's avatarAaron Plattner <aplattner@nvidia.com>
      Reviewed-by: 's avatarJosé Hiram Soltren <jsoltren@nvidia.com>
      705a8166
    • José Hiram Soltren's avatar
      Extend the VDPAU API to support H.265/HEVC Decoding · c199b610
      José Hiram Soltren authored
      This patch adds an API for player applications to utilize VDPAU for
      hardware-accelerated playback of H.265/HEVC streams.
      
      The goals of this API are:
      - enable hardware accelerated decoding of H.265/HEVC content under VDPAU;
      - provide a reference implementation for H.265/HEVC hardware decoding that
        is vendor agnostic;
      - provide enough data for H.265/HEVC hardware acceleration implementations
        from multiple vendors to be able to use the same API;
      
      This patch is written against "version one" of the H.265/HEVC Specification,
      Rec. ITU-T H.265 (04/2013), available at:
      
          http://handle.itu.int/11.1002/1000/12296
      
      A future patch against this header may address bug fixes, and may support
      the new features described in "version two" of the H.265/HEVC Specification,
      Rec. ITU-T H.265 v2 (10/2014).
      
      Note that the API does need to be self documenting with Doxygen markup,
      which we (NVIDIA) will generate and post as an update to our public VDPAU
      documentation.
      
      This is version 8 of the patch.
      
      Version 1 was the original version.
      
      Version 2 was a minor cleanup change.
      
      Version 3 incorporated 10- and 12-bit formats.
      
      Version 4 clarified some documentation related to H.265/HEVC support.
      
      Version 5 clarified some documentation related to H.265/HEVC support
      and correcting the Specification URI above.
      
      Version 6 further corrected the Specification URI above, re-ordered the
      fields in VdpPictureInfoHEVC to agree with the Specification, and added
      additional documentation for some fields. It also corrected some cosmetic
      indentation errors.
      
      Version 7 removed the sps_sub_layer_ordering_info_present_flag, added a
      note on implementing clauses 8.3 through 8.7, clarified the meaning of
      sps_max_dec_pic_buffering_minus1, moved the scaling lists to follow
      scaling_list_enabled_flag, clarified comments on pps_beta_offset_div2
      and pps_tc_offset_div2, and added "Ignored otherwise." or "Invalid
      values are ignored" comments to several fields.
      
      Version 8 truncated a number of fields related to reference pictures to
      8 bit types, e.g. uint8_t.
      Signed-off-by: Aaron Plattner's avatarAaron Plattner <aplattner@nvidia.com>
      Reviewed-by: Aaron Plattner's avatarAaron Plattner <aplattner@nvidia.com>
      Acked-by: Christian König's avatarChristian König <christian.koenig@amd.com>
      c199b610
  17. 19 Dec, 2014 1 commit
  18. 12 Dec, 2014 1 commit
  19. 09 Dec, 2014 1 commit
    • Aaron Plattner's avatar
      vdpau.h: define a more strict ABI policy · 3e191f7d
      Aaron Plattner authored
      Because structures defined in vdpau.h may be used outside of the libvdpau
      interface itself, it's important for them to not change, even to add new fields
      to the end.  Clarify this by tightening the restriction on how structures can be
      modified.
      
      This means that we can also *relax* the restriction on versioned structures that
      says that they can only be extended by adding fields to the end.  As long as
      uint32_t struct_version is the first field of the structure, the implementation
      can look at that to determine the complete layout of the rest of the fields.
      Signed-off-by: Aaron Plattner's avatarAaron Plattner <aplattner@nvidia.com>
      Reviewed-by: Christian König's avatarChristian König <christian.koenig@amd.com>
      3e191f7d
  20. 04 Nov, 2014 6 commits
  21. 29 Oct, 2014 3 commits