Commit graph

13 commits

Author SHA1 Message Date
Xu Guangxin
cab1ddf48b msdk: bufferpool: set alignment to video meta
else gst_video_meta_validate_alignment will report error like
"videometa gstvideometa.c:416:gst_video_meta_validate_alignment: Stride of plane 0 defined in meta (384) is different from the one computed from the alignment (320)"

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1224>
2020-05-07 05:45:36 +00:00
Seungha Yang
2e5fee17a3 msdkbufferpool: Fix build warning on Windows
gstmsdkbufferpool.c(274): warning C4101: 'fd': unreferenced local variable
2020-03-22 22:30:15 +09:00
Aaron Boxer
6d3429af34 documentation: fixed a heap o' typos 2019-11-05 09:11:25 -05:00
Haihao Xiang
20f61db2e5 msdkdec: make sure mfx frame width/height meets MSDK's requirement
It is possible that the output region size (e.g. 192x144) is different
from the coded picture size (e.g. 192x256). We may adjust the alignment
parameters so that the padding is respected in GstVideoInfo and use
GstVideoInfo to calculate mfx frame width and height

This fixes the error below when decoding a stream which has different
output region size and coded picture size

0:00:00.057726900 28634 0x55df6c3220a0 ERROR                msdkdec
gstmsdkdec.c:1065:gst_msdkdec_handle_frame:<msdkh265dec0>
DecodeFrameAsync failed (failed to allocate memory)

Sample pipeline:

gst-launch-1.0 filesrc location=output.h265 ! h265parse ! msdkh265dec !
glimagesink
2019-07-24 08:41:13 +08:00
Haihao Xiang
348a4b570d msdk: move the comment to the correct place 2019-02-24 17:59:43 +00:00
Víctor Manuel Jáquez Leal
6b6ed2cad8 msdk: bufferpool: refactor memory type decision
The memory type was used as bitwise enum, but the enum was not
defined in that way.

Nonetheless, most of the usage of the memory type was as mutually
exclusive options, rather than option composition.

This patch refactor how the memory type is defined, so it is kept
the mutual exclusion among options.
2019-01-24 08:49:39 +00:00
Seungha Yang
373580c7be msdk: Fix invalid return type build warning
void function cannot have return value

gst-plugins-bad/sys/msdk/gstmsdkbufferpool.c(332): warning C4098:
'gst_msdk_buffer_pool_release_buffer': ...
2018-12-25 16:14:36 +09:00
Xiang, Haihao
a1aae3fd92 msdk: fix the wrong operator
The condition is for video memory only, so the operator should be
& instead of |
2018-12-03 07:09:56 +00:00
Tim-Philipp Müller
65c5b9a4f6 msdk: Update for g_type_class_add_private() deprecation in recent GLib
Untested.
2018-06-24 12:22:27 +02:00
Hyunjun Ko
ea92da6e54 msdk: dmabuf support
This patch includes:
1\ Implements MsdkDmaBufAllocator and allocation of msdk dmabuf memroy.
2\ Each msdk dmabuf memory include its own msdk surface kept by GQuark.
3\ Adds new option GST_BUFFER_POOL_OPTION_MSDK_USE_DMABUF

https://bugzilla.gnome.org/show_bug.cgi?id=793707
2018-03-30 11:06:05 -08:00
Hyunjun Ko
c3438b5a0f msdk: generalize the parameter of msdk video memory functions
There needs to be generalized for the parameter from
GstVideoMsdkVideoMemory to GstMemory.

Thus we can call these functions if using DMABuf memory.

https://bugzilla.gnome.org/show_bug.cgi?id=793707
2018-03-30 11:03:00 -08:00
Hyunjun Ko
b08b8ddae3 msdk: manage MSDK surfaces seperately
Currently a gst buffer has one mfxFrameSurface when it's allocated and
can't be changed.
This is based on that the life of gst buffer and mfxFrameSurface would
be same.
But it's not true. Sometimes even if a gst buffer of a frame is finished
on downstream,
mfxFramesurface coupled with the gst buffer is still locked, which means
it's still being used in the driver.

So this patch does this.
Every time a gst buffer is acquired from the pool, it confirms if the
surface coupled with the buffer is unlocked.
If not, replace it with new unlocked one.
In this way, user(decoder or encoder) doesn't need to manage gst buffers
including locked surface.

To do that, this patch includes the following:
1. GstMsdkContext
- Manages MSDK surfaces available, used, locked respectively as the
following:
  1\ surfaces_avail : surfaces which are free and unused anywhere
  2\ surfaces_used : surfaces coupled with a gst buffer and being used
now.
  3\ surfaces_locked : surfaces still locked even after the gst buffer
is released.

- Provide an api to get MSDK surface available.
- Provide an api to release MSDK surface.

2. GstMsdkVideoMemory
- Gets a surface available when it's allocated.
- Provide an api to get an available surface with new unlocked one.
- Provide an api to release surface in the msdk video memory.

3. GstMsdkBufferPool
- In acquire_buffer, every time a gst buffer is acquired, get new
available surface from the list.
- In release_buffer, it confirms if the buffer's surface is unlocked or
not.
  - If unlocked, it is put to the available list.
  - If still locked, it is put to the locked list.

This also fixes bug #793525.

https://bugzilla.gnome.org/show_bug.cgi?id=793413
https://bugzilla.gnome.org/show_bug.cgi?id=793525
2018-03-08 11:37:12 -09:00
Hyunjun Ko
2542b2d34d msdk: supports bufferpool
Implements 2 memory allocators:
1\ GstMsdkSystemAllocator: This will allocate system memory.
2\ GstMsdkVideoAllocator: This will allocate device memory depending
on the platform. (eg. VASurface)

Currently GstMsdkBufferPool uses video allocator currently by default
only on linux. On Windows, we should use system memory until d3d
allocator
is implemented.

https://bugzilla.gnome.org/show_bug.cgi?id=790752
2018-02-13 13:44:08 -09:00