The support for buffer exports in VA-API was added in version 0.36. These
interfaces are for interop with EGL, OpenCL, etc.
GStreamer-VAAPI uses it for a dmabuf memory allocator. Though, gstreamer-vaapi
has to support VA-API versions ranging from 0.30.4, which doesn't support it.
This patch guards all the buffer exports handling (and dmabuf allocator) if
the detected VA-API version is below 0.36.
https://bugzilla.gnome.org/show_bug.cgi?id=746405
The member size in GstMpeg4Packet is gsize which is unsigned, which cannot be
less than zero. Hence this pre-condition test is a no-op. This patch removes
that code.
https://bugzilla.gnome.org/show_bug.cgi?id=747312
slice_type in slice_param is defined as (char *), but it is compared against a
signed integer. clang complains about this comparison.
This patch casts the variable.
https://bugzilla.gnome.org/show_bug.cgi?id=747312
The symbol GstVaapiCodedBuffer is already defined in
gst-libs/gst/vaapi/gstvaapicodedbuffer.h which is loaded, at the end, by
gstvaapiencoder_objects.h. Clang complains about the symbol re-definition.
This patch removes that redefinition.
https://bugzilla.gnome.org/show_bug.cgi?id=747312
The member value in frame_rate_tab is float, the result of the abs() function
should be float too. But abs() only manages integers.
This patch replaces abs() with fabsf() to handle correctly the possible floats
values.
https://bugzilla.gnome.org/show_bug.cgi?id=747312
The purpose of gstcompat.h is to couple the API differences among
gstreamer-1.0 and gstreamer-0.10. Since gstreamer-0.10 is obsolete, the code
in this compatibility layer shall be removed.
Nevertheless, the gstcompat.h header should be kept, if new incompatibilites
appear in the future, but it shall live in gst/vaapi, not in gst-libs.
This patch removes the crumbs defined gstcompat.h and moves it to gst/vaapi.
In order to avoid layer violations, gstcompat.h includes sysdeps.h and all
the includes in gst/vaapi of sysdeps.h are replaced with gstcompat.h
https://bugzilla.gnome.org/show_bug.cgi?id=745728
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
This library was intended to add the base classes for video decoders which
where not included in gstreamer-0.10.
Since the support of gstreamer-0.10 is deprecated those classes are not
required, thus the whole library is removed.
https://bugzilla.gnome.org/show_bug.cgi?id=745728https://bugzilla.gnome.org/show_bug.cgi?id=732666
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
This patch only removes the support of gstreamer-0.10 in the autotools
scripts. No other files are touched.
The configuration parameter --gstreamer-api was deleted since now it is always
auto-detected.
The verification of vmethod query in GstBaseSinkClass was removed since it was
added in gstreamer 0.10.35. The same case for GstVideoOverlayComposition and
its format flags.
The precious variable GST_PLUGIN_PATH was removed, while GST_PLUGIN_PATH_1_0
remained.
The automake files were changed accordingly.
Removed, in debian/control, the vaapiupload and vaapidownload descriptions.
https://bugzilla.gnome.org/show_bug.cgi?id=732666https://bugzilla.gnome.org/show_bug.cgi?id=745728
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Add support for H.264 MVC Multiview High profile encoding with
more than 2 views. All views within the same accesss unit are
provided in increasing order of view order index (VOIdx).
Upto 10 view are supported for now.
A new property "view-ids" has been provided for the plugins to
set the view ids (which is an array of guint values) to be used
for mvc encoding.
https://bugzilla.gnome.org/show_bug.cgi?id=732453
Add support for GstVideoGLTextureOrientation modes. In particular,
add orientation flags to the GstVaapiTexture wrapper and the GLX
implementations. Default mode is that texture memory is laid out
with top lines first, left row first. Flags indicate whether the
X or Y axis need to be inverted.
Add GstVaapiTextureEGL abstraction that can create its own GL texture,
or import a foreign allocated one, while still allowing updates from a
VA surface.
Add helpers to import EGLImage objects into VA surfaces. There are
two operational modes: (i) gst_vaapi_surface_new_from_egl_image(),
which allows for implicit conversion from EGLImage to a VA surface
in native video format, and (ii) gst_vaapi_surface_new_with_egl_image(),
which exactly wraps the source EGLImage, typically in RGBA format
with linear storage.
Note: in case of (i), the EGLImage can be disposed right after the
VA surface creation call, unlike in (ii) where the user shall ensure
that the EGLImage is live until the associated VA surface is no longer
needed.
https://bugzilla.gnome.org/show_bug.cgi?id=743847
Add initial support for EGL to libgstvaapi core library. The target
display server and the desired OpenGL API can be programmatically
selected at run-time.
A comprehensive set of EGL utilities are provided to support those
dynamic selection needs, but also most importantly to ensure that
the GL command stream is executed from within a single thread.
https://bugzilla.gnome.org/show_bug.cgi?id=743846
Added rounding control handling for VC1 simple and Main profile
based on VC1 standard spec: section 8.3.7
https://bugzilla.gnome.org/show_bug.cgi?id=743958
Signed-off-by: Lim Siew Hoon <siew.hoon.lim@intel.com>
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
Practically we should be able to support more formats, for eg:
JPEG Encoder can support YUV422, RGBA and all.
But this is causing more issues which need proper fix here and there.
Otherwise the condition could become true before the lock
is taken and the g_cond_signal() could be called
before the g_cond_wait(), so the g_cond_wait() is never
awoken.
https://bugzilla.gnome.org/show_bug.cgi?id=740645
Add support for GEM buffer imports. This is useful for VA/EGL interop
with legacy Mesa implementations, or when it is desired or required to
support outbound textures for instance.
https://bugzilla.gnome.org/show_bug.cgi?id=736718
Add new gst_vaapi_surface_new_with_dma_buf_handle() helper function
to allow for creating VA surfaces from a foreign DRM PRIME fd. The
resulting VA surface owns the supplied buffer handle.
https://bugzilla.gnome.org/show_bug.cgi?id=735362
Add gst_vaapi_surface_new_from_buffer_proxy() helper function to
create a VA surface from an external buffer provided throug the
new GstVaapiBufferProxy object.
Add support for GEM buffer exports. This will only work with VA drivers
based off libdrm, e.g. the Intel HD Graphics VA driver. This is needed
to support interop with EGL and the "Desktop" GL specification. Indeed,
the EXT_image_dma_buf_import extension is not going to be supported in
Desktop GL, due to the lack of support for GL_TEXTURE_EXTERNAL_OES targets
there.
This is useful for implementing VA/EGL interop with legacy Mesa stacks,
in Desktop OpenGL context.
https://bugzilla.gnome.org/show_bug.cgi?id=736717
Use the new VA buffer export APIs to allow for a VA surface to be
exposed as a plain PRIME fd. This is in view to simplifying interop
with EGL or OpenCL for instance.
https://bugzilla.gnome.org/show_bug.cgi?id=735364
The VA buffer export APIs work for a particular lifetime starting from
vaAcquireBufferHandle() and ending with vaReleaseBufferHandle(). As such,
it could be much more convenient to support implicit releases by simply
having a refcount reaching zero.
https://bugzilla.gnome.org/show_bug.cgi?id=736721
