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
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.
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
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>
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.
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.
gst_vaapi_surface_new_with_format() is a wrapper for
gst_vaapi_surface_new_full (). In this case, the former is simpler
than the first. This patch changes that.
If src pad caps have changed, it needs to notify it downstream. In
addition, do not set passthrough if they have changed.
Otherwise, transform sometimes starts processing before caps change.
The passthrough value will be set in fixate later in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=775204
Add a capsfilter forcing the caps
"video/x-raw(memory:VASurface), format=(string)NV12" between the
queue and the vaapipostproc so no renegotiation is required.
https://bugzilla.gnome.org/show_bug.cgi?id=776175
To detect and handle errors during allocator_configure_surface_info()
and allocator_conigure_image_info().
https://bugzilla.gnome.org/show_bug.cgi?id=776084
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
When an instance of GstVaapiVideoAllocator fails at initializing, the
log message should not include the allocator's object, because it is
going to be unrefed.
This reverts commit 3285121181.
videodecode's negotiate() vmethod is also called when events arrive,
but this would mean that the proper configuration of sink pad might
not be complete, thus we should not update the src pad.
Let's keep the old non-vmethod negotitate().
Added the inlined function allocator_configure_pools() moving out code
from gst_vaapi_video_allocator_new() to make clear that it is a
post-initalization of the object.
Since video_info stores the GstVideoInfo of the allocation caps,
it is clear if we rename it as allocation_info, to distinguish it
later from negotiation_info.
Instead of defining GstVaapiDmaBufAllocator as a hackish decorator of
GstDmaBufAllocator, now, since the expose of the GstDmaBufAllocator's
GType, GstVaapiDmaBufAllocator is a full feature GstAllocator inherited
from GstDmaBufAllocator.
https://bugzilla.gnome.org/show_bug.cgi?id=755072
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Add a helper function to initialize the gst_debug_vaapivideomemory,
to use it either by the GstVaapiVideoAllocatorClass or
GstVaapiDmabufAllocator (which is a decorator of GstDmaBufAllocator).
Later, log possible errors when calling gst_vaapi_dmabuf_allocator_new ()
https://bugzilla.gnome.org/show_bug.cgi?id=755072
As the internal encoder is created at start(), let's release it at
stop() vmethod, to be consistent.
gst_vaapiencode_destroy() is called since it also resets the input and
output states, which is something that the base class does internally
after calling stop() vmethod.
https://bugzilla.gnome.org/show_bug.cgi?id=769266
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Currently, specific encoder is created during set_format(). This might
lead to race condition when creating profiles with multiple encoders.
This patch moves ensure_encoder() call to start() vmethod to ensure
avoiding the race condition.
https://bugzilla.gnome.org/show_bug.cgi?id=773546
In commit ca0c3fd6 we remove the dynamic configuration if the bin
because we assumed that the bin will be always static as it is
registered.
Nonetheless we were wrong, because it is possible to request, with a
property, to avoid the use of the post-processor.
Since we want to add a way to disable the post-processor through
environment variables, this remove feature is required again.
If the environment variable GST_VAAPI_DISABLE_VPP is defined the
postprocessor inside of the vaapidecodebin is disabled, then
vaapidecodebin is an alias of the old vaapidecode.
https://bugzilla.gnome.org/show_bug.cgi?id=775041
Instead of creating the VA display before setting the bus to the
element, it is created when the element is opened.
Basically, this commit is a revert of
5e5d62cac7
That was done when the GStreamer's context sharing was not mature
enough as now. There is no reason to keep this hack.
Since the differentiation of negotiation caps and allocation caps,
there is no need to add a video crop meta with the negotiation caps.
Hence, removing it.
https://bugzilla.gnome.org/show_bug.cgi?id=773948
Since all the video converter were deprecated in gstreamer-1.2, we don't need
to handle them anymore in the vaapi's buffer meta.
This patch removes its usage and the buffer meta's API for that.
https://bugzilla.gnome.org/show_bug.cgi?id=745728
First, deactivate source pad pool when the out caps change, and if so,
destroy texture map, the source pad allocator and pool only if the
new caps are different from the ones already set.
This is related with bug 758907 when no vaapipostproc is used (no
vaapidecodebin). In order to negotiate downstream we need to destroy
the source pad allocator, otherwise the same allocated buffers are
used, failing the mapping.
Remove redundant GST_VAAPI_TYPE_VIDEO_INFO, since it is a duplicate of
GST_TYPE_VIDEO_INFO created before gstreamer 1.6, where the boxed type
was created.
https://bugzilla.gnome.org/show_bug.cgi?id=774782
This patch adds the created allocator to the allocation query either
in decide_allocation() and propose_allocation() vmehtods.
With it, there's no need to set the modified allocator's size in the
pool configuration.
https://bugzilla.gnome.org/show_bug.cgi?id=774782
We should set the correct buffer size when we are configuring the pool,
otherwise the buffer will be discarded when it returns to the pool.
Indeed when the ref-count of a buffer reaches zero, its pool will queue
it back (and ref it) if, and only if, the buffer size matches the
configured buffer size on the pool.
This issue can be debugged with GST_DEBUG=*PERF*:6, see gstbufferpool.c
https://bugzilla.gnome.org/show_bug.cgi?id=774782
When calling gst_vaapi_video_memory_copy() the allocator of the memory
to copy should be allocated by the vaapi allocator.
This patch does this verification.
Instead of having a gst_vaapi_video_memory_free() that is only going to
be called by gst_vaapi_video_allocator_free(), let's just remove the first
and merged into the second.
