This is, practically, a revert of commit dcf135e2.
The parent logic is useful for the EGL display, which is a decorator
of the real windowing subsystem (X11 or Wayland). Thus it is avoided
calling vaInitialize() and vaTerminate() twice.
https://bugzilla.gnome.org/show_bug.cgi?id=795391
gst_vaapi_display_egl_new_with_native_display() has been broken since
it wasn't used.
Currently it's needed to call this API to create a display providing
the EGL display, so it could avoid duplicated calls to the native
display (eg. eglTerminate).
Signed-off-by: Victor Jaquez <vjaquez@igalia.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795391
This change is due a problem decoding JPEGs with Intel's media-driver:
no image was generated.
This patch relases the VA buffers after vaEndPicture() is called,
and not before (after vaRenderPicture()).
https://bugzilla.gnome.org/show_bug.cgi?id=796505
The commit 67e33d3de2 ("vaapiencode: h264:
find best profile in those available") changed the code to pick a profile
that is actually supported by the hardware. Unfortunately it dropped the
downstream constraints. This can cause negotiation failures under certain
circumstances.
The fix is split in two cases:
1\ the available VA-API caps doesn't intersect with pipeline's allowed
caps:
* The best allowed profile (pipeline's caps) is set as the encoding
target profile (it will be adjusted later by the available profiles
and properties)
2\ the available VA-API caps does intersect with pipeline's allowed
caps:
* The intersected caps are fixed, and its profile is set as the
encoding target profile. In this case the is not the best profile,
but the minimal one (if VA-API reports the profiles in order).
Setting the minimal profile of the intersected caps is better for
compatibility.
This patch fixes other tests related with caps negotiation, for
example, it handles baseline profile, even when VA only supports
constrained-baseline.
Original-patch-by: Michael Olbrich <m.olbrich@pengutronix.de>
https://bugzilla.gnome.org/show_bug.cgi?id=794306
The specification says,
"log2_max_pic_order_cnt_lsb_minus4 shall be in the range of 0 to 12, inclusive."
This patch changes the upper limit from 6 to 12.
https://bugzilla.gnome.org/show_bug.cgi?id=796179
Instead of using our own context handling for looking for GstGL
parameters (display, context and other context), this patch changes
the logic to use the utility function offered by GstGL.
https://bugzilla.gnome.org/show_bug.cgi?id=793643
The parameters of gst_gl_ensure_element_data() have to be not
local variable since they are going to be used to see if they're
set in gst_element_set_context() inside the API.
This is basically a revert of commit 3d56306chttps://bugzilla.gnome.org/show_bug.cgi?id=793643
This removes hard-coded checks on the parent subsystem of potential DRM
devices. These checks were set to exlude devices that do not originate
from the PCI bus, which is only a valid approach on x86 devices.
Other devices may have a DRM device originating from the platform
subsystem, so the checks that were previously restricted to PCI are
extended to cover platform devices as well.
https://bugzilla.gnome.org/show_bug.cgi?id=794840
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Through "gst.vaapi.app.Display" context, users can set their own
VADisplay and native display of their backend.
So far we support only X11 display, from now we also support Wayland
display.
Attributes:
- wl-display : pointer of struct wl_display .
https://bugzilla.gnome.org/show_bug.cgi?id=705821
Otherwise the following poll may not return for an arbitrary amount of
time. This can happen if another wayland event queue has flushed and read
our events.
https://bugzilla.gnome.org/show_bug.cgi?id=795224
pic_width_in_luma_samples/pic_height_in_luma_samples can be 16-bit rounded
instead of 32-bit.
In addition, codedbuf_size must be calculated according to this change.
https://bugzilla.gnome.org/show_bug.cgi?id=753229
Instead to look for the best profile in the allowed profiles by
downstream, the encoder should look for the base profile in the
available profile in VA-API.
https://bugzilla.gnome.org/show_bug.cgi?id=794306
Even if it is the h264parse fault or bad video file, vaapih264dec
should set a proper value for VAPictureParameterBufferH264.num_ref_frames
as the driver might use it.
Also see "info.ref_frames = dpb_size;" in
gstvaapidecoder_h264.c::ensure_context
https://bugzilla.gnome.org/show_bug.cgi?id=793836
Instead of copying the metada in prepare_output_buffer() vmethod,
it is done in append_output_buffer_metadata() thus deinterlaced
buffers could also have the proper metas.
GstVideoCropMeta now it is copied internally and it is decided via
transform_meta() vmethod.
A new internal method, copy_metadata() was added to handle VPP
transformation where non-GstVideoVaapiMeta metas were lost.
Rewrote the ROI test to use GstVideoRegionOfInterest meta rather
than injecting GstEvents. These meta are added as a pad probe in
the queue src pad.
Also
* Use of navigation messages to control de test
* Use signal watch for processing messages
* Change to H265 rather than H264 since current intel-vaapi-driver
only supports ROI on kabylake.
TODO: add a parameter to change the encoder/decoder to test.
https://bugzilla.gnome.org/show_bug.cgi?id=768248
Check input buffers for ROI metas and pass them to VA. Also added a
new "default-roi-delta-qp" property in order to tell the encoder what
delta QP should be applied to ROI by default.
Enabled it for H264 and H265 encoders.
https://bugzilla.gnome.org/show_bug.cgi?id=768248
When importing buffers to a VA-base buffer, it is required to copy
the metas in the original buffer, otherwise information will be
lost, such as GstVideoRegionOfInterestMeta.
https://bugzilla.gnome.org/show_bug.cgi?id=768248
According to Debian package auto-building, uintptr_t is not an
unsigned long in i386 arch, raising an "incompatible pointer type"
error.
This patch adds a casting for compiler's satisfaction in i386.
