VPP support is only needed for advanced deinterlacing, which is not
enabled by default either. Error out if it is selected but VPP is not
supported, and otherwise just work without VPP support.
https://bugzilla.gnome.org/show_bug.cgi?id=788758
When creating the test display for querying capabilites, it try in
certain order: DRM, Wayland and finally X11. GLX nor EGL are tried
since they are either composited with X11 or Wayland.
The reason for this is to reduce the posibility of failure that could
blacklist the plugin.
https://bugzilla.gnome.org/show_bug.cgi?id=782212
We returned FALSE from ::start() if VPP support is not available, but it
is only really needed for complex filters and during transform we check
for that. For simple deinterlacing it is not needed.
Instead of reusing a parameter variable for the return value of
gst_vaapipostproc_transform_caps(), this patch uses the function
scoped pointer. Thus, the code is cleaner.
https://bugzilla.gnome.org/show_bug.cgi?id=785706
Instead of reusing a parameter variable for the return value of
gst_vaapipostproc_fixate_caps(), this patch uses the function scoped
pointer. Thus, the code is cleaner.
https://bugzilla.gnome.org/show_bug.cgi?id=785706
When glimagesink negotiates the caps feature memory:DMABuf the
exported dmabufs buffers with NV12 format are not well rendered, thus
setting only planar.
https://bugzilla.gnome.org/show_bug.cgi?id=788229
Instead of using gst_vaapi_display_set_property() or
gst_vaapi_display_get_property(), this patch set replace it usage
with g_object_set() or g_object_get().
Also the internal helper cb_set_value() is removed since it is not
used anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=788058
Make sure vaapisink create a va surface backed buffer pool and all
required attributes get assigned correctly for drm display type.
This is needed to make the below pipeline working:
gst-launch-1.0 filesrc location= raw_video.mov ! videoparse format=uyvy
width=320 height=240 framerate=30/1 ! vaapisink display=drm
https://bugzilla.gnome.org/show_bug.cgi?id=786954
A new FEI based encoder element for h264 is added: vaapih264feienc
FEI is a an extension to VA-API which is providing low level
advanced control over different stages of encoding.
Extending vaapih264enc with fei support is possible, but it will
make the code too much complicated and will be difficult
to debug. So adding the new encoder element, but keeping
the rank as 0 , vaapih264enc will stay as the primary
encoder for normal use cases.
The vaaih264feienc is mainly useful for customers who want to play
with MotionVectors and Macroblock Predictions. Also user can
do one stage of encoding(eg: only the Motion Vector Calculation)
in software and offload trasformation/entroy-coding etc to
Hardware (which is what PAK module is doing) using FEI element.
vaapih264feienc can work in different modes using fei-mode properoty
eg: gst-launch-1.0 videotestsrc ! vaapih264feienc fei-mode=ENC+PAK ! filesink location=sample.264
Important Note: ENC only mode won't produce any encoded data which is expected.
But ENC alwys requires the output of PAK in order to do the inter-prediction
over reconstructed frames.
Similary PAK mode alway requires MV and MBCode as input, so unless there is an
upstream element providing those buffers, PAK only won't work as expected.
In a nutshell, ENC_PAK and the ENC+PAK modes are the only options we can verify
with vaapih264feienc. But ideally, EN+PAK mode verification is enough to make sure
that ENC and PAK are working as expected since ENC+PAK mode always invoke ENC and PAK
separately in vaapih264feienc.
People contributed:
Wang, Yi <yi.a.wang@intel.com>
Leilei <leilei.shang@intel.com>
Zhong, Xiaoxia <xiaoxia.zhong@intel.com>
xiaominc <xiaomin.chen@intel.com>
Li, Jing B <jing.b.li@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=785712https://bugzilla.gnome.org/show_bug.cgi?id=784667
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
When vaapih264dec's base-only profile is set to TRUE, fake SVC profile
support in caps.
https://bugzilla.gnome.org/show_bug.cgi?id=732266
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
Instead including particular gstgl header files in a header file
that doesn't export a gstgl symbol, the main gstgl header file is
included in gstvaapipluginutil.c where the symbols are used.
https://bugzilla.gnome.org/show_bug.cgi?id=786597
Coverity scan bug:
An unsigned value can never be negative, so this test will always
evaluate the same way.
As len is guint32, there is no need to check it if it is equal or
bigger than zero.
Coverity scan bug:
The variable will contain an arbitrary value left from earlier
computations.
Variable base_only is fetched from base-only property, and it may be
not assigned. It needs to be initialized.
Refactor gst_vaapi_plugin_base_create_gl_context() in order to check
the return value of gst_gl_ensure_element_data(). The result is a code
bit cleaner.
The function g_bit_nth_lsf() may return -1 if the request bit position
is not avaible. Thus, this patch check if the return value is not -1
in order to continue.
Replacing GstVaapiDisplay during rendering might be hiding problems
at some cases, even though it's safe currently since we use cache
of GstVaapidisplay.
Play safe by failing if this happens.
https://bugzilla.gnome.org/show_bug.cgi?id=766704
Through "gst.vaapi.app.Display" context, users can set their own VADisplay
and native display of their backend.
Attributes:
- display : pointer of VADisplay
- x11-display : pointer of X11 display (Display *), if they're using.
This patch creates GstVaapidisplayX11 if information provided through
"gst.vaapi.app.Display"
https://bugzilla.gnome.org/show_bug.cgi?id=766704
So far vaapi encoder does not set profile to src caps. This patch makes it
setting profile to src caps, which is determined by itself.
In addition, if encoder chose different profile, which is not negotiated with
downstream, we should set compatible profile to make negotiation working.
https://bugzilla.gnome.org/show_bug.cgi?id=757941
Check if the requested profile in source caps, is supported by the
VA driver. If it is not, an info log message is send saying that
another (compatible?) profile will be used.
https://bugzilla.gnome.org/show_bug.cgi?id=757941
First check if downstream requests ANY caps. If so, byte-stream is
used and the profile will be choose by the encoder. If dowstream
requests EMPTY caps, the negotiation will fail.
Lately, byte-stream and profile are looked in the allowed caps.
https://bugzilla.gnome.org/show_bug.cgi?id=757941
The check for avc stream format was done in the vaapi encoder's
vmethod get_caps(), but that is wrong since it has to be check
when encoder set_format().
https://bugzilla.gnome.org/show_bug.cgi?id=757941
vaapipostproc didn't negotiate the proper multiview caps losing
downstream information.
This patch enables the playing of MVC encoded stream by setting
the proper multiview mode/flags and views to src caps, according
to sink caps.
https://bugzilla.gnome.org/show_bug.cgi?id=784320
