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.
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>
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.
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.
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
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.
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.
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>
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.
This mechanism comes from ffmpeg vaapi implementation, where they have
their own quirks.
A specific driver is identified by a substring present in the vendor
string. If that substring is found, a set of bitwise flags are store.
These flags can be accessed through the function
gst_vaapi_display_has_driver_quirks().
The purpose for this first quirks is to disable the put image try for
AMD Gallium driver (see [1]).
1. https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/merge_requests/72
