1. 14 Feb, 2020 1 commit
    • ManojBonda's avatar
      Add HEVC Main 10/12 and HEVC Main 444 10/12 decode support in VDPAU API · 8765a34f
      ManojBonda authored
      Add new profiles present in Range Extension profiles.
      A.3.5 in Annexures of HEVC draft mentions of various profiles
      Main 12,
      Main 444,
      Main 444 10/12,
      Main 422 10/12,
      under format range extension profiles. All these profiles have single
      profile_idc value 4 These are distinguished by additional flags present
      in the bistream specified in Table A.2 of HEVC draft.
      FFmpeg skips parsing the additional flags and maintains single profile
      for all the format range extension profiles. However since various GPU
      generations support various features we are adding all the profiles
      separately so that support can be specified accurately.
      This Change adds the new HEVC profiles in VDPAU.h
      Add new VdpPictureInfoHEVCRangeExt picture parameter structure.
      As HEVC444 profile falls under RangeExtension profiles, Due to
      similarities between Range Extensions profiles, the picture parameter
      structure is re-used.
      Also Adding new VdpChromaTypes for 16bit.
      For 10/12 bit HEVC decoding, the output memory layout will be P010/P012
      respectivley which are similar to P016 format i.e. each component is of
      2 Byte width (16bit) with MSBs as valid bits as per the format.
      Hence adding 16bit surfaces which can accommodate both P010 and P012
      formats and can be used for both 10/12 bit decoding.
      This Change also adds VDP_YCBCR_FORMAT_P016, VDP_YCBCR_FORMAT_P010 YCrCb
      formats to be used by get/put bits functions(transfer functions) to
      access the 16Bit Decoded Surface.
  2. 03 Sep, 2019 2 commits
    • Aaron Plattner's avatar
      doc: Add missing "HEVC Picture Parameter Set" group close marker · a58a1207
      Aaron Plattner authored
      Fixing this imbalance doesn't cause any major changes to the generated
    • Aaron Plattner's avatar
      doc: Use /** @} */ to close Doxygen groups · 385116a9
      Aaron Plattner authored
      Doxygen looks for the sequence /**, so the existing group closing markers that
      use the pattern /*@}*/ are ignored. Use /** @} */ instead.
      Fixes a Doxygen warning:
       libvdpau/include/vdpau/vdpau.h:4870: warning: end of file while inside a group
       libvdpau/include/vdpau/vdpau_x11.h:179: warning: end of file while inside a group
      Also fixes an imbalance in the Doxgen generated module list. From
       * Core API
         * Basic Types
           * Miscellaneous Types
             * Error Handling
               * [etc.]
       * Core API
         * Basic Types
         * Miscellaneous Types
         * Error Handling
         * [etc.]
  3. 26 Jul, 2019 1 commit
    • ManojBonda's avatar
      Add VP9 decode support in VDPAU API · 4475d106
      ManojBonda authored
      Added VP9 decoder profiles and level to VDPAU header file.
      VP9 specification has 4 profiles and 1 level defined.
      A new VdpPictureInfoVP9 structure is defined to pass VP9 specific params
      to the driver.
  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
       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>
  5. 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
      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>
  6. 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>
    • ManojBonda's avatar
      Add new frame and field mode chroma types. Add VdpDecoderQueryProfileCapability API · 53eeb07f
      ManojBonda authored
      Chroma types :
      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:
      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
      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>
  7. 15 Sep, 2015 1 commit
  8. 11 May, 2015 1 commit
  9. 16 Mar, 2015 2 commits
    • 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: default avatarJosé Hiram Soltren <jsoltren@nvidia.com>
    • 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
          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>
  10. 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: default avatarJosé Hiram Soltren <jsoltren@nvidia.com>
    • 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:
      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
      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>
  11. 12 Dec, 2014 1 commit
  12. 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
      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>
  13. 04 Nov, 2014 2 commits
  14. 28 Aug, 2014 1 commit
  15. 20 Feb, 2014 1 commit
  16. 07 Sep, 2010 1 commit
  17. 10 Feb, 2010 1 commit
  18. 08 Feb, 2010 1 commit
  19. 28 Jan, 2010 2 commits
  20. 17 Nov, 2009 1 commit
  21. 23 Oct, 2009 1 commit
  22. 04 Sep, 2009 1 commit
  23. 25 Mar, 2009 1 commit
  24. 15 Mar, 2009 2 commits
  25. 06 Mar, 2009 1 commit
  26. 18 Feb, 2009 1 commit
  27. 13 Feb, 2009 1 commit
  28. 06 Feb, 2009 1 commit
  29. 14 Jan, 2009 1 commit