iHD doesn't provide a full implemention for rendering surfaces and
i965 has problems in wayland. And I suspect this path is followed
by other driver implementations.
This patch demotes the rank of vaapisink to secondary, so it will
not be autoplugged avoiding bad experience of users.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/336>
I've just discovered iHD driver in Skylake doesn't have VideoProc
entry point, hence, in this platform, when vaapioverlay is tried to be
registered, critical warnings are raised because blend doesn't have a
display assigned.
As it is possible to have drivers without EntryPointVideoProc it is
required to handle it gracefully. This patch does that: only tries to
register vaapioverlay if the testing display has VPP and finalize()
vmethods, in filter and blend, bail out if display is NULL.
FEI encoders are not actively mantained neither tested, and it is
using infrastructure that is changing and FEI is stopping this
effort.
Also it is required to rethink how FEI can be used in GStreamer.
A plugin similar to the base compositor element but
uses VA-API VPP blend functions to accelerate the
overlay/compositing.
Simple example:
gst-launch-1.0 -vf videotestsrc ! vaapipostproc \
! tee name=testsrc ! queue \
! vaapioverlay sink_1::xpos=300 sink_1::alpha=0.75 \
name=overlay ! vaapisink testsrc. ! queue ! overlay.
vaapsink, when used with the Intel VA-API driver, tries to display
surfaces with format NV12, which are handled correctly by
Weston. Nonetheless, COGL cannot display YUV surfaces, making fail
pipelines on mutter.
This shall be solved either by COGL or by making the driver to paint
RGB surfaces. In the meanwhile, let's just demote vaapisink as
marginal when the Wayland environment is detected, no matter if it is
Weston.
https://bugzilla.gnome.org/show_bug.cgi?id=775698
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
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>
In a multiple video cards system, a X11 environment may have different VA
capabilities. This patch tracks the DISPLAY environment variable to
invalidates the GStreamer features cache. Also tracks WAYLAND_DISPLAY.
https://bugzilla.gnome.org/show_bug.cgi?id=770357
Encoders claim to support a whole bunch of input formats but then
just error out if the format is not actually supported, even if
there's a converter in front. This means they're not fit for
autoplugging in encodebin or camerabin yet and therefore should
not have a rank. People can still use them in custom pipelines.
https://bugzilla.gnome.org/show_bug.cgi?id=769266
In order to register only the available decoders, this patch queries the
created test VA display, which uses the currently used back-end (X11, Wayland,
DRM, …) on the used display device.
https://bugzilla.gnome.org/show_bug.cgi?id=724352
In order to register only the available encoders, this patch queries the
created test VA display, which uses the currently used back-end (X11,
Wayland, DRM, …) on the used display device.
https://bugzilla.gnome.org/show_bug.cgi?id=724352
Query the GstVaapiDisplay to know if the driver supports video
postprocessing. If does, then register vaapipostproc and vaapidecodebin
elements.
This patch will simplify the design of vaapidecodebin.
https://bugzilla.gnome.org/show_bug.cgi?id=724352
This patch tries to instantiate a GstVaapiDisplay when registering the plugin
features, if it fails, no gstreamer-vaapi element is registering.
The purpose of this patch is to avoid a situation where the user has
gstreamer-vaapi installed but their VA-API setup is not functional, which may
lead to unexpected behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=724352
There are two main external dependencies that define the feature set of this
plugin: a) the kernel and b) the VA driver
This patch tracks both dependencies, if any of them change, GStreamer will
re-inspect the plugin.
The kernel is tracked through the device files /dev/dri/card*
The VA driver is tracked through the files VA_DRIVERS_PATH/*_drv_video.so,
where VA_DRIVERS_PATH is the one defined in libva package configuration. Also,
the environment variables LIBVA_DRIVERS_PATH and LIBVA_DRIVER_NAME are tracked
since they modify the driver lookup.
Additionally, the environment variable GST_VAAPI_ALL_DRIVERS is tracked too.
https://bugzilla.gnome.org/show_bug.cgi?id=724352
Though USE_{JPEG,VP8,VP9,H265}_ENCODER macros definition depend on USE_ENCODER
macro, it is clearer to nest them, showing explicitly the dependency relation.
Don't expose the the vaapidecode GType, instead expose a function
which will register element.
This is the first step to split the decoder by codecs.
https://bugzilla.gnome.org/show_bug.cgi?id=734093
Trying to comply with GStreamer's element names, this patch renames the
encoders using the name format vaapi{codec}enc.
In this way, the plugin documentation is linked correctly.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
As gstreamer-vaapi now only supports from GStreamer 1.6, this patch removes
all the old GStreamer version guards.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@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>
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>
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
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
Add GstVaapiEncodeMPEG2 element object. The actual plug-in element
is called "vaapiencode_mpeg2".
Valid properties:
- rate-control: rate control mode (default: cqp - constant QP)
- bitrate: desired bitrate in kbps (default: auto-calculated)
- key-period: maximal distance between two key frames (default: 30)
- max-bframes: number of B-frames between I and P (default: 2)
- quantizer: constant quantizer (default: 8)
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Add GstVaapiEncodeH264 element object. The actual plug-in element
is called "vaapiencode_h264".
Valid properties:
- rate-control: rate control mode (default: none)
- bitrate: desired bitrate in kbps (default: auto-calculated)
- key-period: maximal distance between two key frames (default: 30)
- num-slices: number of slices per frame (default: 1)
- max-bframes: number of B-frames between I and P (default: 0)
- min-qp: minimal quantizer (default: 1)
- init-qp: initial quantizer (default: 26)
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Port vaapipostproc element to GStreamer 1.2. Support is quite minimal
right now so that to cope with auto-plugging issues/regressions. e.g.
this happens when the correct set of expected caps are being exposed.
This means that, currently, the proposed caps are not fully accurate.
Port vaapidecode and vaapisink plugins to GStreamer API >= 1.2. This
is rather minimalistic so that to test the basic functionality.
Disable vaapipostproc plugin for now as further polishing is needed.
Also disable GstVideoContext interface support since this API is now
gone in 1.2.x. This is preparatory work for GstContext support.
https://bugzilla.gnome.org/show_bug.cgi?id=703235
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Add support for interlaced streams with GStreamer 1.0 too. Basically,
this enables vaapipostproc, though it is not auto-plugged yet. We also
make sure to reply to CAPS queries, and happily handle CAPS events.
Fix the name of the plug-in element reported to gst-inspect-1.0. i.e. we
need an explicit definition for GStreamer >= 1.0 because the GST_PLUGIN_DEFINE
incorrectly uses #name for creating the plug-in name, instead of using macro
expansion (and let further expansion of macros) through e.g. G_STRINGIFY().
Introduce a new configure option --with-gstreamer-api that determines
the desired GStreamer API to use. By default, GStreamer 1.0 is selected.
Also integrate more compatibility glue into gstcompat.h and plugins.
Port vaapidecode and vaapisink plugins to GStreamer API >= 1.0. This
is rather minimalistic so that to test the basic functionality.
Disable vaapiupload, vaapidownload and vaapipostproc plugins. The latter
needs polishing wrt. to GStreamer 1.x functionality and the former are
totally phased out in favor of GstVaapiVideoMemory map/unmap facilities,
which are yet to be implemented.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
