Skip to content

GitLab

Switch branch/tag
  1. 16 Mar, 2015 1 commit
    • 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
  3. 09 Mar, 2015 1 commit
  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. 19 Dec, 2014 1 commit
  9. 12 Dec, 2014 1 commit
  11. 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
  13. 04 Nov, 2014 6 commits
  15. 29 Oct, 2014 5 commits
  17. 28 Oct, 2014 1 commit
  19. 09 Sep, 2014 1 commit
    • Robert Morell's avatar
      vdpau_trace: Fix GCC 4.8 build warnings · a2386ece
      Robert Morell authored 
      

vdpau_trace.cpp: In function 'void _vdp_cap_dump_video_mixer_attribute_value(VdpVideoMixerAttribute, const void*, bool)':
vdpau_trace.cpp:539:48: error: cast from type 'const void*' to type 'const float (**)[3][4]' casts away qualifiers [-Werror=cast-qual]
                 ptr = *(VdpCSCMatrix const * *)value;
                                                ^
vdpau_trace.cpp: In function 'void _vdp_cap_dump_bitstream_buffer_list(uint32_t, const VdpBitstreamBuffer*)':
vdpau_trace.cpp:1175:52: error: cast from type 'const void* const' to type 'uint8_t* {aka unsigned char*}' casts away qualifiers [-Werror=cast-qual]
             uint8_t * ptr = (uint8_t * )buffers[0].bitstream;
                                                    ^
Signed-off-by: default avatarRobert Morell <rmorell@nvidia.com>
Reviewed-by: default avatarStephen Warren <swarren@nvidia.com>
Signed-off-by: default avatarAaron Plattner <aplattner@nvidia.com>
      a2386ece
  21. 28 Aug, 2014 1 commit
  23. 19 Jul, 2014 2 commits
  25. 01 Jul, 2014 1 commit
  27. 31 May, 2014 1 commit
  29. 20 Feb, 2014 1 commit
  31. 28 Jan, 2014 1 commit
  33. 01 Aug, 2013 3 commits
  35. 26 Jul, 2013 1 commit
  37. 25 Jul, 2013 1 commit
  39. 23 Jul, 2013 1 commit
  41. 02 Feb, 2013 1 commit
  43. 01 Feb, 2013 1 commit
  45. 28 Jan, 2013 1 commit
    • Aaron Plattner's avatar
      test: add a dlclose test · d00042fd
      Aaron Plattner authored 
      Closing an X display that had a VDPAU device created on it causes a crash.

Work around an identical libXext dlclose bug with the "Generic Event Extension"
by dlopening libXext.so.6 and leaving it open.

Original bug discovered and fixed by Robert Morell <rmorell@nvidia.com> in
commit 3b43955c

.

v2: Don't SKIP if creating the device fails.  Just attempting to create the
device installs the DRI2 extension that causes the problem.
Signed-off-by: default avatarAaron Plattner <aplattner@nvidia.com>
Reviewed-by: default avatarRobert Morell <rmorell@nvidia.com>
      d00042fd
  47. 25 Jan, 2013 3 commits
  49. 24 Jan, 2013 1 commit