Commit graph

57 commits

Author SHA1 Message Date
He Junyan
ce3bf2c2ae plugin: bufferpool: use hashmap to cache dmabuf mem-surface
The old way of refer memory by bufferproxy is not a good one, since it
make the logic error prone.

Now it is established a map between surface-bufferproxy and its GstMemory,
caching the memory bound by a surface looked for the specified surface.
2020-04-04 14:21:57 +02:00
He Junyan
7701844813 plugin: bufferpool: Delete ACQUIRE_FLAG_NO_ALLOC flag.
Delete the GST_VAAPI_VIDEO_BUFFER_POOL_ACQUIRE_FLAG_NO_ALLOC flag.
In fact, no one is using that flag, and all vaapi buffers should
have GstVaapiVideoMeta.
2020-04-04 13:47:51 +02:00
U. Artie Eoff
da008baac2 vaapivideobufferpool: force video meta if sizes are different
The strides and offsets could be the same, but the allocation
size might be different (e.g. alignment).  Thus, ensure we also
set the flag to copy from VA memory to system memory when alloc
size differs.

Fixes #243
2020-03-06 12:08:44 +00:00
He Junyan
15e169fbf1 videobufferpool: don't reset surface when created internally
The bug fixing, in commit 89f202ea, just considers the case when
surface's DMABuf is set through gst_buffer_pool_acquire_buffer(),
which is typically a decoder's behavior. But vaapipostproc doesn't
provide any surface when calling gst_buffer_pool_acquire_buffer(),
thus a surface is created when GstMemory is allocated.

If the surface proxy in buffer's meta is reset at
buffer_pool_reset_buffer(), that surface will be destroyed and it
won't be available anymore. But GstBuffers are cached in the buffer
pool and they are reused again, hence only those images are rendered
repeatedly.

Fixes: #232
2020-02-21 15:52:43 +00:00
Víctor Manuel Jáquez Leal
7f61ad7938 vaapivideobufferpool: dmabuf implies allocator
Some code can be optimized since only if the dmabuf allocator is set,
the internal flag of dmabuf is TRUE, thus there's no need to evaluate
the allocator address.
2020-02-02 18:04:35 +01:00
Víctor Manuel Jáquez Leal
62f3329455 vaapivideobufferpool: reject configuration if allocator isn't vaapi
If the requested allocator in set_config() is not a VAAPI valid one,
reject the configuration, instead of lying and using a private one.

This patch superseeds !254 and !24
2020-02-02 17:22:43 +01:00
Víctor Manuel Jáquez Leal
5eca31b5e8 vaapivideobufferpool: add explanation for allocator reconfig 2020-02-02 17:22:43 +01:00
Víctor Manuel Jáquez Leal
377dd0cc6c vaapivideobufferpool: check for vaapi meta first
If the configured meta doesn't request vaapi meta then it is not a
vaapi buffer pool. Bail out as soon as possible.
2020-02-02 17:22:43 +01:00
Víctor Manuel Jáquez Leal
ed505f5ed4 vaapivideobufferpool: turn errors into warnings
set_config() vmethod should fail gracefully, thus upstream could
negotiate another pool if possible.

Instead of sending error messages to the bus, let demote the level
to warning.
2020-02-02 17:22:43 +01:00
Víctor Manuel Jáquez Leal
4778882728 vaapivideobufferpool: Reuse internal allocator is possible.
Instead of creating a new allocator when upstream requests a different
allocator, this patch tries to reuse the internal allocator if it was
already initializated.

If the stream changes, then either one will be unref and a new
allocator is created.
2020-01-27 20:31:12 +00:00
Víctor Manuel Jáquez Leal
9fa177951e vaapivideobufferpool: Log messages in proper category.
The log messages where logged in the GstBufferPool category because
the instance was not properly casted. This fix that situation.
2020-01-27 19:08:37 +01:00
Víctor Manuel Jáquez Leal
0815899121 vaapivideobufferpool: validate returned meta
Validate if the meta returned by gst_buffer_get_vaapi_video_meta() in
the acquired buffer is not null.

This situation should be very "pathological", but still it is better
be safe since that meta might be used later to create a new dma
buffer.
2020-01-24 11:55:22 +01:00
Philipp Zabel
89f202ea2e vaapivideobufferpool: always update/release the underlying surface proxy
gst_vaapi_video_buffer_pool_reset_buffer() is called when the sink
releases the last reference on an exported DMA buffer. This should
release the underlying surface proxy. To avoid releasing the wrong
surface due to a stale surface proxy reference in the buffer's
GstVaapiVideoMeta, always update the reference to the correct surface
in gst_vaapi_video_buffer_pool_acquire_buffer().
2020-01-24 09:10:44 +00:00
Tim-Philipp Müller
4f32a72675 Update for g_type_class_add_private() deprecation in recent GLib 2018-06-24 13:07:20 +02:00
Víctor Manuel Jáquez Leal
b1d8c68921 vaapibufferpool: declare parameter display as object
We have neglected to update this code since GstVaapiDisplay turned
into a GstObject descendant.

https://bugzilla.gnome.org/show_bug.cgi?id=796470
2018-06-14 16:41:00 +02:00
Víctor Manuel Jáquez Leal
bcc480b70e vaapibufferpool: add gst_vaapi_video_buffer_pool_copy_buffer()
This function will inform the element if it shall copy the generated
buffer by the pool to a system allocated buffer before pushing it
to downstream.

https://bugzilla.gnome.org/show_bug.cgi?id=785054
2018-02-20 10:57:12 -06:00
Víctor Manuel Jáquez Leal
ad705cc5a3 vaapibufferpool: don't change config when forcing video meta
VA-API based buffer might need a video meta because of different
strides. But when donwstream doesn't support video meta we need to
force the usage of video meta.

Before we changed the buffer pool configuration, but actually this
is a hack and we cannot rely on that for downstream.

This patch add a check fo raw video caps and allocator is VA-API,
then the option is enabled without changing the pool configuration.
In this case the element is responsible to copy the frame to a
simple buffer with the expected strides.

https://bugzilla.gnome.org/show_bug.cgi?id=785054
2018-02-20 10:57:12 -06:00
Víctor Manuel Jáquez Leal
de0f8936f8 vaapivideobufferpool: don't shift by negative since it's undefined
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.
2017-08-01 17:39:04 +02:00
Víctor Manuel Jáquez Leal
7d7f722a18 vaapivideobufferpool: fix regression with video metas
There is another regression with 7a206923 when setting the video
info for the video meta, it should be the one from the image's
allocator rather from the allocation caps.

Test pipeline:

  gst-launch-1.0 filesrc location=bug766184.flv ! decodebin \
      ! tee ! videoconvert ! videoscale                     \
      ! video/x-raw, width=1920, height=1080 ! xvimagesink
2017-06-23 17:51:04 +02:00
Víctor Manuel Jáquez Leal
05a41009f2 plugins: update buffer size with the one reported by allocator
There is a regression in 7a206923, since the buffer pool ditches all
the buffers generated by them because the pool config size is
different of the buffer's size.

Test pipeline:

  gst-launch-1.0 filesrc location=big_buck_bunny_1080p_h264.mov \
      ! qtdemux ! vaapih264dec ! vaapipostproc ! xvimagesink    \
      --gst-debug=GST_PERFORMANCE:5

The allocator may update the buffer size according to the VA surface
properties. In order to do this, the video info is modified when the
allocator is created, which reports through the allocation info the
updated size, and set it to the pool config.
2017-06-23 17:49:38 +02:00
Víctor Manuel Jáquez Leal
bd0209228b vaapivideobufferpool: remove allocation_vinfo private attribute
There is no need to keep this attribute internally since it is
already managed by the allocator.

https://bugzilla.gnome.org/show_bug.cgi?id=783599
2017-06-12 18:41:14 +02:00
Víctor Manuel Jáquez Leal
60158c3d6b vaapivideobufferpool: refactor set_config()
Refactor the set_config() virtual method considering a cleaner
approach to allocator instanciation, if it it not set or if it is
not valid for the pool.

https://bugzilla.gnome.org/show_bug.cgi?id=783599
2017-06-12 18:41:14 +02:00
Víctor Manuel Jáquez Leal
7a20692364 plugins: distinguish allocation and negotiation caps
The vaapi video decoders might have different allocation caps from
the negotiation caps, thus the GstVideoMeta shall use the negotiation
caps, not the allocation caps.

This was done before reusing gst_allocator_get_vaapi_video_info(),
storing there the negotiation caps if they differ from the allocation
ones, but this strategy felt short when the allocator had to be reset
in the vaapi buffer pool, since we need both.

This patch adds gst_allocator_set_vaapi_negotiated_video_info() and
gst_allocator_get_vaapi_negotiated_video_info() to store the
negotiated video info in the allocator, and distinguish it from
the allocation video info.

https://bugzilla.gnome.org/show_bug.cgi?id=783599
2017-06-12 18:41:14 +02:00
Víctor Manuel Jáquez Leal
45faeb25e8 vaapivideobufferpool: rename local variables
Renamed local video info structure names in set_config() vitual
method. The purpose of their renaming is to clarify the origin
of those structures, whether come from passed caps parameter
(new_allocation_vinfo) or from the configured allocator
(allocator_vinfo).

https://bugzilla.gnome.org/show_bug.cgi?id=783599
2017-06-09 17:10:34 +02:00
Víctor Manuel Jáquez Leal
dce7a6f46b vaapivideobufferpool: rename video info structures
Renamed private GstVideoInfo structure video_info to allocation_vinfo
and alloc_info to negotiated_vinfo.

The purpose of these renaming is to clarify the origin and purpose of
these private variables:

video_info (now allocation_vinfo) comes from the bufferpool
configuration. It describes the physical video resolution to be
allocated by the allocator, which may be different from the
negotiated one.

alloc_info (now vmeta_vinfo) comes from the negotiated caps in
the pipeline. It represents how the frame is going to be mapped
using the video meta.

In Intel's VA-API backend, the allocation_vinfo resolution is
bigger than the negotiated_info.

https://bugzilla.gnome.org/show_bug.cgi?id=783599
2017-06-09 17:10:34 +02:00
Hyunjun Ko
cce5ce4a9d vaapivideobufferpool: fix leak of created allocator
Since it's created by itself, it should be unref-counted
after gst_buffer_pool_config_set_allocator call. Afterwards,
this allocator will be ref-counted again when assigning to priv->allocator.

https://bugzilla.gnome.org/show_bug.cgi?id=781577
2017-04-27 11:03:02 +02:00
Víctor Manuel Jáquez Leal
158b44fc1e vaapivideobufferpool: create or reconfig allocator
Sometimes a video decoder could set different buffer pool
configurations, because their frame size changes. In this case we
did not reconfigure the allocator.

This patch enables this use case, creating a new allocator inside
the VAAPI buffer pool if the caps changed, if it is not dmabuf-based.
If so, it is just reconfigured, since it doesn't have a surface pool.

https://bugzilla.gnome.org/show_bug.cgi?id=781577
2017-04-25 15:06:39 +02:00
Julien Isorce
9ed73e76af vaapivideobufferpool: override acquire_buffer()
Overriding the vmethod acquire_buffer() it is possible to attach the
right GstMemory to the current acquired buffer.

As a matter of fact, this acquired buffer may contain any instantiated
GstFdmemory, since this buffer have been popped out from the buffer
pool, which is a FIFO queue. So there is no garantee that this buffer
matches with the current processed surface. Evenmore, the VA driver
might not use a FIFO queue. Therefore, it is no way to guess on the
ordering.

In short, acquire_buffer on the VA driver and on the buffer pool return
none matching data, we have to manually attach the right GstFdMemory to
the acquired GstBuffer. The right GstMemory is the one associated with
the current surface.

https://bugzilla.gnome.org/show_bug.cgi?id=755072
2017-02-03 16:18:08 +01:00
Julien Isorce
6a0375d96e vaapivideomemory: export surface if it is provided
gst_vaapi_dmabuf_memory_new() always exports a surface. Previously, it
had to create that surface. Now it can also export an already provided
surface. It is useful to export decoder's surfaces (from VA context).

https://bugzilla.gnome.org/show_bug.cgi?id=755072
2017-02-02 20:33:36 +01:00
Julien Isorce
aca43dab47 vaapivideobufferpool: set correct buffer size
We should set the correct buffer size when we are configuring the pool,
otherwise the buffer will be discarded when it returns to the pool.

Indeed when the ref-count of a buffer reaches zero, its pool will queue
it back (and ref it) if, and only if, the buffer size matches the
configured buffer size on the pool.

This issue can be debugged with GST_DEBUG=*PERF*:6, see gstbufferpool.c

https://bugzilla.gnome.org/show_bug.cgi?id=774782
2016-11-21 16:37:31 +01:00
Scott D Phillips
b5bf2e83f7 vaapivideobufferpool: add video meta to config when needed
In cases where we know the video meta must be present, add it to
the pool configuration.

Signed-off-by: Scott D Phillips <scott.d.phillips@intel.com>

https://bugzilla.gnome.org/show_bug.cgi?id=766184
2016-06-15 15:44:00 +02:00
Víctor Manuel Jáquez Leal
6c5b6232da vaapivideobufferpool: share options flag with pluginbase
Originally, vaapivideobufferpool has a set of boolean variables for the
buffer configuration options.

This pach changes these boolean variables for a single bitwise, just as
it is used in pluginbase. Hence, the internal enum was moved to
vaapivideobufferpool header.

https://bugzilla.gnome.org/show_bug.cgi?id=765435
2016-06-08 10:19:01 +02:00
Víctor Manuel Jáquez Leal
50b2423a2b pluginbase negotiates allocator with bufferpool
Originally vaapivideobufferpool instantiates its own allocator regardless the
received configuration, and it relies in custom configuration options to
choose which kind of allocator instantiate.

This patch transfers the responsibility of the allocator instantiate to
vaapipluginbase and pass it to the vaapivideobufferpool through its
configuration.

* gst/vaapi/gstvaapipluginbase.c
  + set_dmabuf_allocator(): inserts a dmabuf allocator in the bufferpool
  + ensure_sinkpad_buffer_pool(): set a normal vaapi video allocator in
    bufferpool configuration
  + gst_vaapi_plugin_base_propose_allocation(): call set_dmabuf_allocator() if
    needed.
  + gst_vaapi_plugin_base_decide_allocation(): set a normal vaapi video
    allocator in bufferpool configuration
* gst/vaapi/gstvaapivideobufferpool.c
  + gst_vaapi_video_buffer_pool_set_config(): instead of instantiate the
    allocator, process the received one through its configuration.
* gst/vaapi/gstvaapivideobufferpool.h: removed
  GST_BUFFER_POOL_OPTION_DMABUF_MEMORY since it is not used anymore.
* gst/vaapi/gstvaapivideomemory.c
  + gst_vaapi_is_dmabuf_allocator(): new helper function to identify a dmabuf
    allocator with the vaapi qdata.

https://bugzilla.gnome.org/show_bug.cgi?id=765435
2016-06-08 10:19:01 +02:00
Víctor Manuel Jáquez Leal
2643ae980a vaapivideobufferpool: keep only current video info
Instead of keeping old and new GstVideoInfo video structure, we only keep one,
the current one, the negotiated. The old one is not needed at all.

https://bugzilla.gnome.org/show_bug.cgi?id=765435
2016-06-08 10:19:01 +02:00
Víctor Manuel Jáquez Leal
2562cd51be pluginutil: add gst_video_info_changed() helper
This function is shared among different elements, so let factorized it.

https://bugzilla.gnome.org/show_bug.cgi?id=765435
2016-06-08 10:19:01 +02:00
Víctor Manuel Jáquez Leal
21b184284b vaapivideobufferpool: split caps validation
When validating the caps from bufferpool config, this patch distinguishes the
error from no caps received (NULL) from the invalid caps (cannot be converted
into GstVideoInfo structure).
2016-05-24 10:33:18 +02:00
Víctor Manuel Jáquez Leal
1769da4957 vaapivideobufferpool: relate errors to instance
Use GST_ERROR_OBJECT instead of GST_ERROR, thus the logs will show the name of
the vaapivideobufferpool instance that failed.
2016-05-19 13:21:37 +02:00
Julien Isorce
240fc0f726 vaapibufferpool: do not create texture upload meta if dmabuf
https://bugzilla.gnome.org/show_bug.cgi?id=755072
2016-05-09 12:53:21 +01:00
Sreerenj Balachandran
b4154ac85c gst/vaapi: Switch to upstreram like indentation.
gst-indent for all gst/vaapi/*.c source files
2015-06-30 09:44:18 +03:00
Olivier Crete
be37f45998 videopool: Free members before chaining up finalize
The finalize function in GObject frees the object memory, so
everything else needs to have been freed before.

https://bugzilla.gnome.org/show_bug.cgi?id=748563
2015-04-28 11:16:02 +02:00
Víctor Manuel Jáquez Leal
8b36e25f47 Removal of gstreamer-1.0 support
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>
2015-04-03 17:09:08 +03:00
Víctor Manuel Jáquez Leal
c561b8da8a update and move gstcompat.h
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>
2015-04-03 17:08:30 +03:00
Gwenole Beauchesne
60e96e80cc plugins: add initial support for EGL.
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
2015-02-24 15:20:03 +01:00
Gwenole Beauchesne
82fc406dfd plugins: add support for dma_buf exports (v4l2src).
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
2015-01-28 17:36:21 +01:00
Gwenole Beauchesne
96ce1bc761 videopool: add optional flags for surface pool allocation.
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.
2015-01-27 18:11:45 +01:00
Gwenole Beauchesne
1ef5a3a200 plugins: allow bufferpool to not allocate vaapi video meta.
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.
2014-08-22 15:54:32 +02:00
Gwenole Beauchesne
038d56bdca plugins: re-indent all GstVaapiVideo* related source code. 2014-08-22 15:54:32 +02:00
Gwenole Beauchesne
cafb25c4d1 vaapidecode: add support for VideoAlignment bufferpool option.
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.
2014-07-25 15:52:06 +02:00
Gwenole Beauchesne
c2eabc17dd plugins: allow builds without GLX enabled for GStreamer 1.2.
Don't try to build GLTextureUploadMeta related code if GLX is not
enabled during GStreamer >= 1.2 builds.
2013-12-11 15:30:51 +01:00
Matthieu Bouron
6b6c10d94d plugins: request GLTextureUpload meta on buffers in the buffer pool.
Requesting the GLTextureUpload meta on buffers in the bufferpool
prevents such metas from being de-allocated when buffers are released
in the sink.

This is particulary useful in terms of performance when using the
GLTextureUploadMeta API since the GstVaapiTexture associated with
the target texture is stored in the meta.

https://bugzilla.gnome.org/show_bug.cgi?id=712558

Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
2013-12-11 15:30:51 +01:00