- 15 Sep, 2015 1 commit
-
-
José Hiram Soltren authored
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>
-
- 08 Sep, 2015 2 commits
-
-
Aaron Plattner authored
Otherwise, GCC generates a "‘getenv_wrapper’ defined but not used" warning. Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
-
Rico Tzschichholz authored
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>
-
- 31 Aug, 2015 2 commits
-
-
Aaron Plattner authored
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
-
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: Aaron Plattner <aplattner@nvidia.com> Reviewed-by: Florian Weimer <fweimer@redhat.com>
-
- 27 May, 2015 1 commit
-
-
Bibhuti Prusty authored
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>
-
- 11 May, 2015 5 commits
-
-
José Hiram Soltren authored
Signed-off-by: Aaron Plattner <aplattner@nvidia.com> Reviewed-by: Robert Morell <rmorell@nvidia.com>
-
Emil Velikov authored
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>
-
Emil Velikov authored
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>
-
Emil Velikov authored
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>
-
Aaron Plattner authored
PDF documentation isn't enabled, so pdflatex isn't used. Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
-
- 16 Mar, 2015 3 commits
-
-
Aaron Plattner authored
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
-
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 <aplattner@nvidia.com> Reviewed-by: José Hiram Soltren <jsoltren@nvidia.com>
-
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: Aaron Plattner <aplattner@nvidia.com> Acked-by: Aaron Plattner <aplattner@nvidia.com>
-
- 09 Mar, 2015 1 commit
-
-
Aaron Plattner authored
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
-
- 09 Feb, 2015 2 commits
-
-
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 <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>
-
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: Aaron Plattner <aplattner@nvidia.com> Reviewed-by: Aaron Plattner <aplattner@nvidia.com> Acked-by: Christian König <christian.koenig@amd.com>
-
- 19 Dec, 2014 1 commit
-
-
Aaron Plattner authored
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
-
- 12 Dec, 2014 1 commit
-
-
Karthikeyan Sreenivasan authored
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>
-
- 09 Dec, 2014 1 commit
-
-
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: Aaron Plattner <aplattner@nvidia.com> Reviewed-by: Christian König <christian.koenig@amd.com>
-
- 04 Nov, 2014 6 commits
-
-
Rémi Denis-Courmont authored
The wrapper, as it's currently written, cannot cope with more than one VdpGetProcAddress implementation. Luckily, this should hardly ever happen. This patch protects access to the _imp_get_proc_address variable to conform to the memory model, and ensures that a single VDPAU implementation is used - failing safe if not so. Reviewed-by: Aaron Plattner <aplattner@nvidia.com> Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
-
Rémi Denis-Courmont authored
Reviewed-by: Aaron Plattner <aplattner@nvidia.com> Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
-
Rémi Denis-Courmont authored
Reviewed-by: Aaron Plattner <aplattner@nvidia.com> Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
-
Rémi Denis-Courmont authored
Reviewed-by: Aaron Plattner <aplattner@nvidia.com> Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
-
Rémi Denis-Courmont authored
Signed-off-by: Rémi Denis-Courmont <remid@nvidia.com> Reviewed-by: José Hiram Soltren <jsoltren@nvidia.com> Reviewed-by: Aaron Plattner <aplattner@nvidia.com> Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
-
Rémi Denis-Courmont authored
Signed-off-by: Rémi Denis-Courmont <remid@nvidia.com> Reviewed-by: José Hiram Soltren <jsoltren@nvidia.com> Reviewed-by: Aaron Plattner <aplattner@nvidia.com> Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
-
- 29 Oct, 2014 5 commits
-
-
Rémi Denis-Courmont authored
Signed-off-by: Rémi Denis-Courmont <remid@nvidia.com> Reviewed-by: Aaron Plattner <aplattner@nvidia.com> Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
-
Rémi Denis-Courmont authored
Signed-off-by: Rémi Denis-Courmont <remid@nvidia.com> Reviewed-by: Aaron Plattner <aplattner@nvidia.com> Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
-
Rémi Denis-Courmont authored
Signed-off-by: Rémi Denis-Courmont <remid@nvidia.com> Reviewed-by: Aaron Plattner <aplattner@nvidia.com> Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
-
Rémi Denis-Courmont authored
Signed-off-by: Rémi Denis-Courmont <remid@nvidia.com> Reviewed-by: Aaron Plattner <aplattner@nvidia.com> Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
-
Aaron Plattner authored
When this comment was written, it wasn't clear how the library was going to figure out which back-end driver to load. Since then, the wrapper has been updated to make DRI2 that "VDPAU-specific X extension." Signed-off-by: Aaron Plattner <aplattner@nvidia.com> Reviewed-by: José Hiram Soltren <jsoltren@nvidia.com>
-
- 28 Oct, 2014 1 commit
-
-
José Hiram Soltren authored
Signed-off-by: José Hiram Soltren <jsoltren@nvidia.com> Reviewed-by: Aaron Plattner <aplattner@nvidia.com> Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
-
- 09 Sep, 2014 1 commit
-
-
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: Robert Morell <rmorell@nvidia.com> Reviewed-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
-
- 28 Aug, 2014 1 commit
-
-
José Hiram Soltren authored
(version 2, supercedes "Clarify type of source_surface") VDPAU takes special action if source_surface is VDP_INVALID_HANDLE, not if it is NULL, in both VdpOutputSurfaceRenderOutputSurface and VdpOutputSurfaceRenderBitmapSurface. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
-
- 19 Jul, 2014 2 commits
-
-
Emil Velikov authored
Neither one is part of the public API, thus should never be used outside of the library itself. Add macro PRIVATE, that is used to annotate the function visibility by setting __attribute__((visibility("hidden"))). v2: Provide only PRIVATE macro. Requested by Aaron. 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>
-
Emil Velikov authored
The following three were never a part of the public API and as such should have never been exported by libvdpau_trace.so Correct that by marking them as static, thus allowing the compiler to hide them from the exported namespace. _vdp_cap_init_planes_adapt_surface_video _vdp_cap_init_planes_adapt_surface_bitmap _vdp_cap_init_planes_adapt_surface_output 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>
-
- 01 Jul, 2014 1 commit
-
-
Aaron Plattner authored
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
-
- 31 May, 2014 1 commit
-
-
Emil Velikov authored
Allow the user to specify the location of the backend driver, via the VDPAU_DRIVER_PATH environment variable. This allows easier testing of VDPAU backends without the need to rebuild libvdpau. Inspired by LIBGL_DRIVERS_PATH from mesa. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Acked-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Aaron Plattner <aplattner@nvidia.com> Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
-
- 20 Feb, 2014 1 commit
-
-
Reimar Döffinger authored
VdpPictureInfo should not be a pointer, otherwise the VdpDecoderRender function signature asks for a pointer to a pointer. But it really does expect a pointer directly to e.g. VdpPictureInfoH264. Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de> Tested-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
-
- 28 Jan, 2014 1 commit
-
-
Emil Velikov authored
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>
-