Commit graph

41 commits

Author SHA1 Message Date
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
8b91ddac0b plugins: fix allocation of DMABUF memory.
The dmabuf allocator would close the DMABUF handle passed in the init
function gst_dmabuf_allocator_alloc(). So, we need to dup() it so that
to avoid a double close, ultimately in the underlying driver that owns
the DMABUF handle.
2015-03-02 13:41:29 +01:00
Víctor Manuel Jáquez Leal
671b1ea305 Fix compiler warnings
This patch fixes some warnings that gcc 4.9 reports.

https://bugzilla.gnome.org/show_bug.cgi?id=744411
2015-02-18 11:46:11 +02: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
09dcb1e0f7 vaapivideomemory: don't crash when trying to allocate 0x0 images.
In some occasions, a buffer pool is created for pre-initialization
purposes regardless of whether a valid image size is available or
not. However, during actual decode stage, the vaapidecode element
is expected to update the srcpad caps with the new dimensions, thus
also triggering a reset of the underlying bufferpool.
2015-01-15 17:13:52 +01:00
Gwenole Beauchesne
cf352336b3 plugins: further fixes to the new "current" storage tracker.
The ensure_surface() and ensure_image() functions shall only relate
to the underlying backing store. The actual current flags are to be
updated only through ensure_{surface,image}_is_current() or very other
particular cases in GstMemory hooks.
2014-11-24 13:20:33 +01:00
Gwenole Beauchesne
5fd643bf49 plugins: fix "current" video memory flags.
If the surface proxy is updated into the GstVaapiVideoMemory, then
it is assumed it is the most current representation of the current
video frame. Likewise, make a few more arrangements to have the
"current " flags set more consistently.
2014-11-21 15:50:35 +01:00
Gwenole Beauchesne
ceb60285ea plugins: ensure VA surface is current prior to using it.
When interacting with SW elements, the buffers and underlying video
memory could be mapped as read/write. However, we need to use those
buffers again as plain VA surfaces, we have to make sure the VA image
is thus committed back to VA surface memory.

This fixes pipelines involving avdec_* and vaapi{postproc,sink}.
2014-11-21 15:29:33 +01:00
Víctor Manuel Jáquez Leal
0e87abc574 plugins: enable memory maps for read & write.
Hence vaapisink can display buffers decoded by gst-libav, or HW decoded
buffers can be further processed in-place, e.g. with a textoverlay.

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

[ported to current git master branch, amended commit message]
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
2014-11-19 10:36:27 +01:00
Sreerenj Balachandran
aa4d1f5a1e vaapivideomemory: avoid NULL pointer unref if GstVaapiImage creation failed.
https://bugzilla.gnome.org/show_bug.cgi?id=735156
2014-08-22 15:54:32 +02: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
1d1be0ae76 vaapivideomemory: always prefer native VA surface formats.
Make sure to always prefer native internal formats for the VA surfaces
that get allocated. Also disable "direct-rendering" mode in this case.

This is needed so that to make sure that anything that gets out of the
decoder, or anything that gets into the encoder, is in native format
for the hardware, and thus the driver doesn't need to perform implicit
conversions in there. Interop with SW elements is still available with
fast implementations of VA imaging APIs.
2014-07-25 15:44:58 +02:00
Gwenole Beauchesne
e0e869f536 vaapivideomemory: disallow memory shares across buffers, use a copy.
Forbid shares of GstMemory instances, and rather make copy of it. This
effectively copies the GstMemory structure and enclosed metadata, but
this does not copy the VA surface contents itself. It should though.

This fixes preroll and makes sure to not download garbage for the first
frame when a SW rendering sink is used.
2014-07-24 11:58:29 +02:00
Gwenole Beauchesne
3a762284a2 vaapivideomemory: use an image pool to cache objects.
Use an image pool to hold VA images to be used for downloads/uploads
of contents for the associated surface.

This is an optmization for size. So, instead of creating as many VA
images as there are buffers (then VA surfaces) allocated, we only
maintain a minimal set of live VA images, thus preserving memory
resources.
2014-07-24 06:55:26 +02:00
Gwenole Beauchesne
c3643b42a4 vaapivideomemory: forbid R/W mappings if non direct-rendering mode.
Disable read-write mappings if "direct-rendering" is not supported.
Since the ordering of read and write operations is not specified,
this would require to always download the VA surface on _map(), then
commit the temporary VA image back to the VA surface on _unmap().

Some SW decoding plug-in elements still use R/W mappings though.

https://bugzilla.gnome.org/show_bug.cgi?id=733242
2014-07-24 00:14:09 +02:00
Gwenole Beauchesne
f2ce28e4b7 vaapivideomemory: minor code clean-ups.
Fix error messages introduced in the previous commit for the _map()
imaplementation. Also use the new get_image_data() helper function
to determine the base pixels data buffer from a GstVaapiImage when
updating the video info structure from it.
2014-07-23 23:53:15 +02:00
Gwenole Beauchesne
9cad85a936 vaapivideomemory: add support for raw pixels mappings.
Allow raw pixels of the whole frame to be mapped read-only. i.e. in
cases where the buffer pool is allocated without VideoMeta API, thus
individual planes cannot be mapped.

This is initial support for Firefox >= 30.

https://bugzilla.gnome.org/show_bug.cgi?id=731886
2014-07-23 19:14:47 +02:00
Sreerenj Balachandran
9cb3acc813 vaapivideomemory: fix determination of the surface pool format.
While creating the vaapi video allocator, make sure the associated
surface pool has correct format instead of defaulting to NV12 video
format even though there is no direct rendering support.

https://bugzilla.gnome.org/show_bug.cgi?id=732691
2014-07-23 18:48:32 +02:00
Gwenole Beauchesne
b07de8a7f9 vaapivideomemory: fix association of surface to proxy.
Make sure to always update the VA surface pointer whenever the proxy
changes. This used to only work when the VA surface is written to, in
interop with SW element ("upload" feature), and this now fixes cases
when the VA surface is needed for reading, in interop with SW element
("download" feature).
2014-07-23 18:01:21 +02:00
Gwenole Beauchesne
dac20cecb4 plugins: expose I420 format for interop with SW elements.
Always expose I420 format by default when the VA surface could be
mapped for interoperability with non harware accelerated elements.
However, the default behaviour remains the auto-plugging of vaapi
elements, down to the sink.

Side effect: "direct-rendering" mode is also disabled most of the
times as plain memcpy() from uncached speculative write combining
memory is not going to be efficient enough.
2014-07-23 16:25:08 +02:00
Gwenole Beauchesne
dc6d529830 plugins: allow download capability to vaapidecode element.
Fix support for VA surface download capability in vaapidecode element
for GStreamer >= 1.2. This is a fix to supporting libva-vdpau-driver,
but also the libva-intel-driver while performing hardware accelerated
conversions from the native VA surface format (NV12) to the desired
output VA image format.

For instance, this fixes pipelines involving vaapidecode ! xvimagesink.

https://bugzilla.gnome.org/show_bug.cgi?id=733243
2014-07-22 19:06:52 +02:00
Gwenole Beauchesne
84b3f84925 plugins: fix memory leaks through GstVideoMeta maps.
When GstVideoMeta maps were used, the supporting functions incorrectly
used gst_buffer_get_memory() instead of gst_buffer_peek_memory(), thus
always increasing the associated GstMemory reference count and giving
zero chance to actually release that, and subsequently the VA display.
2013-11-28 19:08:28 +01:00
Gwenole Beauchesne
15519ebe3d legal: add per-file authorship information.
Credit original authors on a per-file basis as we cannot expect people
to know all country-specific rules, or bother browsing through the git
history.
2013-11-22 06:39:15 +01:00
Gwenole Beauchesne
399e887c4f plugins: fix and optimize check for buffer pool allocator params.
Reset the buffer pool allocator only if the config caps changed in a
sensible way: format or resolution change. i.e. don't bother with
other caps like colorimetry et al. as this doesn't affect the way to
allocate VA surfaces or images.
2013-10-09 18:30:06 +02:00
Gwenole Beauchesne
77b2d88452 plugins: enable memory maps for read & write with direct-rendering.
Enable read and write mappings only if direct-rendering is supported.
Otherwise, this means that we may need to download data from the VA
surface first for correctness, even if the VA surface doesn't need to
be read at all. i.e. sometimes, READWRITE mappings are meant for
surfaces that are written to first, and read afterwards for further
processing.

https://bugzilla.gnome.org/show_bug.cgi?id=704078
2013-10-09 18:30:06 +02:00
Gwenole Beauchesne
847e3efb4d plugins: fix check for direct-rendering support.
Fix check for direct-rendering if the creation of VA surfaces with
an explicit pixel format is not support, e.g. VA-API < 0.34.0, and
that we tried to allocate a VA surface based on the corresponding
chroma type. i.e. in that particular case, we have to make sure that
the derived image has actually the expected format.
2013-10-09 18:30:06 +02:00
Gwenole Beauchesne
f361d4a23d plugins: fix buffer pool reset_buffer() to reset memory resources.
Fix GstVaapiVideoBufferPool::reset_buffer() to reset the underlying
memory resources, and more particularly the VA surface proxy. Most
importantly, the GstVaapiVideoMeta is retained. Cached surface in
memory are released, thus triggering a new allocation the next time
we need to map the buffer.
2013-10-09 18:30:06 +02:00
Gwenole Beauchesne
4df68163dc plugins: fix GstVaapiVideoMemory to allocate VA surface proxies.
Make sure GstVaapiVideoMemory allocates VA surface proxies from a
pool stored in the parent VA memory allocator.

This fixes the following scenario:
- VA video buffer 1 is allocated from a buffer pool
- Another video buffer is created, and inherits info from buffer 1
- Buffer 1 is released, thus pushing it back to the buffer pool
- New buffer alloc request comes it, this yields buffer 1 back
- At this stage, buffers 1 and 2 still share the same underlying VA
  surface, but buffer 2 was already submitted downstream for further
  processing, thus conflicting with additional processing we were
  about to perform on buffer 1.

Maybe the core GstBufferPool implementation should have been fixed
instead to actually make sure that the returned GstBuffer memory we
found from the pool is writable?
2013-10-09 18:30:06 +02:00
Gwenole Beauchesne
c82a1bc0ff plugins: fix ref counting of GstVaapiVideoMemory allocator.
Fix reference counting issue whereby gst_memory_init() does not hold
an extra reference to the GstAllocator. So, there could be situations
where the last instance of GstVaapiVideoAllocator gets released before
a dangling GstVaapiVideoMemory object, thus possibly leading to a crash.
2013-07-12 17:14:49 +02:00
Gwenole Beauchesne
1cfe03ee52 plugins: allow creation of VA surfaces with explicit pixel format.
Adapt GstVaapiVideoMemory allocator to support creation of VA surfaces
with an explicit pixel format. This allows for direct rendering to
VA surface memory from a software decoder.
2013-07-10 17:03:47 +02:00
Gwenole Beauchesne
09397fa0d8 plugins: port to new video format API. 2013-07-09 17:16:35 +02:00
Gwenole Beauchesne
e712abba11 plugins: allow buffer mappings to GstVaapiSurfaceProxy.
Allow plain gst_buffer_map() interface to work with gstreamer-vaapi
video buffers, i.e. expose the underlying GstVaapiSurfaceProxy to the
caller. This is the only sensible enough thing to do in this mode as
the underlying surface pixels need to be extracted through an explicit
call to the gst_video_frame_map() function instead.

A possible use-case of this is to implement a "handoff" signal handler
to fakesink or identity element for further processing.
2013-06-05 11:09:37 +02:00
Gwenole Beauchesne
eb9dd361f8 plugins: silence check for direct-rendering mode in video memory.
Fix gst_vaapi_video_allocator_new() to silently check for direct-rendering
mode support, and not trigger fatal-criticals if either test surface or
image could not be created. Typical case: pixel format mismatch, e.g. NV12
supported by most hardware vs. I420 supported by most software decoders.
2013-06-05 11:09:37 +02:00
Gwenole Beauchesne
33f6415696 plugins: improve video memory flags safety checks.
On map, ensure we have GST_MAP_WRITE flags since this is only what we
support for now. Likewise, on unmap, make sure that the VA image is
unmapped for either read or write, while still committing it to the
VA surface if write was requested.
2013-06-05 11:09:37 +02:00
Gwenole Beauchesne
e52ea35b11 plugins: cope with GST_VAAPI_IS_xxx() macros removal. 2013-05-23 19:01:34 +02:00
Gwenole Beauchesne
9535bb9950 plugins: cope with new GstVaapiMiniObject objects. 2013-05-07 18:19:03 +02:00
Gwenole Beauchesne
3f15a682ea plugins: implement direct-rendering mode for raw YUV buffer uploads.
Allow direct-rendering (writes) into target VA surfaces.
2013-04-10 14:58:17 +02:00
Gwenole Beauchesne
c698a015a3 plugins: implement uploads from raw YUV buffers for GStreamer 1.0.
Implement GstVideoMeta::{,un}map() to support raw YUV buffer upload when
the last component is unmapped. Downloads are not supported yet. The aim
was to first support SW decoding + HW accelerated rendering (vaapisink).
e.g. for Wayland.
2013-04-10 14:58:17 +02:00
Sreerenj Balachandran
5b11b83321 plugins: add GstVaapiVideoMemory and GstVaapiVideoBufferPool objects.
Add initial support for GstVaapiVideoMemory backed buffer pool. The memory
object currently holds a reference to GstVaapiVideoMeta.

Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
2013-04-10 14:58:16 +02:00