The decoder was trying to detect earlier that a field was lost base
on guessing the parity order. This breaks in streams were the parity
order changes.
This patch reverts the field order prediction code added by commit
8dd93e9c8.
https://bugzilla.gnome.org/show_bug.cgi?id=796169
This ensure that we always have sentinels set in the reference
pictures arrays. The code wasn't unsafe, this simply improve the
tracing, so instead of printing 32 lines of zeros, va tracer
prints proper empty lists.
https://bugzilla.gnome.org/show_bug.cgi?id=796169
Gobjectification for GstVaapiDisplay was almost done by the commit 185da3d1.
But still something breaking GObject code convention remains, which is
calling gst_vaapi_display_new() in each decendants.
This patch replaces it with gst_vaapi_display_config(), defined in private
header.
https://bugzilla.gnome.org/show_bug.cgi?id=796470
The function name was gst_vaapi_display_create_unlocked(), nonetheless
it wasn't called unlocked. In order to keep the semantics this patch
renames the gst_vaapi_display_create_unlocked() as
gst_vaapi_display_create(), removing the previous function
gst_vaapi_display_create().
https://bugzilla.gnome.org/show_bug.cgi?id=796470
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
