Skip to content

GitLab

Switch branch/tag
  1. 28 Feb, 2019 1 commit
  3. 04 Feb, 2019 1 commit
    • ManojGuptaBonda's avatar
      Add HEVC 444 support in VDPAU API · 1b468dea
      ManojGuptaBonda 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: default avatarAaron Plattner <aplattner@nvidia.com>
      1b468dea
  5. 20 Nov, 2018 2 commits
    • Aaron Plattner's avatar
      Fix typos from commit 53eeb07f · 52a6ea26
      Aaron Plattner authored 
      
Signed-off-by: default avatarAaron Plattner <aplattner@nvidia.com>
      52a6ea26
    • ManojGuptaBonda's avatar
      Add new frame and field mode chroma types. Add VdpDecoderQueryProfileCapability API · 53eeb07f
      ManojGuptaBonda 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: default avatarManoj Bonda <mbonda@nvidia.com>
Signed-off-by: default avatarAaron Plattner <aplattner@nvidia.com>
      53eeb07f
  7. 15 Sep, 2015 1 commit
  9. 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: default 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: default avatarAaron Plattner <aplattner@nvidia.com>
Reviewed-by: default avatarFlorian Weimer <fweimer@redhat.com>
      d1f9c16b
  13. 27 May, 2015 1 commit
  15. 11 May, 2015 5 commits
  17. 16 Mar, 2015 3 commits
    • Aaron Plattner's avatar
      Bump version to 1.1 · 0962da95
      Aaron Plattner authored 
      
Signed-off-by: default 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: 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
  19. 09 Mar, 2015 1 commit
  21. 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
  23. 19 Dec, 2014 1 commit
  25. 12 Dec, 2014 1 commit
  27. 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
  29. 04 Nov, 2014 6 commits
  31. 29 Oct, 2014 5 commits
  33. 28 Oct, 2014 1 commit
  35. 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
  37. 28 Aug, 2014 1 commit
  39. 19 Jul, 2014 2 commits