Age | Commit message (Collapse) | Author | Files | Lines |
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/331>
|
|
When split one frame into fields, the second field should also
copy the reference flags.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/333>
|
|
As far as we know there are no VAAPI drivers supporting FMO, which
migth be used in baseline streams.
This commit is a continuation of
https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/328
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/332>
|
|
From now on always the baseline is going to be treated as constrained without
need of setting a property.
Since the property was added along the development cycle (1.17 / commit
866a9f06) and never released, we assume that it is safe to remove it.
Fixes: #252
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/328>
|
|
This flag is set to true by default in both MediaSDK and FFmpeg-vaapi,
so let's align this plugin with other libraries / softwares.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/329>
|
|
It is more convinience and thread-safe.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/325>
|
|
The function iterates all supported video formats and returns the
formats belong to the specified chroma type.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/315>
|
|
This is continuation of
https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/317
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/324>
|
|
Some headers had duplicated inlined function declaration. This was
for gtkdoc, but now GStreamer uses hotdoc and the internal library
documentation is not generated. So let's remove these extra lines.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/323>
|
|
We store GstVaapiTextureGLX and GstVaapiTextureEGL's private data in
the qdata of miniobject and avoid extending the base texture class.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/317>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/321>
|
|
Since bufferproxy and surface are not referenced circularly, there's
no need to keep, in the buffer proxy, a reference to the GstMemory
where it is held. This patch removes that handling.
|
|
The bufferproxy may reference the surface and the surface may also
reference the bufferproxy, producing a circular reference, which might
lead to serious resource leak problems.
Now make the relationship clearer, the bufferproxy's references is
transfered to surface, while bufferproxy just keeps the surface's
address without increasing its reference count.
The surface can be created through a bufferproxy like in
gst_vaapi_surface_new_with_dma_buf_handle(), and the surface might
get its bufferproxy via gst_vaapi_surface_get_dma_buf_handle(). In
both cases the surface holds a bufferproxy's reference.
|
|
|
|
Add support for HDR10 tone mapping (since VA-API 1.4.0).
|
|
Using Y410 as the input of the encoder can generate main_444_10 bit
streams.
|
|
|
|
This fixed segfault when running the pipeline below with iHD driver
(commit efe5e9a) on ICL
gst-launch-1.0 videotestsrc ! vaapivp9enc tune=low-power ! vaapivp9dec ! \
fakesink
|
|
|
|
In hevc, we can consider the -intra profile a subset of the none
-intra profile. The -intra profiles just contain I frames and we
definitely can use the none -intra profiles's context to decode
them.
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
|
|
Enable support for ICQ and QVBR bitrate control.
The code is essentially the same for h264 ICQ/QVBR support
which was added in commit 9e0c133a2403.
|
|
This is a workaround for intel-media-driver bug
https://github.com/intel/media-driver/issues/865
The driver will force the RC method to CBR for HEVCe
when it parses the HRD param. Thus, any RC method
param submitted "prior" to the HRD param will be lost.
Therefore, VBR, ICQ and QVBR for HEVCe can't be
effectively enabled if the RC method param "precedes"
the HRD param.
To work around this issue, set the HRD param before
the RC method param so the driver will parse the RC
method param "after" the HRD param.
Afaict, other codecs in the driver (and other drivers)
do not appear to be dependent on the order of HRD and
RC param submission.
|
|
iHD driver shifts the value by 50 when calculating quantization for JPEG
encoding, so we should add 50 in this plugin for iHD driver too.
|
|
GstVaapiPixmap is an abstract base class which only implementation
were GstVaapiPixmapX11. This class were used for a special type of
rendering in the tests apps, utterly unrelated in GStreamer.
Since gstreamer-vaapi is no longer a general-user wrapper for VA-API
we should remove this unused API.
This removal drops libxrender dependency.
|
|
HEVCMain444_10 is already a supported profile and misses the strings.
|
|
|
|
If the dependent_slice_segment_flag is true, most slice info derived from last slice.
So we need check the slice type after we call populate_dependent_slice_hdr
|
|
Since commit 32bf6f1e GLTextureUpload is broken because i965
doesn't report properly RGBA support. It could be possible to use RGBx
but GLTextureUpload only regotiates RGBA.
The simplest fix to this regression is adding synthetically the RGBA
format in the internal format map.
|
|
Instead of break at the fist foud quirk in the table, iterate all over
so it would be feasible to add several quirks for one driver per
element in array.
|
|
The intel-media-driver (iHD) can't convert output color
primaries when doing YUV to/from RGB CSC. Thus, we must
keep the output color primaries the same as the input
color primaries for this case.
fixes #238
|
|
The intel-media-driver (iHD) can't convert output color
primaries when doing YUV to/from RGB CSC.
|
|
When creating surfaces it is possible to pass to VA hints of its usage,
so the driver may do some optimizations.
This commit adds the handling of encoding/decoding hints.
|
|
|
|
Intel HW has limitation on max_transform_hierarchy_depth_inter and
max_transform_hierarchy_depth_intra (see [1]). We can provide a quirk for
other HWs if other HWs may support other values
[1] https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-kbl-vol10-hevc.pdf
|
|
I've just discovered iHD driver in Skylake doesn't have VideoProc
entry point, hence, in this platform, when vaapioverlay is tried to be
registered, critical warnings are raised because blend doesn't have a
display assigned.
As it is possible to have drivers without EntryPointVideoProc it is
required to handle it gracefully. This patch does that: only tries to
register vaapioverlay if the testing display has VPP and finalize()
vmethods, in filter and blend, bail out if display is NULL.
|
|
Older VA-API (0.39.0) doesn't have VAProcColorProperties.
Thus, guard all colorimetry -> VA-API support to version
1.2.0.
Fixes #234
|
|
Commit 1168d6d5 showed up a regression: decode_sps() stores the unit's
parser info in sps array. If that parser info comes from decoding
codec data, that parser info will have an undefined state which might
break ensure_sps().
This patch sets the parser info state, at decoding codec data, with
the internal parser state. This is similar with h264 decoder apprach.
Original-patch-by: Xu Guangxin <guangxin.xu@intel.com>
|
|
Instead of logging in an unspecified category, set the default vaapi.
|
|
Relates to #234
|
|
|
|
All these guarded code seem like leftovers of commit 920b1ec7a. This
patch completes that missing clean up.
|
|
VAProcColorStandardExplicit and associated VAProcColorProperties
(primaries, transfer and matrix) are not supported until
VA-API 1.2.0.
Use VAProcColorStandardNone instead of VAProcColorStandardExplicit
if VA-API < 1.2.0.
Fixes #231
|
|
Addresses #228 on iHD side. It seems iHD can't handle
VAProcColorStandardSRGB in all situations for vpp. But
it has no problem when we specify the sRGB parameters
via VAProcColorStandardExplicit parameters.
|
|
We've always sent VA_SOURCE_RANGE_UNKNOWN to the driver.
And, the [iHD] driver essentially computes the same color
range as gstreamer when we send VA_SOURCE_RANGE_UNKNOWN for
cases were gstreamer computes it automatically. But,
if the user wants to make it explicit, we should try
to honor it.
|
|
|
|
Add API function to allow setting the input and output vpp
color standard from GstVideoColorimetry.
|
|
Fallback to VAProcColorStandardExplicit if there is no
1:1 mapping.
|
|
The i965 does not properly report supported vpp color
standards.
|
|
This is useful while asking for logs to know the used driver.
|
|
Initialize VASurfaceAttribExternalBuffers using compiler's syntax
rather than using memset().
|