Split the funcion context_create() into context_create() and
config_create().
Decoupling VAConfig and VAContext during context creation, we could
query the VAConfig for the supported surface's formats without creating
a VAContext.
https://bugzilla.gnome.org/show_bug.cgi?id=769266
Originally the drm backend only tried to open the first render node
found. But in hybrid system this first render node might not support
VA-API (propietary Nvidia driver, for example).
This patch tries all the available nodes until a finding one with a
VA-API supported driver.
https://bugzilla.gnome.org/show_bug.cgi?id=774811
Original-patch-by: Stirling Westrup <swestrup@gmail.com> and
Reza Razavi <reza@userful.com>
In case libva-wayland has its headers not installed in default
locations (like /usr/include), the build fails to include "wayland-client.h":
CC libgstvaapi_egl_la-gstvaapiutils_egl.lo
In file included from gstvaapidisplay_wayland.h:27:0,
from gstvaapidisplay_egl.c:35:
/usr/include/va/va_wayland.h:31:28: fatal error: wayland-client.h: No such file or directory
#include <wayland-client.h>
As we already passed VA_CLAGS, /usr/include/va/va_wayland.h could be found, but it is
our fault not to instruct the system that we ALSO care for va_wayland. We correctly query
for libva-wayland.pc in configure and use this in other places as well. It is thus only
correct and consequent, to do it also at this spot.
https://bugzilla.gnome.org/show_bug.cgi?id=773946
This patch ensures to get the formats, as filter does, available in the
decoder / encoder context.
The context fills up the array as soon it is created, otherwise the pipeline
could get stalled (perhaps this is a bug in my HSW backend).
https://bugzilla.gnome.org/show_bug.cgi?id=752958
The query of all the supported formats for a VA config were only used by the
postprocessor (vaapifilter). But, in order to enable the vaapidecoder to
negotiate a suitable raw format with downstream, we need to query these
formats against the decoder's config.
This patch is the first step: moves the code in filter's ensure_image() to a
generic gst_vaapi_get_surface_formats() in vaapiutils_core, so it can be
shared later by the decoder.
https://bugzilla.gnome.org/show_bug.cgi?id=752958
When creating a GstVaapiWindowEGL, it also creates native window by its own
native display. It should pass the native display, either X11 or Wayland.
https://bugzilla.gnome.org/show_bug.cgi?id=768266
This patch is to change the inheritance of GstVaapiDisplay to GstObject,
instead of GstVaapiMiniObject. In this way we can use all the available
infrastructure for GObject/GstObject such as GstTracer, GIR, etc.
In addition, a new debug category for GstVaapiDisplay is created to make it
easier to trace debug messages. It is named "vaapidisplay" and it transverse
all the VA display backends (DRM, GLX, EGL, Wayland, ...)
This patch is a step forward to expose GstVaapiDisplay for users in a future
library.
https://bugzilla.gnome.org/show_bug.cgi?id=768266
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
GstVaapiDecode is a descendant of GstVaapiMiniObject, so, thought we should
use its methods, even though it doesn't change functionality.
GstVaapiPixmap, GstVaapiTexture and GstVaapiWindow are descendant of
GstVaapiObject, hence its methods shall be used.
https://bugzilla.gnome.org/show_bug.cgi?id=772554
instances when created and reuse
This patch improves performance when glimagesink uploads a GL texture.
It caches the GStVaapiTexture instances in GstVaapiDisplay{GLX,EGL}, using an
instance of GstVaapiTextureMap, so our internal texture structure can be found
by matching the GL texture id for each frame upload process, avoiding the
internal texture structure creation and its following destruction.
https://bugzilla.gnome.org/show_bug.cgi?id=769293
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Implement GstVaapiTextureMap object, which caches VAAPI textures, so them can be
reused. Internally it is a hash table.
Note that it is GstObject based rather than GstVaapiObject, as part of the future
converstion to GstObject of most of the code.
https://bugzilla.gnome.org/show_bug.cgi?id=769293
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
We are not getting enough compression for some streams and
encoded frame end up with more size than allocated.
Assuming a compression ratio of 4, which should be good enough
for holding the frames.
https://bugzilla.gnome.org/show_bug.cgi?id=771528
While doing the mode-1 referece picture selection,
the circular buffer logic was not correctly setting the
refresh frame flags as per VP9 spec.
Make sure refresh_flag[0] get updated correclty after
each cycle of GST_VP9_REF_FRAMES.
https://bugzilla.gnome.org/show_bug.cgi?id=771507
When the format of a H.264 stream is AVC3, the SPS and PPS are inside the
stream, not in the codec_data, so the size of codec_data might be 7.
This patch reduces the minimal size of the codec_data buffer from 8 to 7.
https://bugzilla.gnome.org/show_bug.cgi?id=771441
In commit 2eb4394 the frame coding mode was verified for progressive
regardless the profile. But the FCM is only valid in the advanced
profile. This patch checks for the advanced profile before verifying FCM for
progressive.
https://bugzilla.gnome.org/show_bug.cgi?id=769250
In the earlier patch:
f31d9f3 decoder: vc1: Print error on interlaced content
Decoding would error out if the interlace flag was set in the
sequence bdu. This isn't quite right because a video can have this
flag set and yet not have any interlaced pictures.
Here instead we error out when either parsing a field bdu or
decoding a frame bdu which has fcm set to anything other than
progressive.
Signed-off-by: Scott D Phillips <scott.d.phillips@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=769250
Validate that fps numerator is non-zero so it can be used to calculate
the duration of the B frame.
Also it gst_util_uint64_scale() is used instead of normal arithmetic in
order to aviod overflows, underflows and loss of precision.
https://bugzilla.gnome.org/show_bug.cgi?id=768458
Since the upstream of gstreamer-vaapi, the library is not a public shared
object anymore. But the EGL support depended on this dynamic library, so the
EGL support was broken.
This patch removes the dynamic library loading code and instantiates the
EGL display using either X11 or Wayland if available.
https://bugzilla.gnome.org/show_bug.cgi?id=767203
This reverts commit 1dbcc8a0e1 and commit
372a03a9e3.
While the dmabuf handle is exported, the derive image must exist, otherwise
the image's VA buffer is invalid, thus the dmabuf handle is never released,
leading into a file descriptors leak.
A planar(or some other) buffer allocation may fail on the driver, then
the wayland connection becomes invalid, not able to send request or
receive any event. So we need to set up a new wayland connection if
there's an error detected on the cached wl_display.
https://bugzilla.gnome.org/show_bug.cgi?id=768761
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Change defaults for max-bframes, cabac, and dct8x8 to be enabled
by default. This will cause the default profile to be high instead
of baseline. In most situations this is the right decision, and
the profile can still be lowered in the case of caps restrictions.
Signed-off-by: Scott D Phillips <scott.d.phillips@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757941
Without this, all dpb pictures are not released during flush,
because we used the global dpb_count variable for checking the
dpb fullness which get decremented in dpb_remove_index()
routine during each loop iteration.
https://bugzilla.gnome.org/show_bug.cgi?id=767934
Clarify that vaapi context resets are never needed for vp9, but
that ensure_context() needs called when the size increases so that
new surfaces can be allocated.
Signed-off-by: Scott D Phillips <scott.d.phillips@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=767474
Added two modes(as properties) for reference picture selection:
ref-mode-0: AltRef and GoldRef pointing to the recent keyframe
and LastRef is pointing to the previous frame.
ref-mode-1: Previous frame (n) as LastRef , n-1 th frame as GoldRef
and n-2 th frame as AltRef
https://bugzilla.gnome.org/show_bug.cgi?id=766048
gst_video_info_set_format() and gst_video_info_from_caps() call, internally,
gst_video_info_init(), hence it is not required to call it before them. This
patch removes these spurious calls.
This is a workaround since vaapi-intel-driver doesn't have
support for B-frame encode when utilizing low-power-enc
hardware block.
Fixme :We should query the VAConfigAttribEncMaxRefFrames
instead of blindly disabling b-frame support and set b/p frame count,
buffer pool size etc based on the query result.
https://bugzilla.gnome.org/show_bug.cgi?id=766050
Added a new property "low-power-enc" for enabling low power
encoding mode. Certain encoding tools may not be available
with the VAEntrypointEncSliceLP.
https://bugzilla.gnome.org/show_bug.cgi?id=766050
Call gst_vaapi_video_pool_finalize() in coded_buffer_pool_finalize().
Otherwise it is not called when the pool is destroyed and all objects
referenced by the GstVaapiVideoPool are never released.
https://bugzilla.gnome.org/show_bug.cgi?id=764993
If gst_vaapi_image_new_with_image() fails, the created derived image should be
destroyed, otherwise the surface cannot be processed because is being used.
https://bugzilla.gnome.org/show_bug.cgi?id=764607
The subsampling_x, subsampling_y, bit_depth, color_space and color_range
fileds are moved from GstVp9FrameHdr to the global GstVp9Parser structure.
These fields are only present in keyframe or intra-only frame, no need to
duplicate them for inter-frames.
https://bugzilla.gnome.org/show_bug.cgi?id=764082
The array_completeness, reserved bit and num_nal_units fields
in HEVCDecoderConfigurationRecord will be present for each VPS/SPS/PPS array list,
but not for each occurance of similar headers.
https://bugzilla.gnome.org/show_bug.cgi?id=764274
The P010 video format is the native format used by the vaapi intel driver
for HEVCMain10 decode . Add support for planes and images of this video format.
https://bugzilla.gnome.org/show_bug.cgi?id=759181
The colour depth is clamped to 24 when it is not equal {15,16,24,32}. But this
fails with the NVIDIA binary driver as it doesn't advertise a TrueColor visual
with a depth of 24 (only 30 and 32). Allowing the depth to be 30, lets everything
work as expected.
https://bugzilla.gnome.org/show_bug.cgi?id=764256
Copy the data into the dependent slice segment header from the
corresponding independent slice segment header during parsing.
Previously the reference to the "previous" independent header was
held through the parsing phase and then dereferenced during the
decoding phase. This caused all dependent headers to be populated
with the data of the AU's last independent header instead of the
proper corresponding header.
https://bugzilla.gnome.org/show_bug.cgi?id=762352
Changes since v1:
- Reworded commit message
gst_vaapi_buffer_proxy_{acquire_handle,release_handle,finalize,class}
functions are used only when libva's API version is greater than 0.36.0
This patch guards those functions completely rather than just their
content. The patch is a continuation of commit 38f8fea4
Original-patch-by: Vineeth TM <vineeth.tm@samsung.com>
https://bugzilla.gnome.org/show_bug.cgi?id=762055
After setting the release flags, the compiler warns about a couple
initialized variables.
Also marked a couple of set variables as unused, because they are only
used for assertion.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
As part of the upstreaming process of gstreamer-vaapi into the GStreamer
umbrella, we need to comply with the project's code style. This meant to
change a lot of code.
It was decided to use a single massive patch to update the code style.
I would like to apologize with the original developers of this code because of
the history breakage.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
As gst-indent generated ugly code in these cases, this patch changes the used
idiomatic into other one.
No functional changes were introduced.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Somehow this didn't show up earlier, but gst_adapter_prev_timestamp() got
deprecated since GStreamer 1.0.
This patch replace it with gst_adapter_prev_pts()
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
This a very pathological situation: when we have a HEVC encoder but not a HEVC
decoder.
The encoder needs functions that are only available when the decoder is
enabled.
This patch moves the utils functions into the generic sources, such as the
rest of the utils.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
As gstreamer-vaapi now only supports from GStreamer 1.6, this patch removes
all the old GStreamer version guards.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Since we don't install libraries anymore, it makes no sense to keep
versioning them according to the gstreamer's version.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
This basically reverts 62c3888b76 (wayland:
decouple wl_buffer from frame).
Otherwise the frame may be overwritten while it is still used by the
compositer:
The frame done callback (frame_done_callback()) is called, when the
compositor is done processing the frame and hands it to the hardware.
The buffer release callback (frame_release_callback()) is called when the
buffer memory is no longer used.
This can be quite some time later: E.g. if weston (with the DRM backend)
puts the buffer on a hardware plane, then then buffer release callback is
called when the kernel is done with the buffer. This is usually when the
next frame is shown, so most likely after the frame done callback for the
next frame!
Since 70eff01d36 "wayland: sync() when
destroy()" the mentioned possible leak should no longer be a problem, so
reverting this change should cause no leaking buffers.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=758848
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Only supporting vaapidecode ! vaapisink combination for now.
Missing dependencies:
1: No support for P010 video format in GStreamer
2: No support for P010 vaGetImage()/vaPutimage() in vaapi-intel-driver
3: As a result of 1&2 , we have no support for Vaapi Video memory mapping
through GstVideoMeta.
Right now we only set chroma format (YUV420 with more than 8 bits per channel)
for surface pool and keeping GST_VIDEO_FORMAT as ENCODED. The underlying format
of the surfaces is implementation (driver) defined, which is P010.
This new API gst_vaapi_surface_pool_new_with_chroma_type() is for
creating a new GstVaapiVideoPool of GstVaapiSurfaces with the specified
chroam type and dimensions. The underlying format of the surfaces is
implementation (driver) defined.
