Víctor Manuel Jáquez Leal [Thu, 20 Apr 2017 16:44:41 +0000 (18:44 +0200)]
vaapipostproc: fixes for memory leaks
The use of gst_vaapi_value_set_format() and gst_structure_*_value()
requires to clear the used GValue to avoid a memory leak.
Víctor Manuel Jáquez Leal [Thu, 8 Dec 2016 17:51:54 +0000 (18:51 +0100)]
plugins: enable direct rendering with envvar
Direct rendering (use vaDeriveImage rather than vaPutImage) has better
performance in some Intel platforms (Haswell, for example) but in others
(Skylake) is the opposite.
In order to have some control, the patch enables the direct rendering
through the environment variable GST_VAAPI_ENABLE_DIRECT_RENDERING.
Also it seems to generating some problems with gallium/radeon backend.
See bug #779642.
https://bugzilla.gnome.org/show_bug.cgi?id=775848
Jan Schmidt [Fri, 7 Apr 2017 16:05:21 +0000 (02:05 +1000)]
vaapidecode: Don't renegotiate on every flush
If caps don't actually change, don't update the
decoder and don't set the do_renego flag forcing
downstream renegotiation
https://bugzilla.gnome.org/show_bug.cgi?id=781142
Jan Schmidt [Fri, 7 Apr 2017 15:21:23 +0000 (01:21 +1000)]
h264 decoder: Implement reset() for faster flush
Implement a custom reset() function for faster flushes
that just clear the reference pictures but don't reallocate
the DPB or clear out SPS/PPS
https://bugzilla.gnome.org/show_bug.cgi?id=781142
Jan Schmidt [Wed, 5 Apr 2017 07:24:20 +0000 (17:24 +1000)]
Implement decoder reset on flush, rather than recreating
Clear decoders out on a flush but keep the same instance,
rather than completely recreating them. That avoids
unecessarily freeing and recreating surface pools
and contexts, which can be quite expensive
https://bugzilla.gnome.org/show_bug.cgi?id=781142
Víctor Manuel Jáquez Leal [Tue, 11 Apr 2017 16:50:35 +0000 (18:50 +0200)]
libs: window: don't add an unused function
The macro GST_VAAPI_OBJECT_DEFINE_CLASS_WITH_CODE only defines
a function that is never used, thus when compiling we might see
this warning (clang):
gstvaapiwindow.c:147:1: warning: unused function 'gst_vaapi_window_class' [-Wunused-function]
GST_VAAPI_OBJECT_DEFINE_CLASS_WITH_CODE (GstVaapiWindow,
^
https://bugzilla.gnome.org/show_bug.cgi?id=759533
Víctor Manuel Jáquez Leal [Tue, 11 Apr 2017 16:22:00 +0000 (18:22 +0200)]
libs: window: remove surface_format member
Since we always convert to NV12, there is no need to keep a
variable for that. Let us hard code it.
https://bugzilla.gnome.org/show_bug.cgi?id=759533
Hyunjun Ko [Mon, 10 Apr 2017 08:23:26 +0000 (17:23 +0900)]
libs: window: x11/wayland: use new api for conversion
Since gst_vaapi_window_vpp_convert_internal is created,
GstVaapiWindowX11/Wayland can use it for conversion.
Note that once it chooses to use vpp, it's going to use vpp
until the session is finished.
https://bugzilla.gnome.org/show_bug.cgi?id=759533
Hyunjun Ko [Mon, 10 Apr 2017 02:41:29 +0000 (11:41 +0900)]
libs: window: add gst_vaapi_window_vpp_convert_internal()
If a backend doesn't support specific format, we can use vpp for conversion
and make it playing.
This api is originated from GstVaapiWindowWayland and moved to GstVaapiWindow,
so that GstVaapiWindowX11 could use it.
https://bugzilla.gnome.org/show_bug.cgi?id=759533
Hyunjun Ko [Mon, 3 Apr 2017 07:45:36 +0000 (16:45 +0900)]
libs: window: x11/wayland: chaining up to GstVaapiWindow
Currently, GstVaapiWindowX11/Wayland are not descendants of GstVaapiWindow.
This patch chains them up to GstVaapiWindow to handle common members in GstVaapiWindow.
https://bugzilla.gnome.org/show_bug.cgi?id=759533
Scott D Phillips [Wed, 5 Apr 2017 18:19:15 +0000 (11:19 -0700)]
plugins: Fix usage of GST_GL_HAVE_WINDOW_* defines
When these definitions are false, they are undef in the
preprocessor, not a defined value of 0. When they are unset the
compile fails with:
'GST_GL_HAVE_WINDOW_WAYLAND' undeclared (first use in this function)
https://bugzilla.gnome.org/show_bug.cgi?id=780948
Tim-Philipp Müller [Mon, 10 Apr 2017 22:51:06 +0000 (23:51 +0100)]
Automatic update of common submodule
From 39ac2f5 to 60aeef6
Sebastian Dröge [Fri, 7 Apr 2017 13:36:21 +0000 (16:36 +0300)]
Release 1.11.90
Víctor Manuel Jáquez Leal [Mon, 3 Apr 2017 12:52:41 +0000 (14:52 +0200)]
vaapiencode: h265: add main-10 in caps template
This patch adds h265's main-10 profile in encoder src caps template.
https://bugzilla.gnome.org/show_bug.cgi?id=771291
Víctor Manuel Jáquez Leal [Mon, 3 Apr 2017 13:34:51 +0000 (15:34 +0200)]
libs: encoder: h265: chroma and luma with format
If the profile is main-10 the bit_depth_luma_minus8, in the sequence
parameter buffer, shall be the color format bit depth minus 8, 10-8
which is 2. Also for bit_depth_chroma_minus8.
This patch gets the negotiated sink caps format and queries its
luma's depth and uses that value to fill the mentioned parameters.
https://bugzilla.gnome.org/show_bug.cgi?id=771291
Víctor Manuel Jáquez Leal [Wed, 29 Mar 2017 17:20:26 +0000 (19:20 +0200)]
libs: encoder: admit YUV420_10BPP as valid chroma
Accepts as supported the GST_VAAPI_CHROMA_TYPE_YUV420_10BPP chroma
type.
https://bugzilla.gnome.org/show_bug.cgi?id=771291
Víctor Manuel Jáquez Leal [Wed, 29 Mar 2017 17:16:50 +0000 (19:16 +0200)]
libs: encoder: h265: ensures profile given format
Set the VA profile as GST_VAAPI_PROFILE_H265_MAIN10 if the
configured color format is P010_10LE.
Otherwise, keep GST_VAAPI_PROFILE_H265_MAIN
https://bugzilla.gnome.org/show_bug.cgi?id=771291
Víctor Manuel Jáquez Leal [Thu, 6 Apr 2017 15:21:21 +0000 (17:21 +0200)]
libs: encode: merge all possible surface formats
When the function gst_vaapi_encoder_get_surface_formats() was added
it was under the assumption that any VA profile of the specific codec
supported the same format colors. But it is not, for example the
profiles that support 10bit formats.
In other words, different VA profiles of a same codec may support
different color formats in their upload surfaces.
In order to expose all the possible color formats, if no profile is
specified via source caps, or if the encoder doesn't have yet a
context, all the possible VA profiles for the specific codec are
iterated and their color formats are merged.
https://bugzilla.gnome.org/show_bug.cgi?id=771291
Víctor Manuel Jáquez Leal [Thu, 6 Apr 2017 14:28:12 +0000 (16:28 +0200)]
vaapiencode: add get_profile() vmethod
This new virtual method, get_profile(), if implemented by specific
encoders, will return the VA profile potentially determined by the
source caps.
Also it is implemented by h264 and h265 encoders, which are the main
users of this vmethod.
https://bugzilla.gnome.org/show_bug.cgi?id=771291
Víctor Manuel Jáquez Leal [Thu, 6 Apr 2017 10:49:24 +0000 (12:49 +0200)]
libs: encoder: pass profile to get_surface_formats()
In order to get the supported surface formats within a specific
profile this patch adds the GstVaapiProfile as property to
gst_vaapi_encoder_get_surface_formats().
Currently the extracted formats are only those related with the
default profile of the element's codec.
https://bugzilla.gnome.org/show_bug.cgi?id=771291
Víctor Manuel Jáquez Leal [Thu, 6 Apr 2017 10:28:51 +0000 (12:28 +0200)]
libs: encoder: dummy context for get_surface_formats()
Instead of creating (if it doesn't exist, yet) the encoder's context
the method gst_vaapi_encoder_get_surface_formats() now it creates
dummy contexts, unless the encoder has it already created.
The purpose of this is to avoid setting a encoder's context with a
wrong profile.
https://bugzilla.gnome.org/show_bug.cgi?id=771291
Víctor Manuel Jáquez Leal [Tue, 4 Apr 2017 12:39:59 +0000 (14:39 +0200)]
libs: encoder: refactor init_context_info()
In order to generate vaapi contexts iterative, the function
init_context_info() is refactored to pass, as parameters the
GstVaapiContextInfo and the GstVaapiProfile.
https://bugzilla.gnome.org/show_bug.cgi?id=771291
Víctor Manuel Jáquez Leal [Tue, 4 Apr 2017 12:21:43 +0000 (14:21 +0200)]
libs: encoder: initialize chroma_type
Instead of initialize the chroma_type with a undefined value, which
will be converted to GST_VAAPI_CHROMA_TYPE_YUV420 by GstVaapiContext,
this patch queries the VA config, given the received
GstVaapiContextInfo's parameters, and gets the first response.
In order to get the GstVaapiChromaType value, also it was needed to
add a new utility function: to_GstVaapiChromaType(), which, given a
VA_RT_FORMAT_* will return the associated GstVaapiChromaType.
https://bugzilla.gnome.org/show_bug.cgi?id=771291
Víctor Manuel Jáquez Leal [Fri, 31 Mar 2017 09:21:21 +0000 (11:21 +0200)]
vaapiencode: enhance logs of negotiated caps
https://bugzilla.gnome.org/show_bug.cgi?id=771291
Scott D Phillips [Wed, 5 Apr 2017 18:15:41 +0000 (11:15 -0700)]
libs: encoder: vp9: Fix initialization of ref_list
gcc 7.0.1 gives a memset-elt-size warning in gst_vaapi_encoder_vp9_init:
'memset' used with length equal to number of elements without
multiplication by element size [-Werror=memset-elt-size]
https://bugzilla.gnome.org/show_bug.cgi?id=780947
Sreerenj Balachandran [Fri, 31 Mar 2017 21:12:43 +0000 (14:12 -0700)]
encoder: h264: Fix Backward ReferencePicture flag setting
This is a regression introduced by e829b62 which
override the reference flags and caused issues with
latest intel-vaapi-driver.
Víctor Manuel Jáquez Leal [Wed, 29 Mar 2017 11:22:47 +0000 (13:22 +0200)]
libs: encoder: h265: fix code style
Trivial patch to remove a double ';' as end of instruction.
Sreerenj Balachandran [Tue, 28 Mar 2017 17:53:20 +0000 (10:53 -0700)]
encoder: h264: Fix B frame encoding artifacts
The current implementation is updating the POC values only
in Slice parameter Buffer.But we are not filling the
picture order count and reference flags in VAPictureH264
while populating VA Picture/Slice structures.The latest
intel-vaapi-driver is directly accessing the above fields
from VAPicutreH264 provided as RefPicLists, which resulted
some wrong maths and prediction errors in driver.
https://bugzilla.gnome.org/show_bug.cgi?id=780620
Víctor Manuel Jáquez Leal [Tue, 21 Mar 2017 15:13:56 +0000 (16:13 +0100)]
libs: encoder: h265: remove unused macro definition
Since the h265 encoder doesn't use GValueArray, there is no need to
disable the Glib deprecation warnings, thus removing the macro
definition.
Víctor Manuel Jáquez Leal [Mon, 20 Mar 2017 15:45:01 +0000 (16:45 +0100)]
plugins: when debug disabled, default category is NULL
As in gstreamer-vaapi a common base class is used, the specific
default category is passed to the base-plugin initializator, thus
the log messages are categorized with the used plugin.
Nonetheless, when the gst-debug is disabled in compilation time,
it is needed to pass NULL to the base-plugin initializator. This
patch does that.
https://bugzilla.gnome.org/show_bug.cgi?id=780302
Hyunjun Ko [Fri, 17 Mar 2017 08:14:01 +0000 (17:14 +0900)]
libs: h26x: adds gst_vaapi_utils_h26x_write_nal_unit()
Implements gst_vaapi_utils_h26x_write_nal_unit(), which writes NAL
unit length and data to a bitwriter.
Note that this helper function applies EPB (Emulation Prevention
Bytes), since otherwise produced codec_data might be broken when
decoder/parser considering EPB, starts parsing.
See sections 7.3 and 7.4 of the H264 and H264 specifications, which
describes the emulation_prevention_three_byte.
https://bugzilla.gnome.org/show_bug.cgi?id=778750
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Hyunjun Ko [Fri, 17 Mar 2017 07:49:41 +0000 (16:49 +0900)]
libs: utils: h26x: create vaapiutils_h26x
Since there is duplicated code in h264/265 encoder, we could
refactor it to avoid duplicated code.
https://bugzilla.gnome.org/show_bug.cgi?id=778750
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Hyunjun Ko [Fri, 17 Mar 2017 07:32:36 +0000 (16:32 +0900)]
libs: encoder: h264/5: fix wrong return value
https://bugzilla.gnome.org/show_bug.cgi?id=778750
Hyunjun Ko [Mon, 13 Mar 2017 08:29:59 +0000 (17:29 +0900)]
docs: h264/h265: put parser to the example pipeline
https://bugzilla.gnome.org/show_bug.cgi?id=778749
Hyunjun Ko [Mon, 13 Mar 2017 07:20:59 +0000 (16:20 +0900)]
libs: encoder: h265: fix reserved length of bits
Fix reserved length of bits for bit_depth_luma_minus8 and bit_depth_chroma_minus8
https://bugzilla.gnome.org/show_bug.cgi?id=778749
Thomas Petazzoni [Sun, 12 Mar 2017 17:59:42 +0000 (18:59 +0100)]
O_CLOEXEC needs _GNU_SOURCE defined
From man open(2):
The O_CLOEXEC, O_DIRECTORY, and O_NOFOLLOW flags are not specified
in POSIX.1-2001, but are specified in POSIX.1-2008. Since glibc
2.12, one can obtain their definitions by defining either
_POSIX_C_SOURCE with a value greater than or equal to 200809L or
_XOPEN_SOURCE with a value greater than or equal to 700. In glibc
2.11 and earlier, one obtains the definitions by defining
_GNU_SOURCE.
And indeed, with the uClibc C library, O_CLOEXEC is not exposed if
_GNU_SOURCE is not defined. Therefore, this commit fixes the build of
gstreamer-vaapi with the uClibc C library.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
https://bugzilla.gnome.org/show_bug.cgi?id=779953
Víctor Manuel Jáquez Leal [Tue, 14 Mar 2017 15:07:08 +0000 (16:07 +0100)]
README: fix "Sources" section
Update the URL where the release source tarballs can be downloaded.
Thomas Petazzoni [Sun, 12 Mar 2017 20:39:53 +0000 (21:39 +0100)]
README: fix "Reporting bugs" section
The "Reporting bugs" section gives
https://bugzilla.gnome.org/enter_bug.cgi?product=gstreamer-vaapi as the
link to report a bug, but this link says "Sorry, entering a bug into the
product gstreamer-vaapi has been disabled.".
This commit fixes the URL to point to the proper location, and also
removes the following paragraph that is no longer correct.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
https://bugzilla.gnome.org/show_bug.cgi?id=779954
Víctor Manuel Jáquez Leal [Fri, 3 Mar 2017 18:55:00 +0000 (19:55 +0100)]
plugins: retry to create the VA display
Particularly in GNOME Wayland, the negotiated or created GL context
defines a GLX environment, but VAAPI fails to create a GLX VA
display because there is no a DRI2 connection.
This patch retries to create the VA display if VA cannot create one
with the GL context parameters. Now using the old list of display
types.
This should also work in the case of systems with two GPU, when the
non-VAAPI has the graphics environment, and the VAAPI-enabled one
shall work headless.
https://bugzilla.gnome.org/show_bug.cgi?id=772838
Julien Isorce [Wed, 19 Oct 2016 14:33:41 +0000 (15:33 +0100)]
vaapipostproc: texture upload if driver supports GL
Removes GstVideoGLTextureUploadMeta caps feature if the driver
doesn't support opengl.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=772838
Víctor Manuel Jáquez Leal [Tue, 25 Oct 2016 15:48:47 +0000 (17:48 +0200)]
vaapidecode: texture upload if driver supports GL
When the allowed source pad caps are generated, the GLTextureUpload caps are
only inserted if the driver support OpenGL.
https://bugzilla.gnome.org/show_bug.cgi?id=772838
Sreerenj Balachandran [Wed, 22 Feb 2017 23:02:01 +0000 (15:02 -0800)]
configure: Add missing compiler flags
The AC_CHECK_HEADERS macro was failing to locate some headers, in
particular the va_enc_* headers due to missing compiler flags.
https://bugzilla.gnome.org/show_bug.cgi?id=779101
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Hyunjun Ko [Wed, 1 Mar 2017 05:48:46 +0000 (14:48 +0900)]
libs: window: wayland: handle more VAStatus to use vpp
Since the commit landed https://github.com/01org/intel-vaapi-driver/pull/55,
we should consider more returned VAStatus to use vpp.
https://bugzilla.gnome.org/show_bug.cgi?id=779400
Hyunjun Ko [Thu, 23 Feb 2017 06:16:06 +0000 (15:16 +0900)]
libs: encoder: ensure profile when context initialization
We can't be sure that encoder's profile is assgined already or not
at context initialization.
https://bugzilla.gnome.org/show_bug.cgi?id=779120
Hyunjun Ko [Thu, 23 Feb 2017 06:13:59 +0000 (15:13 +0900)]
libs: encoder: set rate control info only when query succeed
Currently, it set rate control information even when query fails.
In addition, it doesn't update any more since the flag
got_rate_control_mask is set to TRUE.
https://bugzilla.gnome.org/show_bug.cgi?id=779120
Sebastian Dröge [Fri, 24 Feb 2017 14:00:23 +0000 (16:00 +0200)]
meson: Update version
Sebastian Dröge [Fri, 24 Feb 2017 13:38:22 +0000 (15:38 +0200)]
Back to development
Sebastian Dröge [Fri, 24 Feb 2017 13:10:21 +0000 (15:10 +0200)]
Release 1.11.2
Víctor Manuel Jáquez Leal [Thu, 16 Feb 2017 17:37:59 +0000 (18:37 +0100)]
vaapiencode: merge tags for downstream's info
Add encoder and codec name and the bitrate into the output for
informational purposes. Some muxers or application use it as
media metadata.
https://bugzilla.gnome.org/show_bug.cgi?id=778781
Víctor Manuel Jáquez Leal [Fri, 17 Feb 2017 00:27:52 +0000 (01:27 +0100)]
libs: encoder: caps can change at any time
The encoder should be able to change its caps even it is already
processing a stream.
This is suppose to happen after a flush so the codedbuf_queue should
be empty.
https://bugzilla.gnome.org/show_bug.cgi?id=775490
Víctor Manuel Jáquez Leal [Fri, 17 Feb 2017 00:19:00 +0000 (01:19 +0100)]
libs: encoder: h265: bail if nal unit type fails
Bail out if the NAL unit type is not recognized.
https://bugzilla.gnome.org/show_bug.cgi?id=778782
Víctor Manuel Jáquez Leal [Thu, 16 Feb 2017 17:11:50 +0000 (18:11 +0100)]
libs: decoder: h264,h265 avoid uninitialized variable
Configuring GCC to verify possible usage of uninitialized variables,
shows that found_index might be used without previous assignation.
This patch assigns a initial value to found_index, also avoid a
branching when returning the result value.
https://bugzilla.gnome.org/show_bug.cgi?id=778782
Scott D Phillips [Tue, 14 Feb 2017 00:39:41 +0000 (16:39 -0800)]
build: rename USE_HEVC_DECODER to USE_H265_DECODER
Rename to be consistent with H.264 and also H.265 encoder. The
meson build assumed this was already consistently named, and so
previously was not able to actually build the H.265 decoder.
https://bugzilla.gnome.org/show_bug.cgi?id=778576
Tim-Philipp Müller [Wed, 15 Feb 2017 19:14:59 +0000 (19:14 +0000)]
meson: gstreamer-codecparsers is a required dep
Just like in configure.ac.
Tim-Philipp Müller [Wed, 15 Feb 2017 00:26:21 +0000 (00:26 +0000)]
meson: dist meson build files
Ship meson build files in tarballs, so people who use tarballs
in their builds can start playing with meson already.
Hyunjun Ko [Fri, 10 Feb 2017 00:51:38 +0000 (09:51 +0900)]
libs: encoder: vp8: add CBR encoding mode
This patch enables the Constant BitRate encoding mode in VP8 encoder.
Basically it adds the configuration parameters required by libva to
CBR enconding.
Original-Patch-By: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=749950
Hyunjun Ko [Thu, 9 Feb 2017 03:39:19 +0000 (12:39 +0900)]
libs: encoder: vp8: fix bitrate calculation
Base encoder's unit of bitrate is in Kbps. We should honor it so
we use the value of bitrate in VA, in which is expressed in bps.
https://bugzilla.gnome.org/show_bug.cgi?id=749950
Víctor Manuel Jáquez Leal [Thu, 9 Feb 2017 11:49:44 +0000 (12:49 +0100)]
plugins: fix build when gcc
In commit
a8e482f9 we added a function without parameters, but gcc
doesn't like that.
Scott D Phillips [Mon, 6 Feb 2017 23:46:20 +0000 (15:46 -0800)]
vaapi: add meson build
https://bugzilla.gnome.org/show_bug.cgi?id=778250
Scott D Phillips [Wed, 8 Feb 2017 18:17:40 +0000 (10:17 -0800)]
make: remove gstvaapiversion.h generation
https://bugzilla.gnome.org/show_bug.cgi?id=778250
Julien Isorce [Wed, 19 Oct 2016 14:47:41 +0000 (15:47 +0100)]
plugins: use linear storage if not the same device
When dmabuf is negotiated downstream and decoding and rendering are
not done on the same device, the layout has to be linear in order for
the memory to be shared accross devices, since each device has its
own way to do tiling.
Right now this code is rather just a to-do comment, since we are not
fetching the device ids.
https://bugzilla.gnome.org/show_bug.cgi?id=755072
Hyunjun Ko [Wed, 8 Feb 2017 05:17:05 +0000 (14:17 +0900)]
libs: utils: add HEVC profiles representation
https://bugzilla.gnome.org/show_bug.cgi?id=778318
Hyunjun Ko [Tue, 7 Feb 2017 07:17:39 +0000 (16:17 +0900)]
libs: decoder: h264: reduce frame number of gaps
Reduce frame num gaps so that we don't have to create unnecessary
dummy pictures, just throw them away.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=777506
Víctor Manuel Jáquez Leal [Sun, 16 Oct 2016 00:04:09 +0000 (01:04 +0100)]
vaapidecode: don't GLTextureUpload if dmabuf
Do not add the meta:GstVideoGLTextureUploadMeta feature if the render
element can handle dmabuf-based buffers, avoiding its negotiation.
Julien Isorce [Wed, 19 Oct 2016 15:21:21 +0000 (16:21 +0100)]
vaapidecode: make pool to export decoder's surface
Use new -base API gst_video_decoder_allocate_output_frame_full() to
pass the current proxy/surface to the pool.
The pool will will export thins given surface instead of exporting a
brand new surface that will never be filled in with meaningfull data.
https://bugzilla.gnome.org/show_bug.cgi?id=755072
Víctor Manuel Jáquez Leal [Fri, 3 Feb 2017 16:06:29 +0000 (17:06 +0100)]
plugins: decoder can negotiate dmabuf downstream
Julien Isorce [Wed, 19 Oct 2016 15:07:07 +0000 (16:07 +0100)]
vaapivideobufferpool: override acquire_buffer()
Overriding the vmethod acquire_buffer() it is possible to attach the
right GstMemory to the current acquired buffer.
As a matter of fact, this acquired buffer may contain any instantiated
GstFdmemory, since this buffer have been popped out from the buffer
pool, which is a FIFO queue. So there is no garantee that this buffer
matches with the current processed surface. Evenmore, the VA driver
might not use a FIFO queue. Therefore, it is no way to guess on the
ordering.
In short, acquire_buffer on the VA driver and on the buffer pool return
none matching data, we have to manually attach the right GstFdMemory to
the acquired GstBuffer. The right GstMemory is the one associated with
the current surface.
https://bugzilla.gnome.org/show_bug.cgi?id=755072
Julien Isorce [Wed, 19 Oct 2016 15:05:04 +0000 (16:05 +0100)]
vaapivideomemory: export surface if it is provided
gst_vaapi_dmabuf_memory_new() always exports a surface. Previously, it
had to create that surface. Now it can also export an already provided
surface. It is useful to export decoder's surfaces (from VA context).
https://bugzilla.gnome.org/show_bug.cgi?id=755072
Julien Isorce [Wed, 19 Oct 2016 14:55:27 +0000 (15:55 +0100)]
vaapivideobufferpool: add GstVaapiVideoBufferPoolAcquireParams
Useful to let the pool know the current surface proxy when calling
gst_buffer_pool_alloc_buffer() / gst_buffer_pool_acquire_buffer()
https://bugzilla.gnome.org/show_bug.cgi?id=755072
Julien Isorce [Wed, 19 Oct 2016 14:09:34 +0000 (15:09 +0100)]
libs: surface: add gst_vaapi_surface_{set,peek}_buffer_proxy()
These functions are useful when a dmabuf-based memory is instantiated in
order to relate the generated buffer @proxy with the processed @surface.
https://bugzilla.gnome.org/show_bug.cgi?id=755072
Julien Isorce [Wed, 19 Oct 2016 14:07:31 +0000 (15:07 +0100)]
libs: bufferproxy: gst_vaapi_buffer_proxy_{set,peek}_mem()
This patch adds a GstMemory as a variable member of the buffer proxy,
because we will need to associate the buffer proxy with the memory
which exposes it. Later, we will know which memory, in the video buffer
pool, is attached to the processed surface.
https://bugzilla.gnome.org/show_bug.cgi?id=755072
Julien Isorce [Wed, 19 Oct 2016 14:33:41 +0000 (15:33 +0100)]
vaapipostproc: don't GLTextureUpload if dmabuf
Do not add the meta:GstVideoGLTextureUploadMeta feature if the render
element can handle dmabuf-based buffers, avoiding its negotiation.
Similar as "vaapidecode: do not add meta:GstVideoGLTextureUploadMeta
feature if can dmabuf"
https://bugzilla.gnome.org/show_bug.cgi?id=755072
Víctor Manuel Jáquez Leal [Fri, 16 Dec 2016 13:12:30 +0000 (14:12 +0100)]
plugins: enable DMAbuf allocator to downstream
If the negotiated caps are raw caps and downstream supports the
EGL_EXT_image_dma_buf_import extension, then the created allocator
is the DMAbuf, configured to downstream.
At this moment, the only element which can push dmabuf-based buffers
to downstream, is vaapipostproc.
Víctor Manuel Jáquez Leal [Thu, 2 Jun 2016 20:13:51 +0000 (22:13 +0200)]
plugins: check if negotiate dmabuf with downstream
In order to enable, in the future, dmabuf-based buffers, the vaapi base
plugin needs to check if downstream can import dmabuf buffers.
This patch checks if downstream can handle dmabuf, by introspecting the
shared GL context. If the GL context is EGL/GLES2 and have the extension
EGL_EXT_image_dma_buf_import, then dmabuf can be negotiated.
Original-patch-by: Julien Isorce <j.isorce@samsung.com>
Julien Isorce [Wed, 19 Oct 2016 14:37:04 +0000 (15:37 +0100)]
vaapivideomemory: release proxy's data if downstream
The surface created for downstream is going to be filled by VAAPI
elements. So, the driver needs write access on that surface.
This patch releases the derived image held by the proxy, thus the
surface is unmarked as busy.
This is how it has to be done as discussed on libva mailing list.
https://bugzilla.gnome.org/show_bug.cgi?id=755072
Julien Isorce [Wed, 19 Oct 2016 14:01:04 +0000 (15:01 +0100)]
libs: bufferproxy: add gst_vaapi_buffer_proxy_release_data()
Adds an API to request the user's data release in the buffer proxy.
https://bugzilla.gnome.org/show_bug.cgi?id=755072
Julien Isorce [Wed, 19 Oct 2016 14:27:03 +0000 (15:27 +0100)]
vaapivideomemory: add direction to dmabuf allocator
Add GstPadDirection param to gst_vaapi_dmabuf_allocator_new(), thus
we later could do different thing when the allocated memory is for
upstream or dowstream, as required by VA-API.
https://bugzilla.gnome.org/show_bug.cgi?id=755072
Hyunjun Ko [Thu, 15 Dec 2016 06:59:30 +0000 (15:59 +0900)]
libs: utils: return NULL if failed to get surface formats
Thus, when generating the allowed caps, the element will throw a
warning and it will use its caps template.
This behavior might be a bug in the VA driver.
https://bugzilla.gnome.org/show_bug.cgi?id=775490
Víctor Manuel Jáquez Leal [Thu, 26 Nov 2015 17:21:08 +0000 (18:21 +0100)]
Revert "vaapidisplay: mark X11 display as compatible with EGL"
This reverts commit
200b1baabc066f8a4102f82f539655d588200ec9.
Hyunjun Ko [Wed, 1 Feb 2017 05:32:45 +0000 (14:32 +0900)]
vaapipostproc: set GST_VAAPI_POSTPROC_FLAG_SIZE according to src caps
A value of width/height property should be set to out caps,
if negotiation had been going properly.
So we can use srcpad_info when making decision of scaling.
https://bugzilla.gnome.org/show_bug.cgi?id=778010
Víctor Manuel Jáquez Leal [Fri, 27 Jan 2017 11:10:54 +0000 (12:10 +0100)]
plugins: handle GL params through context query
If the element instantiated the GL display and context, they should
handle them too through the context query.
https://bugzilla.gnome.org/show_bug.cgi?id=777409
Víctor Manuel Jáquez Leal [Thu, 26 Jan 2017 11:02:56 +0000 (12:02 +0100)]
plugins: create a GL context on certain conditions
If a GstVaapiDisplay is not found in the GStreamer context sharing,
then VAAPI elements look for a local GstGLContext in gst context
sharing mechanism ('gst.gl.local.context').
If this GstGLContext not found either then, only the VAAPI decoders
and the VAAPI post-processor, will try to instantiate a new
GstGLContext.
If a valid GstGLContext is received, then a new GstVaapiDisplay will
be instantiated with the platform, API and windowing specified by the
instantiated GstGLContext.
Original-Patch-By: Matt Fischer <matt.fischer@garmin.com>
https://bugzilla.gnome.org/show_bug.cgi?id=777409
Víctor Manuel Jáquez Leal [Tue, 2 Aug 2016 13:48:25 +0000 (15:48 +0200)]
vaapivideocontext: context type can be rejected
Instead of calling g_return_val_if_fail() to check the context type, we
should use a normal conditional, since it is possible that other context types
can arrive and try to be assigned. Otherwise a critical log message is
printed.
This happens when we use playbin3 with vaapipostproc as video-filter.
https://bugzilla.gnome.org/show_bug.cgi?id=777409
Víctor Manuel Jáquez Leal [Fri, 20 Jan 2017 18:57:52 +0000 (19:57 +0100)]
vaapipostproc: use sink caps par if not requested
Use the sink caps pixel-aspect-ratio to fixate the src caps, if it
is not already set.
https://bugzilla.gnome.org/show_bug.cgi?id=777395
Víctor Manuel Jáquez Leal [Fri, 20 Jan 2017 18:00:24 +0000 (19:00 +0100)]
vaapipostproc: set interlace mode
if the vaapipostproc is configured to not do deinterlacing, the
interlace-mode in the src caps should be the same as the input caps.
https://bugzilla.gnome.org/show_bug.cgi?id=777395
Víctor Manuel Jáquez Leal [Fri, 20 Jan 2017 15:10:32 +0000 (16:10 +0100)]
vaapisink: fix gcc compiler warning
warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
Víctor Manuel Jáquez Leal [Thu, 12 Jan 2017 18:54:41 +0000 (19:54 +0100)]
vaapisink: don't use member variable outside lock
Thus a race condition segfault is avoided.
Original-patch-by: Matt Staples <staples255@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=777146
Víctor Manuel Jáquez Leal [Wed, 18 Jan 2017 16:20:21 +0000 (17:20 +0100)]
plugins: avoid log flood when activating pool
Every time a new buffer is allocated, the pool is activated. This
doesn't impact in performance since gst_buffer_pool_set_active()
checks the current state of the pool. Nonetheless it logs out a
message if the state is the same, and it floods the logging subsystem
if it is enabled.
To avoid this log flooding first the pool state is checked before
changing it.
Víctor Manuel Jáquez Leal [Fri, 13 Jan 2017 20:26:15 +0000 (21:26 +0100)]
vaapidecode: update internal decoder sink caps
When a new sink caps arrive the internal decoder state is updated
and, if it is, request a downstream renegotiation.
Previously, when new caps arrived the whole decoder where destroyed
and recreated. Now, if the caps are compatible or has the same codec,
the internal decoder is kept, but a downstream renegotiation is
requested.
https://bugzilla.gnome.org/show_bug.cgi?id=776979
Sebastian Dröge [Thu, 12 Jan 2017 14:33:13 +0000 (16:33 +0200)]
Back to development
Sebastian Dröge [Thu, 12 Jan 2017 14:27:12 +0000 (16:27 +0200)]
Release 1.11.1
Víctor Manuel Jáquez Leal [Thu, 12 Jan 2017 11:49:55 +0000 (12:49 +0100)]
vaapi: bump ifdef to API 0.40.0 for log redirect
vaSetInfoCallback() is not released yet. It is going to appear in
VA-API 0.40.0
Sebastian Dröge [Thu, 12 Jan 2017 11:45:29 +0000 (13:45 +0200)]
vaapiutils: Fix compilation with latest and previous libva releases
vaSetInfoCallback() was defined after 0.39.4 / 1.7.3, so check for
0.39.5 instead.
Víctor Manuel Jáquez Leal [Wed, 11 Jan 2017 15:04:24 +0000 (16:04 +0100)]
libs: display: redirect logging at initialize
Redirect libva's logs to GStreamer logging mechanism. This is
particularly useful when VA is initialized, because it always logs
out the drivers details.
In order to achieve this a new helper function was added as a wrapper
for the vaInitialize() function.
https://bugzilla.gnome.org/show_bug.cgi?id=777115
Hyunjun Ko [Tue, 10 Jan 2017 06:15:31 +0000 (15:15 +0900)]
plugins: provide at least two buffers in sink pool
Adds two buffers as the default value of minimum buffer.
This would be used when creating and proposing vaapi bufferpool for
sink pad, hence the upstream element will keep, at least, these two
buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=775203
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Hyunjun Ko [Tue, 10 Jan 2017 04:49:27 +0000 (13:49 +0900)]
libs: decoder: h264: don't update cloned attributes
If the frame is a cloned picture, its PTS comes from its parent
picture. In addition, the base decoder doesn't set a valid PTS to
the frame corresponding to the cloned picture.
https://bugzilla.gnome.org/show_bug.cgi?id=774254
Víctor Manuel Jáquez Leal [Mon, 9 Jan 2017 18:25:24 +0000 (19:25 +0100)]
vaapivideomemory: check for display
This patch fixes the check of display, rather than check for the
meta, which it is known it exists.
Víctor Manuel Jáquez Leal [Mon, 9 Jan 2017 15:23:56 +0000 (16:23 +0100)]
vaapivideomemory: rename dmabuf allocator parameters
Rename the parameters 'vip' and 'flags' to 'alloc_info' and
'surface_alloc_flags' respectively. The purpose of this change is
to auto-document those parameters.
Also, aligned to this patch, the local 'alloc_info' variable was
renamed as 'surface_info', because it stores the possible surface's
video info, not the allocate one.
Víctor Manuel Jáquez Leal [Mon, 9 Jan 2017 15:18:32 +0000 (16:18 +0100)]
vaapivideomemory: rename vip to alloc_info parameter
In order to auto-document the code, this patch renames the 'vip'
parameter in the functions related to gst_vaapi_video_allocator_new ()
to 'alloc_info', since it declares the allocation video info from
the vaapi buffer pool.
Víctor Manuel Jáquez Leal [Mon, 9 Jan 2017 15:08:17 +0000 (16:08 +0100)]
vaapivideomemory: use GST_VIDEO_INFO_FORMAT_STRING()
Use the existing local macro GST_VIDEO_INFO_FORMAT_STRING() to get
the video format string.