Skip to content

GitLab

Switch branch/tag
  1. 11 May, 2015 1 commit
  3. 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: default avatarAaron Plattner <aplattner@nvidia.com>
Reviewed-by: default 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: default avatarAaron Plattner <aplattner@nvidia.com>
Acked-by: default avatarAaron Plattner <aplattner@nvidia.com>
      8e1e235c
  5. 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: default avatarChristian König <christian.koenig@amd.com>
v2: Rebase on top of José's HEVC work.
Signed-off-by: default avatarAaron Plattner <aplattner@nvidia.com>
Reviewed-by: default 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: default avatarAaron Plattner <aplattner@nvidia.com>
Reviewed-by: default avatarAaron Plattner <aplattner@nvidia.com>
Acked-by: default avatarChristian König <christian.koenig@amd.com>
      c199b610
  7. 12 Dec, 2014 1 commit
  9. 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: default avatarAaron Plattner <aplattner@nvidia.com>
Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      3e191f7d
  11. 04 Nov, 2014 2 commits
  13. 28 Aug, 2014 1 commit
  15. 20 Feb, 2014 1 commit
  17. 07 Sep, 2010 1 commit
  19. 10 Feb, 2010 1 commit
  21. 08 Feb, 2010 1 commit
  23. 28 Jan, 2010 2 commits
  25. 17 Nov, 2009 1 commit
  27. 23 Oct, 2009 1 commit
  29. 04 Sep, 2009 1 commit
  31. 25 Mar, 2009 1 commit
  33. 15 Mar, 2009 2 commits
  35. 06 Mar, 2009 1 commit
  37. 18 Feb, 2009 1 commit
  39. 13 Feb, 2009 1 commit
  41. 06 Feb, 2009 1 commit
  43. 14 Jan, 2009 1 commit