The former approach to left the bin unfinished has some problems: the context
cannot be shared because the vaapidecode is unlinked in many cases, leading to
creating a VADisplay twice.
Initially the bin is fully functional, constructed as
(-----------------------------------)
| vaapidecodebin |
| (-------------) (-------) |
|<--| vaapidecode |--->| queue |--->|
| (-------------) (-------) |
(-----------------------------------)
When the context is shared and the VADisplay has VPP capabilities, before
changing to READY state, the bin is reconfigured dynamically, adding the
vaapipostproc element afeter the queue:
(--------------------------------------------------------)
| vaapidecodebin |
| (-------------) (-------) (---------------) |
|<--| vaapidecode |--->| queue |--->| vaapipostproc |--->|
| (-------------) (-------) (---------------) |
(--------------------------------------------------------)
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757957
Delay the bin configuration until changing to READY state. This is because we
should add the vaapipostproc element until the vaapidecode has emitted the
HAVE_CONTEXT message, so de gst_bin_add() could set the context set to
vaapipostproc.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757957
Since gstreamer 1.4 is not required to have pad query functions if the query
vmethods are used.
This patch guards out the pad query functions for gstreamer < 1.4
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757629
GstVideoEncoder, the base class of vaapiencode, added support for pad queries
as virtual methods since gstreamer 1.4. This patch enables those vmethods,
while keeps support for previous versions of gstreamer.
This patch is relevant since GstVideoEncoder takes care of other queries that
we are currently ignoring.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757629
A caps query can occur before the element has a display. In that case, the
element can return its pad's template. But when the element already has a
display, and the caps probe fails, the element shall return an empty caps, so
the auto-plug could try with another decoder.
If the element has a display and the caps probe works, then the computed caps
should be returned.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757598
Caps query can happen before the element has a bus. The display creation should
be should occur on the context negotiation, when the bus is already configured.
Then at caps query no display should be created.
Instead of force the display creation, we graciously fail the allowed_caps()
creation.
This change only applies for vaapidecode and vaapisink. The vaapipostroc, as a
basetransform descendant, seems to be not affected by this, nor the encoders.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757598
The current context query handling design is flawed: the function
gst_vaapi_reply_to_query() returns FALSE either if the query is not a
GST_CONTEXT_QUERY of if the query could not be handled correctly. But the
pad query function should handle differently each case.
This patch changes the gst_vaapi_reply_to_query() for
gst_vaapi_handle_context_query() and changes it usage in all the vaapi plugins
to match the correct context query handling.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757598
When processing the GST_CONTEXT_QUERY we should not lose the previous
context in the query, we should only add our display structure.
This patch copies the old context, if it is there, and stamp our display on
it. Otherwise, a new context is created.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757598
This function set the display to an already created context. This function is
going to be used later.
Also, gst_vaapi_video_context_new_with_display() now uses this function.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757598
Since the context messages are sync'ed, the display assignation happens in the
same thread, hence we can know if the display was found or not as soon we call
for it.
In order to take advantage of it, gst_vaapi_video_context_prepare() receives,
as a new parameter, the address of the plugin's display, and reports back if
the display was found and set.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757598
Instead of setting the display to the plugin directly after its creation, do
it through the gstreamer's context mechanism, avoiding double assignations.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757598
The context structure is named "display" which is too generic. The contrary
happens, for example, with GstGL, what uses the same name as the context, and
its logs make more sense.
This patch renames the context structure with the same name as the
context, thus GST_PTR_FORMAT can pretty print it.
https://bugzilla.gnome.org/show_bug.cgi?id=757598
First, refactorized run_context_query() into _gst_context_run_query(), adding
a new parameter: the pad direction, in order to simplify the code.
Second, added a new helper function: _gst_context_query(), which is a generic
context query function. It isolates the operation of running the query and
sets the context if found, also it enhances the logs.
_gst_context_query() is similar to the one used in GstGL. Perhaps, in the
future this helper function will be merged into the core libraries of
GStreamer.
Finally, gst_vaapi_video_context_prepare() was rewritten to use
_gst_context_query().
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757598
Refactor the extraction GST_CAT_CONTEXT logging using a only once
initializator, so we could get the debug category from different code
paths, safely.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757598
gst-indent does not handle correctly some expression like function
declaration with attributes, breaking the following expressions.
This patch makes gst-indent to ignore the attributed function
declartion so the followed function definition is not mangled, such
as happened in commit b4154a
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757598
The display returned by gst_vaapi_video_context_get_display() increments the
references. Thus, we have to unref the returned display.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757595
Though caps features are supported since GStreamer 1.2, there are some
issues with the features caps negotiation in that version. Nonetheless,
those issues are fixed in GStreamer 1.4. So, the memoy:VASurface caps
feature negotiation is relaxed for GStreamer 1.4.
The guard is the same as in vaapisink's caps template.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=756686
The received caps query will bring the already negotiated caps, so they are
not expected to change.
This patch removes this verification which is dead code path.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=756686
Instead of calling gst_vaapi_find_preferred_caps_feature(), which is
expensive, we check the caps from the allocation query, to check the
negotiated feature.
In order to do this verification a new utility function has been implemented:
gst_vaapi_caps_feature_contains().
As this new function shared its logic with gst_caps_has_vaapi_surface(), both
have been refactorized.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=756686
There is a regression from commit 3d8e5e. It was expected the buffer pool
allocation occur before the caps negotiation, but it is not.
This patch fixes this regression: the caps negotiation is done regardless the
allocation query from downstream.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=756686
gst_buffer_copy_deep() was added in GStreamer 1.5. If want to use it we should
add an implementation if gstreamer-vaapi is linked to previous versions.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
GST_CODEC_PARSER_* variables are defined if builtin codec parsers are disabled
when running configure.
Right now, libgstcodecparsers links only to libgstvaapi, but libgstvaapi_parse
need it if builtin codec parsers are disabled.
This patch adds GST_CODEC_PARSER_* variables to libgstvaapi_parse
compilation. If builtin codec parsers are enable, this variable is null, so it
should work using libgstvaapi, as normal.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=754845
gst_vaapi_decoder_state_changed() returns void. This patch fixes the
compilation where the toolchain uses restrictive flags as clang.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
The use of gst_caps_is_always_compatible() for this optimization may lead to
false positives. It is better to stick to gst_caps_is_strictly_equal() to know
if it is required a re-negotiation.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=750835
Delaying the pool re-negotiation untill we push all decoded (and queued)
frames downstream. Otherwise for the multi-resolution videos, the
GstVideoVideoMemory will be having wrong resolution and which leads
to nasty behaviours, especially when using software renderers.
sample media file: RAP_B_Bossen_1.bin
case explained:
The first SPS Nal will report resoultion of 448x256 and having crop rectangles to
get the final resoultion 416x240.
Starting from 25 th frame, the resolution will change to 416x240. But parser
elements won't report this since the effective croped resolution is same in
both cases. Here the core libgstvaapi will detect this through it's internal
parsing and do all context/pool destory/reset stuffs. Also it will notify this
change to plugins in advance. But if the plugin try to do re-negotiaion of pool
immediately, this will not sync with the resolution of already decoded and queued
frames and which will lead to failure in gst_video_frame_map() in downstream(if we use the
software renderer). So we have to delay the pool renegotiation in vaapidecode,
untill we push all decoded frames downstream.
https://bugzilla.gnome.org/show_bug.cgi?id=753914
Currently we are sharing the input GstVideoCodecState with
GstVaapiDecoder(gst-libs/gst/vaapi) by just doing ref and unref for
each caps change. This is troublesome in many cases, for eg: if
resoultion changes with in a singe stream. Because, when ever there
is a resolution change, GstVideoDecoder will first change the Codec_state->caps
fields with new resolution, but since we are using the same codecstate (ref)
in gstvaapidecode.c, the caps check for input caps change will always fail.
https://bugzilla.gnome.org/show_bug.cgi?id=753914
If the VPP's deinterlace-method is set, first we should check if the postproc
is already instanced to set it. Otherwise we just store it until the VPP is
added into the bin.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=749554
There are sometimes that the VA-API display context is not shared among the
pipeline, but it is important to know it before going to READY state (when the
pipeline is already linked).
One instance of this case is this:
gst-launch-1.0 filesrc location=media ! decodebin ! vaapipostproc ! vaapisink
This patch adds a new function in gstvaapipluginutil called
gst_vaapi_create_test_display(). Its purpose is to create a disposable VA-API
display, which only will be used for verify if the VAEntrypointVideoProc is
available by the hardware. Afterwards, it should be unrefed.
If the vaapidecodebin is going to READY state, and the element still doesn't
know if VPP is available, the last resort is to create a new instance of the
VA-API display and test for it.
https://bugzilla.gnome.org/show_bug.cgi?id=749554
If USE_NATIVE_FORMATS is defined we bail out before configuring the surface
info based on the derived image configuration.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=744042
First added the function gst_vaapi_video_format_get_best_native(), which
returns the best native format that matches a particular chroma type:
YUV 4:2:0 -> NV12, YUV 4:2:2 -> YUY2, YUV 4:0:0 -> Y800
RGB32 chroma and encoded format map to NV12 too.
That format is used to configure, initially, the surface's pool for the
allocator.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=744042
gst_vaapi_video_context_prepare() received an unused parameter. This patch
removes it and the structure passed by the caller.
This a left over of "Removal of gstreamer-1.0 support" (commit 8b36e25f).
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Refactor the main vaapi caps strings into three macros:
GST_VAAPI_MAKE_SURFACE_CAPS, GST_VAAPI_MAKE_ENC_SURFACE_CAPS and
GST_VAAPI_MAKE_GLTEXUPLOAD_CAPS.
Those are in gstvaapipluginutil.h so all the elements could use them, instead
of re-declaring them every time.
No functional changes.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Those messagse should be attached to the object, also the lack of
caps is not an error, in particular in the case of JPEG encoding.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=744042
Working on bug #744042 I realized that the gstvaapiuploader is practically not
used.
This patch removes the gstvaapiuploader and add the method
gst_vaapi_plugin_base_get_allowed_raw_caps () that returns the raw caps that
the system can handle, which is used by vaapisink and vaapipostproc.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=752777
When seeking, the decoder is reset, but the buffer pool is not
re-negotiated, but in reset_full() the code forgets if the negotiated buffer
pool has the GLTextureUpload meta.
The decoder knows that GLTextureUpload meta was negotiated in
decide_allocation(), but this method is not called when seeking.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=752929
gst_pad_get_allowed_caps() query the pad and the peer pad. In the case
decoders, that is OK, but in the case of the postproc might lead loops,
since the gst_base_transform_query_caps() forwards the query upstream
and forth.
Instead of gst_pad_get_allowed_caps() we only query the peer with
gst_pad_peer_query_caps() using the pad's template as filter.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=752558
Add initial infrastructure in core codec library and vaapidecode to mark
corrupted frames as such. A corrupted frame is such a frame that was
reconstructed from invalid references for instance.
https://bugzilla.gnome.org/show_bug.cgi?id=751434
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Unfortunately vaapidecodebin element is not seems to be stable
enough for autoplugging ahead of vaapidecode.
Lowering the rank for now (cosidering the immediate 0.6 release).
See this: https://bugzilla.gnome.org/show_bug.cgi?id=749554
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
When the system is aware that VPP is not available by the VA driver,
it would be useful to notify to the user that the disable-vpp property
has changed.
https://bugzilla.gnome.org/show_bug.cgi?id=749554
Instead of creating and adding VPP into the bin at setup, we wait until
we are sure the VA driver supports it. We know that when the VA video
context is received by the bin. Afterwards, it is decided to instanciate
and link the VPP or not.
This is more efficient and safer than waiting the VPP to fail and then
disable it.
https://bugzilla.gnome.org/show_bug.cgi?id=749554
Adding a new propery "disable-vpp", enabling it will prevent
the insertion of vaapipostproc child element.
This is helpful in debugging, specifically to narrow-down the
vaapidecodebin/vaapipostproc related negotiation issues.
No support for run-time disabling for now.
https://bugzilla.gnome.org/show_bug.cgi?id=745901
The Current code path is falling back to passthorugh mode if there is no
vpp property set by the user explictily. But we should not use the
passthrough mode if the negotiated src pad caps have a differnt color space
format than sink pad caps (Even though the user didn't set the format property
explicitly).
https://bugzilla.gnome.org/show_bug.cgi?id=748184
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
This is a workaround to deal with the va-intel-driver for non-native
formats while doing advanced deinterlacing. The format of reference surfaces must
be same as the format used by the driver internally for motion adaptive
deinterlacing and motion compensated deinterlacing.
A permanent solution could be to do the color space conversion internally
for reference surfaces.
https://bugzilla.gnome.org/show_bug.cgi?id=730925
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
vaapisink takes the display lock, then does a gst_buffer_replace which can
take the lock on the gst_vaapi_video_pool.
vaapipostproc asks the gst_vaapi_video_pool for a new surface. This takes
the lock on the gst_vaapi_video_pool; if you're unlucky, there are no free
surfaces, which means that gst_vaapi_surface_create is
called. gst_vaapi_surface_create takes the display lock.
If vaapisink and vaapipostproc are in different threads, and this happens,
you get a deadlock. vaapisink holds the display lock, and wants the
gst_vaapi_video_pool lock. vaapipostproc holds the gst_vaapi_video_pool lock
and wants the display lock.
Work around this by releasing the display lock in vaapisink around the
gst_buffer_replace.
https://bugzilla.gnome.org/show_bug.cgi?id=738249
Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
This patch enhance the code path when an error is found when rendering a
buffer.
If the video meta doesn't contain a surface proxy or a surface, a warning
message is printed.
If the rendering backend fails, a error message is posted in the bus.
https://bugzilla.gnome.org/show_bug.cgi?id=749382
This fixes the regression introduced in 64acc74.
If a pad supports multiple set of capsfeatures, it needs to add
multiple equal structures with different feature sets to the caps.
Because caps structures with the same name but with a non-equal
set of caps features are not compatible.
Without this patch, playbin will autoplug xvimagesink instead of vaapisink.
https://bugzilla.gnome.org/show_bug.cgi?id=750095
This is a naïve approach to the calculation of the VA-API decoding latency. It
takes into consideration when the frame-rate has some insane value.
https://bugzilla.gnome.org/show_bug.cgi?id=740419
Otherwise wl_display_dispatch_queue() might prevent the pipeline from
shutting down. This can happen e.g. if the wayland compositor exits while
the pipeline is running.
Changes:
* renamed unlock()/unlock_stop() to unblock()/unblock_cancel() in gstvaapiwindow
* splitted the patch removing wl_display_dispatch_queue()
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=747492https://bugzilla.gnome.org/show_bug.cgi?id=749078
This patch fixes several issues found when running the `make distcheck`
target:
- In commit c561b8da, the update of gstcompat.h in Makefile.am was
forgotten.
- In commit c5756a91 add the simple_encoder_source_h in EXTRA_DIST was
forgotten.
- vpx.build.stamp is not generated at all, only vpx.configure.stamp.
- The make target distcleancheck failed because some autogenerated files
were not handled with the DISTCLEANFILES variable.
Note: `make distcheck -jXX` is not currently supported.
Fix link when building plugin elements without HEVC support. e.g. don't
try to call into gst_vaapi_decoder_h265_set_alignment() if there is no
support HEVC enabled in libgstvaapi.
Also, drop disabled codecs from static template caps. Add the missing
HEVC static template caps into vaapidecodebin too.
In commit 97b768, a regression for GStreamer 1.2 was introduced:
GStreamer 1.2 doesn't check, in gst_buffer_pool_set_config() if the
config option is already set. This patch adds an inline function to
first verify if the option is not in the pool config berfore add it.
In order to reduce the noise, the query type log was downgrade from INFO to
DEBUG, and the shared display address log message is assigned to the object.
Fix regression introduced by bd866479, the query after decide_allocation()
always needs a pool in the first slot.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=748559
This a cosmetic refactor: gst_vaapidecode_internal_flush() removes its only
label; gst_vaapidecode_finish() is more readable and gst_vaapidecode_purge()
shares the same error message of gst_vaapidecode_internal_flush() when flush
fails.
Add the method gst_vaapidecode_purge(). This method releases the
flushed frames from the decoder.
This new method add more readablity to gst_vaapidecode_destroy()
When a frame is rejected by downstream, the message is logged twice. This
patch removes one of those logging messages.
Also, the reject of a frame doesn't mean an alarming error. This patch demotes
the log message from error to info.
This is a mirror of h265parse element in upstream gst-plugins-bad.
There could be additional patches but all should go to upstream.
This is for making development faster.
Note: vaapiparse_h265 will get build only for GStreamer version >= 1.4
The problem with this is that creating the filter causes the display to
be selected, and the caps query happens while linking the element. So,
if the downstream or upstream element is using a specific display
object, it won't be propagated correctly to the postproc as it already
has a display at this point.
https://bugzilla.gnome.org/show_bug.cgi?id=747945
vaapisink inherits from GstVideoSink, in order to use its functionality (such
as ::show-preroll-frame property), we should use its vmethod show_frame(),
rather than call ourselves render() and preroll().
This patch adds the signal ::handoff and the property signal-handoffs. If the
property is set TRUE, the signal ::handoff is emitted just after the buffer is
rendered.
Based on Zhao Halley <halley.zhao@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=747905
We get one reference when the frame is passed to decode_handle_frame()
and create another one in gst_vaapi_decoder_push_frame().
Usually the frame is handled in gst_vaapidecode_push_decoded_frame().
Here the frame is always released twice:
gst_video_decoder_finish_frame() + gst_video_codec_frame_unref() or
gst_video_decoder_drop_frame() + gst_video_codec_frame_unref().
In gst_vaapidecode_reset_full() both references to the frame must be
released as well.
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
https://bugzilla.gnome.org/show_bug.cgi?id=743226
The support for GStreamer 1.0 has been obsoleted in 0.5.10 release.
GStreamer 1.2 is the a minimal requirement for building the gstreamer-vaapi.
This patch removes all the pre-processor conditional code compilation guarded
for gstreamer-1.0.
Thus, all the video converters were removed too.
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>
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 patch only removes the support of gstreamer-1.0 in the autotools
scripts. No other files are touched.
In the automake file all the converters were deprecated.
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>
In GStremer v1.6 a new vmethod drain() was added in GstVideoDecoder
class. This patch implements this new method.
https://bugzilla.gnome.org/show_bug.cgi?id=742922
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
Since in bug #745728 the support for GStreamer 1.0 is going to be dropped,
this patch removes the method reset() which was deprecated in GStreamer 1.2.
https://bugzilla.gnome.org/show_bug.cgi?id=742922
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
Since GStreamer 1.2 the vmethod reset() in GstVideoDecoderClass was deprecated
and flush() was added.
This patch set the vmethod flush() if the installed GStreamer version is 1.2 or
superior. Otherwise, reset() is set.
v2: 1) In order to avoid symbol collision, the old method gst_vaapidecode_flush()
was renamed to gst_vaapidecode_internal_flush().
2) The new vmethod flush() always do a hard full reset.
v3: 1) Call gst_vaapidecode_internal_flush() first in flush() vmethod, in order to
gather all collected data with gst_video_decoder_have_frame()
https://bugzilla.gnome.org/show_bug.cgi?id=742922
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
In commit 2f8c115 (vaapidecode: use the query virtual methods in 1.4)
a bug was introduced: when calling the parent's query function of the
src pad, the one of the sink pad is called instead. This patch fixes
this issue.
https://bugzilla.gnome.org/show_bug.cgi?id=746248
Sometimes, for example, when switching video streams but keeping
the same sink, the surface will be released after the decoder is
stopped and replaced. This caused a crash because the release
callback was called on an invalid pointer.
The patch adding an additional reference to the decoder object in the buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=745189
Signed-off-by: Olivier Crete <olivier.crete@collabora.com>
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
GstVideoDecoder, the base class of vaapidecode, added support for
pad queries as virtual methods. This patch enables the use of that
support, while keeping support for lower versions of gstreamer.
This patch is important because GstVideoDecoder takes care of other
queries that might be important in the pipeline managing.
v2: 1) rebase to current master
2) fix indentation with gst-indent
3) simplify the patch layout
4) fix the context query
5) initialise the filter to NULL
6) improve the query log message for gst-1.2
https://bugzilla.gnome.org/show_bug.cgi?id=744406
The vaapipostproc has a proxy flag to know if the the buffer pool is
already active. But this fails in some situations where it is needed
to renegotiate the buffer pool.
This patch removes that flag so the renegotiation is done whenever is
required.
https://bugzilla.gnome.org/show_bug.cgi?id=745535
The gst_video_colorimetry_to_string() function returns a newly created
string that represents the GstVideoColorimetry value. So, that needs
to be released after usage, in e.g. GST_DEBUG().
Add a "vaapidecodebin" element to vaapi plugins.
Child Elements: "vaapidecode ! queue ! vaapipostproc"
The Reasons for implementing a new bin element:
-- Help to Autoplug Hardware Accelerated Video Postprocessing element in playbin
with out any dependency to upstream gstreamer.
This is to overcome the *unacceptable* delay in upstream gstreamer to get new
features in. Eg: https://bugzilla.gnome.org/show_bug.cgi?id=687182.
Also customers using older gstreamer versions (1.2 and 1.4) will get the
benefit of autoplugging, hardware accelerated deinterlacing support etc.
-- Help to maintain a single thread implementation in vaapidecode.
This will result a dead-lock free vaapidecode in most of the cases.
More details here: https://bugzilla.gnome.org/show_bug.cgi?id=742605https://bugzilla.gnome.org/show_bug.cgi?id=745216
Because the decoder uses the thread from handle_frame() to decode a frame,
the src pad task creates an unsolveable AB-BA deadlock between
handle_frame() waiting for a free surface and decode_loop() pushing
decoded frames out.
Instead, have handle_frame() take responsibility for pushing surfaces,
and remove the deadlock completely. If you need a separate thread
downstream, you can insert a queue between vaapidecode and its downstream
to get one.
Another justification for the single thread implementation is,
there are two many point of locking in gstreamer-vaapi's current
implementation which can lead to deadlocks.
https://bugzilla.gnome.org/show_bug.cgi?id=742605
Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
Improve check for upstream element that requires DMABUF buffer pool,
e.g. v4l2src element. In particular, make sure to traverse through
any additional capsfilter for instance.
Note: the traversal to the top-most upstream element could be made
more generic, but we are insofar only interested in supporting pipes
similar to v4l2src or v4l2src ! capsfilter, e.g. with an explicit
specification for a desired video camera format, or resolution.
The dmabuf allocator would close the DMABUF handle passed in the init
function gst_dmabuf_allocator_alloc(). So, we need to dup() it so that
to avoid a double close, ultimately in the underlying driver that owns
the DMABUF handle.
vaapidecode keeps an output state that use the format
GST_VIDEO_FORMAT_ENCODED, while it crafts a different src caps
for a correct negotiation.
I don't see the rational behind this decoupling, it looks like
unnecessary complexity. This patch simplify this logic keeping
in sync the output state and the src caps.
This patch improves the readability of the function
gst_vaapidecode_update_src_caps() and simplify its logic. Also,
the patch validates if the buffer pool has the configuration for
the GL texture upload meta, in order to set the caps feature
meta:GLTextureUpload. Otherwise, the I420 format is set back.
https://bugzilla.gnome.org/show_bug.cgi?id=744618
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
When vaapidecode finishes the decoding of a frame and pushes it,
if, in the decide_allocation() method, it is determined if the
next element supports the GL texture upload meta feature, the
decoder adds the buffer's meta.
Nonetheless, in the same spirit of the commit 71d3ce4d, the
determination if the next element supports the GL texture upload
meta needs to check both the preferred caps feature *and* if the
allocation query request the API type.
This patch, first removes the unused variable need_pool, and
determines the attribute has_texture_upload_meta using the
preferred caps feature *and* the allocation query.
Also, the feature passed to GstVaapPluginBase is not longer
determined by has_texture_upload_meta, but by the computed
preferred one.
https://bugzilla.gnome.org/show_bug.cgi?id=744618
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
Currently the src caps are set immediately after the sink caps are set, but in
that moment the pipeline might not fully constructed and the video sink has
not negotiated its supported caps and features. As a consequence, in many cases
of playback, the least optimized caps feature is forced. This is partially the
responsible of bug #744039.
Also, vaapidecode doesn't attend the reconfigure events from downstream,
which is a problem too, since the video sink can be changed with different
caps features.
This patch delays the src caps, setting them until the first frame arrives to
the decoder, assuming until that very moment the whole pipeline is already
negotiated. Particularly, it checks if the src pad needs to be reconfigured,
as a consequence of a reconfiguration event from downstream.
A key part of this patch is the new GstVaapiCapsFeature
GST_VAAPI_CAPS_FEATURE_NOT_NEGOTIATED, which is returned when the src pad
doesn't have a peer yet. Also, for a better report of the caps allowed
through the src pad and its peer, this patch uses gst_pad_get_allowed_caps()
instead of gst_pad_peer_query_caps() when looking for the preferred feature.
v3: move the input_state unref to close(), since videodecoder resets at
some events such as navigation.
v4: a) the state_changed() callback replaces the input_state if the media
changed, so this case is also handled.
b) since the parameter ref_state in gst_vaapidecode_update_src_caps() is
always the input_state, the parameter were removed.
c) there were a lot of repeated code handling the input_state, so I
refactored it with the function gst_vaapi_decode_input_state_replace().
https://bugzilla.gnome.org/show_bug.cgi?id=744618
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
Working on bug #743687, I realized that vaapidecode always adds to its buffer
pool the config option GST_BUFFER_POOL_OPTION_VIDEO_GL_TEXTURE_UPLOAD_META if
the decide_allocation()'s query has GST_VIDEO_GL_TEXTURE_UPLOAD_META_API_TYPE.
Nevertheless, there are occasions where the query has the API type, but the
last negotiated caps don't have the feature meta:GstVideoGLTextureUploadMeta.
Under this contradiction, vaapidecode adds the GLTextureUploadMeta API to its
buffer pool configuration, and adds its buffer's meta to each output buffer,
even if the negotiated caps feature is memory:SystemMemory with I420 color
format.
This kind of output buffers chokes ClutterAutoVideosSink, since it uses a map
that relates caps <-> GL upload method. If it receives a buffer with color
format I420, it assumes that it doesn't have a texture upload meta, because
only those with RGB color format has it. Our buffers, with I420 format, say
that they have the upload meta too. In that case the mapped method is a dummy
one which does nothing. I reported this issue in bug #744039 (the patch,
obviously, was rejected).
This patch workarounds the problem: the buffer pool's configuration option
GST_BUFFER_POOL_OPTION_VIDEO_GL_TEXTURE_UPLOAD_META is set if and only if the
query has the GST_VIDEO_GL_TEXTURE_UPLOAD_META_API_TYPE *and* the negotiated
caps feature is meta:GstVideoGLTextureUploadMeta.
I have tested these patches with gst-master (1.5), gst-1.4 and gst-1.2 and
in all they seem to work correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=744618
[adapted to fit current EGL changes]
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
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.
Some frameworks (EFL) expect BGRA textures for storage. However,
adding support for that broadly into GStreamer framework implies
two kinds of hacks: (i) libgstgl helpers currently do not support
BGRA textures correctly, (ii) we need to better parse downstream
suggested caps and intersect them with what the VA plugin elements
can offer to them for GL texturing.
When multiple display servers are available, the glimagesink element
(from GStreamer 1.4) may not be able to derive a global display in
Wayland. Rather, a "window"-specific display is created. In this case,
the GstGLDisplay handle available through GstGLContext is invalid.
So, try to improve heuristics for display server characterisation in
those particular situations.
Add initial support for EGL through GstVideoGLTextureUploadMeta.
Fix gst_vaapi_ensure_display() to allocate a GstVaapiDisplay off the
downstream supplied GstGLContext configuration, i.e. use its native
display handle to create a GstVaapiDisplay of type X11 or Wayland ;
and use the desired OpenGL API to allocate the GstVaapiDisplayEGL
wrapper.
https://bugzilla.gnome.org/show_bug.cgi?id=741079
Sync video texture sizes to GstVideoGLTextureUploadMeta private date,
i.e. GstVaapiVideoMetaTexture, on a regular basis. In particular, we
now update the texture size from the GstVideoMeta, if any, or reset
to some defaults otherwise.
If a GstGLContext is supplied by the downstream element, then make
sure that the VA plugin element gets a compatible display to what
is requested by the GL context. e.g. re-allocate a VA/GLX display
when a GLX context is provided by the downstream element.
Record GL context supplied by downstream elements. This can be useful,
and further needed, to enforce run-time check that the GL context is
compatible for use by libgstvaapi. e.g. check that we don't create a
VA/GLX display for EGL/X11 contexts.
https://bugzilla.gnome.org/show_bug.cgi?id=725643
Original-path-by: Matthew Waters <ystreet00@gmail.com>
Reset the VA decoder after updating the base plugin caps, and most
importantly, after GstVideoDecoder negotiation. The reason behind
this is that the negotiation could trigger a last decide_allocation()
where we could actually derive a new GstVaapiDisplay to use from the
downstream element. e.g. GLX backend.
Query caps filtering should be always done on top of allowed caps instead
of existing fixed caps on a particular pad.
This fixes the mvc stream decoding when there is a base view(high profile)
and non-base view(stereo-high profile).
According to documentation[1] when receiving a GST_QUERY_CAPS
the return value should be all formats that this elements supports,
taking into account limitations of peer elements further downstream
or upstream, sorted by order of preference, highest preference first.
This patch add those limitations intersecting with the received
filter in the query. Also takes into account the already negotiated
caps. Also adds the processing of the query on the SRC pad.
1. http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/section-nego-getcaps.htmlhttps://bugzilla.gnome.org/show_bug.cgi?id=744406
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
GstVaapiVideoMemory quark is not needed any more, and the actual
implementation was already removed bfore the merge. i.e. this is
an oversight for a hunk that was not meant to be pushed.
Allow v4l2src element to connected to vaapipostproc or vaapisink when
"io-mode" is set to "dmabuf-import". In practice, this is a more likely
operational mode with uvcvideo. Supporting v4lsrc with "io-mode" set
to "dmabuf" could work, but with more demanding driver or kernel reqs.
Note: with GStreamer 1.4, v4l2src (gst-plugins-good) needs to be built
with --without-libv4l2.
https://bugzilla.gnome.org/show_bug.cgi?id=743635
Allow imports of v4l2 buffers into VA surfaces for further operation
with vaapi plugins, e.g. vaapipostproc or vaapiencode_* elements.
https://bugzilla.gnome.org/show_bug.cgi?id=735362
[fixed memory leaks, ported to new dma_buf infrastructure, cleanups]
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Reword surface pool allocation helpers so that to allow for a simple
form, e.g. gst_vaapi_surface_pool_new(format, width, height); and a
somewhat more elaborated/flexible form with optional allocation flags
and precise GstVideoInfo specification.
This is an API/ABI change, and SONAME version needs to be bumped.
Add gst_vaapi_display_has_opengl() helper function to help determining
whether the display can support OpenGL context to be bound to it, i.e.
if the class is of type GST_VAAPI_DISPLAY_TYPE_GLX.
Make gst_vaapi_display_get_display_type() return the actual VA display
type. Conversely, add a gst_vaapi_display_get_class_type() function to
return the type of the GstVaapiDisplay instance. The former is used to
identify the display server onto which the application is running, and
the latter to identify the original object class.
GstVaapiTexture is a generic abstraction that could be moved to the
core libgstvaapi library. While doing this, no extra dependency needs
to be added. This means that a GstVaapitextureClass is now available
for any specific code that needs to be added, e.g. creation of the
underlying GL texture objects, or backend dependent ways to upload
a surface to the texture object.
Generic OpenGL data types (GLuint, GLenum) are also replaced with a
plain guint.
https://bugzilla.gnome.org/show_bug.cgi?id=736715
The gst_vaapi_texture_put_surface() function is missing a crop_rect
argument that would be used during transfer for cropping the source
surface to the desired dimensions.
Note: from a user point-of-view, he should create the GstVaapiTexture
object with the cropped size. That's the default behaviour in software
decoding pipelines that we need to cope with.
This is an API/ABI change, and SONAME version needs to be bumped.
https://bugzilla.gnome.org/show_bug.cgi?id=736712
dvbsuboverlay signals no subtitles present by not setting
GstVideoOverlayCompositionMeta on a buffer.
Detect this, and remove subtitles whenever we have no overlay composition to
hand.
Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Otherwise restarting may fail because the state of vaapipluginbase and
vaapipostproc don't match. e.g. gst_vaapipostproc_set_caps() will skip
initailization and not call gst_vaapi_plugin_base_set_caps()
Make sure that the GstVaapiPluginBase instance receives the new src
pad caps whenever they get updated from within the GstVaapiDecoder
decode routines.
This also ensures that downstream elements receive correctly sized
SW decoded buffers if needed.
https://bugs.tizen.org/jira/browse/TC-114
Split GstVideoDecoder::set_format() handler to first update the sink
pad caps and reset the active VA decoder instance based on those, and
then update the src pad caps whenever possible, e.g. when the caps
specify a valid video resolution.
In some occasions, a buffer pool is created for pre-initialization
purposes regardless of whether a valid image size is available or
not. However, during actual decode stage, the vaapidecode element
is expected to update the srcpad caps with the new dimensions, thus
also triggering a reset of the underlying bufferpool.
If the best downstream capsfeature turns out to be GLMemory, then make
sure to propagate RGBA video format in caps to that element. This fixes
the following pipeline: ... ! vaapipostproc ! glimagesink.
When an explicit output video format is selected, from an src pad
capsfilter, make sure that the downstream element actually supports
that format. In particular, fix crash with the following pipelines:
... ! vaapipostproc ! video/x-raw,format=XXX ! xvimagesink ; where
XXX is a format not supported by xvimagesink.
While doing so, also reduce the set of src pad filter caps to the
actual set of allowed src pad caps.
The ensure_surface() and ensure_image() functions shall only relate
to the underlying backing store. The actual current flags are to be
updated only through ensure_{surface,image}_is_current() or very other
particular cases in GstMemory hooks.
If the surface proxy is updated into the GstVaapiVideoMemory, then
it is assumed it is the most current representation of the current
video frame. Likewise, make a few more arrangements to have the
"current " flags set more consistently.
When interacting with SW elements, the buffers and underlying video
memory could be mapped as read/write. However, we need to use those
buffers again as plain VA surfaces, we have to make sure the VA image
is thus committed back to VA surface memory.
This fixes pipelines involving avdec_* and vaapi{postproc,sink}.
Hence vaapisink can display buffers decoded by gst-libav, or HW decoded
buffers can be further processed in-place, e.g. with a textoverlay.
https://bugzilla.gnome.org/show_bug.cgi?id=704078
[ported to current git master branch, amended commit message]
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
In the current implementation, gst_video_info_set_format() would reset
the whole GstVideoInfo structure first, prior to setting video format
and size. So, coleteral information like framerate or pixel-aspect-
ratio are lost.
Provide and use a unique gst_video_info_change_format() for overcome
this issue, i.e. only have it change the format and video size, and
copy over the rest of the fields.
https://bugzilla.gnome.org/show_bug.cgi?id=734665
This is for helping decodebin to autoplug the vaapidecode element.
Decodebin is selecting decoder elements only based on rank and caps.
Without overriding the autoplug-* signals there is no way to autoplug
HW decoders inside decodebin. An easier soulution is to raise the
rank of vaapidecode, so that it gets selected first.
https://bugzilla.gnome.org/show_bug.cgi?id=739332
Added the same Klass specifications used in other upstream
video postprocessing elements like videoconvert, videoscale,
videobalance and deinterlace.
An example use case is for this is to help the playsink
to autoplug the hardware accelerated deinterlacer.
This is a workaround until auto-plugging is fixed when
format=ENCODED + memory:VASurface caps feature are provided.
Use the downstream negotiated video format as the output video format
if the user didn't ask for the colorspace conversion explicitly.
Usecase: This will help to connect elements like videoscale, videorate etc
to vaapipostproc.
https://bugzilla.gnome.org/show_bug.cgi?id=739443
Add new "scale-method" property to expose the scaling mode to use during
video processing. Note that this is only a hint, and the actual behaviour
may differ from implementation (VA driver) to implementation.
Attach the codec_data to out_caps only if downstream needed.
For eg: h264 encoder doesn't need to stuff codec_data to the
src caps if the negotiated caps has a stream format of byte-stream.
https://bugzilla.gnome.org/show_bug.cgi?id=734902
Fix arguments to XkbKeycodeToKeysym() for converting an X11 keycode
to a KeySym. In particular, there is no such Window argument. Also
make sure to check for, and use, the correct <X11/XKBlib.h> header
where that new function is defined. Otherwise, default to the older
XKeycodeToKeysym() function.
Really use the motion event coordinates to propagate the "mouse-move"
event to upper layer, instead of those from a button event. Those are
technically the same though.
When we copy a buffer because we're moving it into VA-API memory, we
need to copy flags. Otherwise, interlaced YUV buffers from a capture
source (e.g. V4L2) don't get flagged as interlaced.
https://bugzilla.gnome.org/show_bug.cgi?id=726270
Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
[reversed order of gst_buffer_copy_into() flags to match <1.0 code]
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Allow implicit conversions to raw video formats, while still keeping
VA surfaces underneath. This allows for chaining the vaapipostproc
element to a software-only element that takes care of maps/unmaps.
e.g. xvimagesink.
https://bugzilla.gnome.org/show_bug.cgi?id=720174
Use pooled GstVaapiVideoMeta information, i.e. always allocate that on
video buffer allocation. Also optimize copy of additional metadata info
into the resulting video buffer: only copy the video cropping info and
the source surface proxy.
https://bugzilla.gnome.org/show_bug.cgi?id=720311
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
[fixed proxy leak, fixed double free on error, optimized meta copy]
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
If no explicit output surface format is supplied try to keep the one
supplied through the sink pad caps. This avoids a useless copy, even
if things are kept in GPU memory.
This is a performance regression from git commit dfa70b9.
If only advanced deinterlacing is requested, i.e. deinterlacing is
the only active algorithm to apply with source and output surface
formats being the same, then make sure to enable VPP processing.
Otherwise, allow fallback to bob-deinterlacing with simple rendering
flags alteration.
Add a default decide_allocation() hook to GstVaapiPluginBase. The caps
feature argument can be used to force a bufferpool with a specific kind
of memory.
Add GST_VAAPI_VIDEO_BUFFER_POOL_ACQUIRE_FLAG_NO_ALLOC params flag that
can be used to disable early allocations of vaapi video metas on buffers,
thus delagating that to the bufferpool user.
Default to I420 format for output surfaces so that to match the usual
GStreamer pipelines. Though, internally, we could still opt for NV12
surface formats, i.e. default format=ENCODED is a hint for that, thus
delegating the decision to the VA driver.
Use the new gst_caps_has_vaapi_surface() helper function to detect
whether the sink pad caps contain native VA surfaces, or not, i.e.
no raw video caps.
Also rename is_raw_yuv to get_va_surfaces to make the variable more
explicit as we just want a way to differentiate raw video caps from
VA surfaces actually.
The "discontinuity" tracking code, whereby lost frames are tentatively
detected, is inoperant if the sink pad buffer timestamps are not right
to begin with.
This is a temporary workaround until the following bug is fixed:
https://bugzilla.gnome.org/show_bug.cgi?id=734386
In order to make the discontinuity detection code useful, we need to
detect the lost frames in the history as early as the previous frame.
This is because some VA implementations only support one reference
frame for advanced deinterlacing.
In practice, turn the condition for detecting new frame that is beyond
the previous frame from field_duration*2 to field_duration*3, i.e.
nothing received for the past frame and a half because of possible
rounding errors when calculating the field-duration either in this
element (vaapipostproc), or from the upstream element (parser element).
This is a regression introduced with commit faefd62.
https://bugzilla.gnome.org/show_bug.cgi?id=734135
Introduce new gst_caps_has_vaapi_surface() helper function to detect
whether the supplied caps has VA surfaces. With GStreamer >= 1.2, this
implies a check for memory:VASurface caps features, and format=ENCODED
for earlier versions of GStreamer.
Simplify the creation and installation process of properties, by first
accumulating them into a g_properties[] array, and next calling into
g_object_class_install_properties().
Also add missing docs and flags to some properties.
Move code around in a more logical way. Introduce GST_VAAPISINK_CAST()
helper macro and use it wherever we know the object is a GstBaseSink or
any base class. Drop explicit initializers for values that have defaults
set to zero.
Introduce new backends vtable so that to have clean separation between
display dependent code and common base code. That's a "soft" separation,
we don't really need dedicated objects.
https://bugzilla.gnome.org/show_bug.cgi?id=722248
Support for X11 "synchronous" mode was never implemented, and was only
to be useful for debugging. Drop that altogether, that's not going to
be useful in practice.
https://bugzilla.gnome.org/show_bug.cgi?id=733985
Rendering with GLX in vaapisink is kind of useless nowadays, including
OpenGL related fancy effects. Plain VA/GLX interfaces are also getting
deprecated in favor of EGL, or more direct buffer sharing with actual
GL textures.
Should testing of interop with GLX be needed, one could still be using
the modern cluttersink or glimagesink elements.
https://bugzilla.gnome.org/show_bug.cgi?id=733984
Allow dynamic changes to the window, e.g. performed by the user, and
make sure to refresh its contents, while preserving aspect ratio.
In practice, Expose and ConfigureNotify events are tracked in X11
display mode by default. This occurs in a separte event thread, and
this is similar to what xvimagesink does. Any of those events will
trigger a reconfiguration of the window "soft" size, subsequently
the render-rect when necessary, and finally _expose() the result.
The default of handle_events=true can be changed programatically via
gst_x_overlay_handle_events().
Thanks to Fabrice Bellet for rebasing the patch.
https://bugzilla.gnome.org/show_bug.cgi?id=711478
[dropped XInitThreads(), cleaned up the code a little]
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
The gst_vaapidecode_decode_loop() function is called within a separate
task to fetch and output all frames that were decoded so far. So, if
the decoder_loop_status is forcibly set to EOS when _finish() is called,
then we are bound to exist the task without submitting the pending
frames.
If the downstream element error'ed out, then the gst_pad_push() would
propagate up an error and so we will get it right for cutting off
_finish() early in that case.
This is a regression from 6003596.
https://bugzilla.gnome.org/show_bug.cgi?id=733897
Fixes a hang/race on shutdown where _decode_loop() had already completed
its execution and _finish() was waiting on a GCond for decode_loop()
to complete. Also fixes the possible race where _finish() is called
but _decode_loop() endlessly returns before signalling completion
iff the decoder instance returns GST_FLOW_OK.
Found with: ... ! vaapidecode ! {glimagesink,cluttersink}
https://bugzilla.gnome.org/show_bug.cgi?id=733897
[factored out GST_VIDEO_DECODER_STREAM_UNLOCK() call]
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Now that we always track the currently active video buffer, it is
not necessary to automatically increase its reference since this is
implicitly performed in ::show_frame() through the get_input_buffer()
helper from GstVaapiPluginBase class.
This is a regression from a26df80.
Rework the logics behind the configuration of an adequate bufferpool,
especially when OpenGL meta or additional capsfeatures are needed.
Besides, for GStreamer >= 1.4, the first capsfeatures that gets matched,
and that is not system memory, is now selected by default.
Make sure to propagate memory:VASurface capsfeature to srcpad caps
only for GStreamer >= 1.5 as the plug-in elements in GStreamer 1.4
core currently miss additional patches available in 1.5-git (1.6).
This is a temporary workaround.
If a multiview stream is decoded, multiple view components are submitted
as is downstream. It is the responsibility of the sink element to display
the required view components. By default, always select the frame buffer
that matches the view-id of the very first frame to be displayed.
However, introduce a "view-id" property to allow the selection of a
specific view component of interest to display.
Always record the VA surface that is currently being rendered, no matter
the fact we are using texturedblit or overlay. That's because in some
occasions, we need to refresh or resize the displayed contents based on
new events. e.g. user-resized window.
Besides, it's simpler to track the last video buffer in GstVaapiSink than
through the base sink "last-sample".
Add a "display-name" property to vaapisink so that the end user could
select the desired output. Keep "display-name" in-line with the existing
"display" (GstVaapiDisplayXXX type).
So, for X11 or GLX, the "display-name" is the usual display name as we
know for XOpenDisplay(); for Wayland, the "display-name" is the name used
for wl_display_connect(); and for DRM, the "display-name" is actually the
DRI device name.
https://bugzilla.gnome.org/show_bug.cgi?id=722247
Always add VideoAlignment bufferpool option if the downstream element
expects its own pool to be used but does not offer it through a proper
propose_allocation() implementation for instance, and that the ALLOCATION
query does not expose the availability of the Video Meta API.
This fixes propagation of video buffer stride information to Firefox.
Make sure to always prefer native internal formats for the VA surfaces
that get allocated. Also disable "direct-rendering" mode in this case.
This is needed so that to make sure that anything that gets out of the
decoder, or anything that gets into the encoder, is in native format
for the hardware, and thus the driver doesn't need to perform implicit
conversions in there. Interop with SW elements is still available with
fast implementations of VA imaging APIs.
Forbid shares of GstMemory instances, and rather make copy of it. This
effectively copies the GstMemory structure and enclosed metadata, but
this does not copy the VA surface contents itself. It should though.
This fixes preroll and makes sure to not download garbage for the first
frame when a SW rendering sink is used.
Use an image pool to hold VA images to be used for downloads/uploads
of contents for the associated surface.
This is an optmization for size. So, instead of creating as many VA
images as there are buffers (then VA surfaces) allocated, we only
maintain a minimal set of live VA images, thus preserving memory
resources.
Disable read-write mappings if "direct-rendering" is not supported.
Since the ordering of read and write operations is not specified,
this would require to always download the VA surface on _map(), then
commit the temporary VA image back to the VA surface on _unmap().
Some SW decoding plug-in elements still use R/W mappings though.
https://bugzilla.gnome.org/show_bug.cgi?id=733242
Fix error messages introduced in the previous commit for the _map()
imaplementation. Also use the new get_image_data() helper function
to determine the base pixels data buffer from a GstVaapiImage when
updating the video info structure from it.
Allow raw pixels of the whole frame to be mapped read-only. i.e. in
cases where the buffer pool is allocated without VideoMeta API, thus
individual planes cannot be mapped.
This is initial support for Firefox >= 30.
https://bugzilla.gnome.org/show_bug.cgi?id=731886
While creating the vaapi video allocator, make sure the associated
surface pool has correct format instead of defaulting to NV12 video
format even though there is no direct rendering support.
https://bugzilla.gnome.org/show_bug.cgi?id=732691
Make sure to always update the VA surface pointer whenever the proxy
changes. This used to only work when the VA surface is written to, in
interop with SW element ("upload" feature), and this now fixes cases
when the VA surface is needed for reading, in interop with SW element
("download" feature).
Always expose I420 format by default when the VA surface could be
mapped for interoperability with non harware accelerated elements.
However, the default behaviour remains the auto-plugging of vaapi
elements, down to the sink.
Side effect: "direct-rendering" mode is also disabled most of the
times as plain memcpy() from uncached speculative write combining
memory is not going to be efficient enough.
Fix support for VA surface download capability in vaapidecode element
for GStreamer >= 1.2. This is a fix to supporting libva-vdpau-driver,
but also the libva-intel-driver while performing hardware accelerated
conversions from the native VA surface format (NV12) to the desired
output VA image format.
For instance, this fixes pipelines involving vaapidecode ! xvimagesink.
https://bugzilla.gnome.org/show_bug.cgi?id=733243
When playbin/decodebin builds the pipeline, it puts decoders and sinks
into different bins and forwards the queries from bins to bins. So in
the initials steps the pipeline is built iteratively by playbin and
looks like this :
[filesrc]
[filesrc] -> [typefind]
[filesrc] -> [typefind] -> [demuxer]
[filesrc] -> [typefind] -> [demuxer] -> [decoder]
At this point the decoder is asked for its SRC caps and it will make a
choice based on what gst_pad_peer_query_caps() returns. The problem is
that the caps returns at that point includes caps features like ANY,
essentially because playbin can plug in additional elements like
videoscale, videoconv or deinterlace.
This patch adds a another call to
gst_vaapi_find_preferred_caps_feature() when the decoder decides its
allocation, to make sure we asks the downstream elements when the
entire pipeline has been built.
https://bugzilla.gnome.org/show_bug.cgi?id=731645
A compiler change showed me that tmp_rect went out of scope before
it was used. Move it to the beginning of the function instead.
https://bugzilla.gnome.org/show_bug.cgi?id=726363
Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
[added guards for GStreamer 0.10 builds]
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
We can avoid scanning for start codes again if the bitstream is fed
in NALU chunks. Currently, we always scan for start codes, and keep
track of remaining bits in a GstAdapter, even if, in practice, we
are likely receiving one GstBuffer per NAL unit. i.e. h264parse with
"nal" alignment.
https://bugzilla.gnome.org/show_bug.cgi?id=723284
[use gst_adapter_available_fast() to determine the top buffer size]
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Avoid reaching an assert if dynamic framerates (0/1) are used. One
way to solve this problem is to just stick field_duration to zero.
However, this means that, in presence of interlaced streams, the
very first field will never be displayed if precise presentation
timestamps are honoured.
https://bugzilla.gnome.org/show_bug.cgi?id=729604
ensure_srcpad_buffer_pool() tries to avoid unnecessarily deleting and
recreating filter_pool. Unfortunately, this also meant it didn't create
it if it did not exist.
Fix it to always create the buffer pool if it does not exist.
https://bugzilla.gnome.org/show_bug.cgi?id=723834
Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Reset deinterlacer state, i.e. past reference frames used for advanced
deinterlacing, when there is some discontinuity detected in the course
of processing source buffers.
This fixes support for advanced deinterlacing when a seek occurred.
https://bugzilla.gnome.org/show_bug.cgi?id=720375
[fixed type of pts_diff variable, fetch previous buffer PTS from the
history buffer, reduce heuristic for detecting discontinuity]
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Apply video cropping regions stored in GstVideoCropMeta, or in older
GstVaapiSurfaceProxy representation, to VPP pipelines. In non-VPP modes,
the crop meta are already propagated to the output buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=720730
deinterlace-mode didn't behave in the way you'd expect if you have
past experience of the deinterlace element. There were two bugs:
1. "auto" mode wouldn't deinterlace "interleaved" buffers, only "mixed".
2. "force" mode wouldn't deinterlace "mixed" buffers flagged as progressive.
Fix these up, and add assertions and error messages to detect cases that
aren't handled.
https://bugzilla.gnome.org/show_bug.cgi?id=726361
Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
gst_video_info_set_format() does not preserve video info properties. In
order to keep important information in the caps such as interlace mode,
framerate, pixel aspect ratio, ... we need to manually copy back those
properties after setting the new video format.
https://bugzilla.gnome.org/show_bug.cgi?id=722276
It can happen that there is a pool provided that does not advertise
the vappivideometa. We should unref that pool before using our own.
Discovered with vaapidecode ! {glimagesink,cluttersink}
https://bugzilla.gnome.org/show_bug.cgi?id=724957
[fixed compilation by adding the missing semi-colon]
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Parse any pending data until a complete frame is obtained. This is a
memory optimization to avoid expansion of video packets stuffed into
the GstAdapter, and a fix to EOS condition to detect there is actually
pending data that needs to be decoded, and subsequently output.
https://bugzilla.gnome.org/show_bug.cgi?id=731831
Force early initializatin of the GstVaapiDisplay so that to make sure
that the sink element display object is presented first to upstream
elements, as it will be correctly featuring the requested display type
by the user.
Otherwise, we might end up in situations where a VA/X11 display is
initialized in vaapidecode, then we try VA/DRM display in vaapisink
(as requested by the "display" property), but this would cause a failure
because we cannot acquire a DRM display that was previously acquired
through another backend (e.g. VA/X11).
When a new display is settled through GstElement::set_context() (>= 1.2),
or GstVideoContext::set_context() (<= 1.0), then we shall also update the
associated display type.
