GitLab

Signed-off-by: ManojGuptaBonda <mbonda@nvidia.com>

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,
etc.
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.

Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

Reviewed-by: Aaron Plattner <aplattner@nvidia.com>

Fixing this imbalance doesn't cause any major changes to the generated
documentation.

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.]

to

 * Core API
   * Basic Types
   * Miscellaneous Types
   * Error Handling
   * [etc.]

Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

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.

Enable -Werror by setting -Dwerror=true on the Meson command line.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

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 <aplattner@nvidia.com>

Update the CI build environment to install doxygen and graphviz. Deploy the
generated documentation as pages.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

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 <aplattner@nvidia.com>

Build-time timestamps in the Doxygen docs make the build unreproducible.
Signed-off-by: Luca Boccassi <bluca@debian.org>

This builds libvdpau and runs the tests, although the only test at the moment is
dlclose and it is skipped because there is no X server running in the Docker
environment.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

Modify the dlclose test to pick up libvdpau.so from the right place

Rename doc/Doxyfile to doc/Doxyfile.in and use Meson's configuration file
support to generate the Doxyfile.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

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 <aplattner@nvidia.com>

Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

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: Manoj Bonda <mbonda@nvidia.com>
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

VdpVideoSurface is not directly displayable in the current
implementation of VDPAU. VdpOutputSurface is. Make the documentation
consistent with reality.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

Otherwise, GCC generates a "‘getenv_wrapper’ defined but not used" warning.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

Fix build with -Wimplicit-function-declaration while secure_getenv() is
guarded by __USE_GNU.
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Tested-by: Stefan Dirsch <sndirsch@suse.de>

Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

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 <aplattner@nvidia.com>
Reviewed-by: Florian Weimer <fweimer@redhat.com>

Signed-off-by: Bibhuti Bhushan Prusty <bprusty@nvidia.com>
Reviewed-by: José Hiram Soltren <jsoltren@nvidia.com>
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Robert Morell <rmorell@nvidia.com>

This commit addresses three concerns:
 - Places quotes around variables. Otherwise things will fail badly if
either one of then contains space.
 - Adds --force to autoreconf, which will ensure that the build is
regenerated, if one updates autotools.
 - Honours the NOCONFIGURE variable, which is set by gnome-continuous
(iirc).
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

Using this macro can lead to various security issues, as pointed out in
the automake manual. Follow the example set by most X components and
remove it from the build.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

Yet another artefact from the autotools buildsystem.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

PDF documentation isn't enabled, so pdflatex isn't used.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

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 <aplattner@nvidia.com>
Reviewed-by: José Hiram Soltren <jsoltren@nvidia.com>

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 <aplattner@nvidia.com>
Acked-by: Aaron Plattner <aplattner@nvidia.com>

Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

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 <christian.koenig@amd.com>
v2: Rebase on top of José's HEVC work.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: José Hiram Soltren <jsoltren@nvidia.com>

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 <aplattner@nvidia.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Acked-by: Christian König <christian.koenig@amd.com>

Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

The current patch adds a new struct VdpPictureInfoH264Predictive which
contains the necessary fields to support High 444 Predictive Profile.

The patch adds VDP_DECODER_PROFILE_H264_HIGH_444_PREDICTIVE (currently
only with 8 bit depth support). Additional profiles and levels will
be added in a future update.

Videos of VDP_DECODER_PROFILE_H264_HIGH_444_PREDICTIVE profile must use
VdpPictureInfoH264Predictive.

This patch adds lossless decode support to VDPAU API via the
qpprimey_zero_transform_bypass_flag in struct
VdpPictureInfoH264Predictive.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: José Hiram Soltren <jsoltren@nvidia.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Acked-by: Rémi Denis-Courmont <remi@remlab.net>

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 <aplattner@nvidia.com>
Reviewed-by: Christian König <christian.koenig@amd.com>