Right now the local JPEG parser is always compiled because the check for the
upstreamed version is broken: it looks for an non existent symbol:
GstJpegImage.
This patch changes that check for< GstJpegFrameHdr.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
This basically reverts 62c3888b76 (wayland:
decouple wl_buffer from frame).
Otherwise the frame may be overwritten while it is still used by the
compositer:
The frame done callback (frame_done_callback()) is called, when the
compositor is done processing the frame and hands it to the hardware.
The buffer release callback (frame_release_callback()) is called when the
buffer memory is no longer used.
This can be quite some time later: E.g. if weston (with the DRM backend)
puts the buffer on a hardware plane, then then buffer release callback is
called when the kernel is done with the buffer. This is usually when the
next frame is shown, so most likely after the frame done callback for the
next frame!
Since 70eff01d36 "wayland: sync() when
destroy()" the mentioned possible leak should no longer be a problem, so
reverting this change should cause no leaking buffers.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=758848
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
When transforming downstream caps we should check for ANY caps from peer pad,
otherwise we get a segmentation fault.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=759893
When gst_vaapi_plugin_base_get_input_buffer() fail to copy the input buffer
into a VAAPI buffer, the return value is GST_FLOW_NOT_SUPPORTED, and it was
ignored by the vaapisink, leading to a segmentation fault.
This patch ignores the frame that generated the GST_FLOW_NOT_SUPPORTED
returned by gst_vaapi_plugin_base_get_input_buffer(), avoiding the
segmentation fault, but doing and effort to continue rendering. This is
the same behavior of ximagesink.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=759332
Only supporting vaapidecode ! vaapisink combination for now.
Missing dependencies:
1: No support for P010 video format in GStreamer
2: No support for P010 vaGetImage()/vaPutimage() in vaapi-intel-driver
3: As a result of 1&2 , we have no support for Vaapi Video memory mapping
through GstVideoMeta.
Right now we only set chroma format (YUV420 with more than 8 bits per channel)
for surface pool and keeping GST_VIDEO_FORMAT as ENCODED. The underlying format
of the surfaces is implementation (driver) defined, which is P010.
This new API gst_vaapi_surface_pool_new_with_chroma_type() is for
creating a new GstVaapiVideoPool of GstVaapiSurfaces with the specified
chroam type and dimensions. The underlying format of the surfaces is
implementation (driver) defined.
When receiving the texture from the application or the video sink, we must
know it size and border. To query the texture the API has changed according to
the OpenGL version used in the GL context of the application/vsink.
This patch checks the current context API type and queries the texture
according to this detected API.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=753099
gst_vaapi_texture_glx_new_wrapped() only handles a GL_TEXTURE_2D target and
formats GL_RGBA or GL_BGRA.
This patch adds a debugging verification of those values.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=753099
In order to know which OpenGL API use, we must detect the API type of current
context. This patch adds the function gl_get_current_api() which returns the
OpenGL API type.
This function is an adaptation of gst_gl_context_get_current_gl_api() from
GstGL.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=753099
This is a quick fix for regression introduced by the upstream
commit e8908f5aee in h264 videoparser.
The patch is disabling the passthrough mode, otherwise it will
break multi-layer mvc stream parsing.
https://bugzilla.gnome.org/show_bug.cgi?id=758656
As gsth265parse was added in GStreamer 1.4, and gstreamer-vaapi still support
GStreamer 1.2, the patching of gsth265parse must be conditional to the target
GStreamer version.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=755525
This is a continuation of commit fc8a0d12
When declaring BUILT_SOURCES, those files should not be distributed. This
patch avoids the distribution of the generated source code.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=755525
`make dist` broke since commit f06798 (libvpx: Update the submodule to
libvpx-1.4.0) because the sources.frag does not contain all the module
sources.
This patch updates thoroughly the sources.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=755525
When the source caps change, the filter is destroyed and recreated.
Nonetheless, this happens every time the vaapipostproc starts, since the caps
change detection algorithm does not take in consideration when the caps are
set by first time.
This patch intents to be an optimization, to avoid a useless filter
destroy-creation cycle when the sources caps are set for first time.
The new helper function video_info_update() is a refactorization to avoid
duplicated code.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=758007
The signature is video_info_changed(old_vip, new_vip). Nonetheless the callers
swapped the the order. This didn't raise problems since the comparison of both
structures were not affected by its semantics.
But still it would be better to fix this to keep the coherence of the code.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=758007
When runnig the `make dist` target from a clean tree, it fails because
if could not find the copied files from codecparsers submodule.
They weren't copied because they weren't declared as built sources.
This patch removes the stamp mechanism and use the actual file list to copy
as the built sources. Also it fixes the duplication of the parser files.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=755525
In order to build a debian package with upstream source, the user should
do
./autogen.sh
cp -a debian.upstream debian
debuild -eDEB_BUILD_OPTIONS="parallel=8" -us -uc -b
The environment variable DEB_BUILD_OPTIONS="parallel=8" is the canonical
way to make a parallel build (-j8 in this case).
This commit removes the script in debian/rules that detects the number of
cpus, requested by the environment variable DEBIAN_BUILD_NCPUS, which is not
official in debian.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=754087
We always set GST_VAAPI_PICTURE_FLAG_SKIPPED for DECODE_ONLY frames and the
gstvaapidecoder base calss is reponsible for handling those frames later on.
No need for explicit verification of frame header's show_frame in order to
do picture outputing.
Rather than create a dummy display, if none has propagated as a context, we
should try to get the one from vaapidecode.
As the bin is already in READY state, the vaapidecode should be also in that
state. That means that the contexts have been negotiated, and it should have
already a display.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757957
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
Set crop rectange if:
There is display_width and display_height which is different from actual width/height
or
The changed resolution is less than the actual configured dimension of surfaces
Unlike other decoders, vp9 decoder doesn't need to reset the
whole context and surfaces for each resolution change. Context
reset only needed if resolution of any frame is greater than
what actullay configured. There are streams where a bigger
resolution set in ivf header or webm header but actual resolution
of all frames are less. Also it is possible to have inter-prediction
between these multi resolution frames.
clang complains about a couple variables and one label which were not
used. This patch removes them.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757958
