Implement GstVaapiTextureMap object, which caches VAAPI textures, so them can be
reused. Internally it is a hash table.
Note that it is GstObject based rather than GstVaapiObject, as part of the future
converstion to GstObject of most of the code.
https://bugzilla.gnome.org/show_bug.cgi?id=769293
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
We are not getting enough compression for some streams and
encoded frame end up with more size than allocated.
Assuming a compression ratio of 4, which should be good enough
for holding the frames.
https://bugzilla.gnome.org/show_bug.cgi?id=771528
While doing the mode-1 referece picture selection,
the circular buffer logic was not correctly setting the
refresh frame flags as per VP9 spec.
Make sure refresh_flag[0] get updated correclty after
each cycle of GST_VP9_REF_FRAMES.
https://bugzilla.gnome.org/show_bug.cgi?id=771507
When the format of a H.264 stream is AVC3, the SPS and PPS are inside the
stream, not in the codec_data, so the size of codec_data might be 7.
This patch reduces the minimal size of the codec_data buffer from 8 to 7.
https://bugzilla.gnome.org/show_bug.cgi?id=771441
set_format() is called by upstream when the stream capabilites has changed.
Before, if the new stream is compatible with the old one the VA decoder was
not destroyed. Nonetheless, with this behavoir, the VA decoder ignores
when the upstreamer parsers gets more details of the stream, such as the
framerate. Hence, when the src caps are negotiates, the further sink caps
updates are ignored.
This patch forces the VA decoder destroying and recreation when set_format()
is called.
https://bugzilla.gnome.org/show_bug.cgi?id=770921
When calling gst_video_frame_map() with GST_MAP_WRITE flag, it doesn't call
ensure_image_is_current(), which means it doesn't guarentee VAImage is valid
in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=766978
In commit 2eb4394 the frame coding mode was verified for progressive
regardless the profile. But the FCM is only valid in the advanced
profile. This patch checks for the advanced profile before verifying FCM for
progressive.
https://bugzilla.gnome.org/show_bug.cgi?id=769250
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
In the earlier patch:
f31d9f3 decoder: vc1: Print error on interlaced content
Decoding would error out if the interlace flag was set in the
sequence bdu. This isn't quite right because a video can have this
flag set and yet not have any interlaced pictures.
Here instead we error out when either parsing a field bdu or
decoding a frame bdu which has fcm set to anything other than
progressive.
Signed-off-by: Scott D Phillips <scott.d.phillips@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=769250
Validate that fps numerator is non-zero so it can be used to calculate
the duration of the B frame.
Also it gst_util_uint64_scale() is used instead of normal arithmetic in
order to aviod overflows, underflows and loss of precision.
https://bugzilla.gnome.org/show_bug.cgi?id=768458
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
Check earlier if upstream video source has activated the dmabuf-import
io-mode (hack to disappear soon), thus we can avoid the re-assignation of a
new allocator.
Add the method gst_allocator_get_vaapi_image_size() for the
GstVaapiVideoAllocator, which gets the size of the allocated images with the
current video info.
This method replaces the direct call to the allocator's image info when the
pool is configured.
Depends on media, video size is sometimes updated with new allocator.
It leads to dismatch between bufferpool's set size and real allocated buffer size.
In this case, it causes every buffer is freed during release in bufferpool,
which should be reused. This affects performance.
https://bugzilla.gnome.org/show_bug.cgi?id=769248
Some invocations of PKG_CHECK_MODULES were intended to be non-fatal if
the package is missing, but action-if-not-found was given as an empty
string which still causes the default action to run, which halts
execution.
Signed-off-by: Scott D Phillips <scott.d.phillips@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=769237
Since the upstream of gstreamer-vaapi, the library is not a public shared
object anymore. But the EGL support depended on this dynamic library, so the
EGL support was broken.
This patch removes the dynamic library loading code and instantiates the
EGL display using either X11 or Wayland if available.
https://bugzilla.gnome.org/show_bug.cgi?id=767203
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
Split the vaapidecode to all the supported codecs with the format
vaapi{codec}dec.
vaapidecode is stil registered as a GObject type, but not as a
GStreamer feature, so it can be used internally by vaapidecodebin without
changing its code too much.
https://bugzilla.gnome.org/show_bug.cgi?id=734093
Since the elements dependant of the VA video processor are now only registered
if it is available, vaapidecodebin code can be simplified a lot, removing all
the code required to check if the VA video processor was available.
https://bugzilla.gnome.org/show_bug.cgi?id=768899
Delay the GstVaapiDisplay instantiating until when changing the state from
READY to PAUSE. In this way the element has more chances to find an already
created GstVaapiDisplay, or a GL context, in the pipeline.
https://bugzilla.gnome.org/show_bug.cgi?id=766206
The function gst_vaapi_create_display_from_gl_context() cretes a
GstVaapiDisplay given a GstGLContext. But it didn't created a GLX VA display
when the GL platform was GLX, but a plain X11 VA display.
This patch fixes that, by querying the GL platform earlier.
https://bugzilla.gnome.org/show_bug.cgi?id=766206
Using the GstContext mechanism, it is possible to find if the pipeline
shares a GstGLContext, even if we are not to negotiating GLTextureUpload
meta. This is interesting because we could negotiate system memory caps
feature, but enable DMABuf if the GstGLContext is EGL with some extensions.
https://bugzilla.gnome.org/show_bug.cgi?id=766206
Since the driver checkup is done at registering, there is no need to do it
when changing the element state from NULL to READY. This patch remove this
vmethod from vaapidecode.
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
Move some of the logic in gst_vaapi_plugin_base_driver_is_whitelisted() to a
new function gst_vaapi_driver_is_whitelisted(), in this way, it can be used
when registering the plugin's feature set with the test VA display.
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
This reverts commit 1dbcc8a0e1 and commit
372a03a9e3.
While the dmabuf handle is exported, the derive image must exist, otherwise
the image's VA buffer is invalid, thus the dmabuf handle is never released,
leading into a file descriptors leak.
