The vaCreateContext do not need to specify the surfaces for the
context creation now. So we do not need to bind any surface to the
context anymore. Surfaces should be the resource belong to display
and just be used in encoder/decoder context.
The previous manner has big limitation for decoder. The context's
surface number is decided by dpb size. All the surfaces in dpb will
be attached to a gstbuffer and be pushed to down stream, and the
decoder need to wait down stream free the surface and go on if not
enough surface available. For more and more use cases, this causes
deadlock. For example,
gst-launch-1.0 filesrc location=a.h264 ! h264parse ! vaapih264dec
! x264enc ! filesink location=./output.h264
will cause deadlock and make the whole pipeline hang.
the x264enc encoder need to cache more than dpb size surfaces.
The best solution is seperating the surfaces number and the dpb size.
dpb and dpb size shoule be virtual concepts maintained by the decoder.
And let the surfaces_pool in context maintain the re-use of all surfaces.
For encoder, the situation is better, all the surfaces are just used
as reference frame and no need to be pushed to down stream. We can
just reserve and set the capacity of the surfaces_pool to meet the
request.
Fix: #147Fix: #88
Co-Author: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/353>
Registering only stream's DBP size number of surfaces for decoding VA
surfaces brings issues for certain streams. This change register all
possible number of reference surfaces in a stream, which is 16.
Fixes: #94
The h265 encoder just support tune mode:
(0): none - None
(3): low-power - Low power mode
So, no need to check and set the high compression parameters.
And by the way, the current ensure_tuning_high_compression manner
of choosing the hightest profile idc as the best compression profile
is not correct. Unlike h264, in h265 the higher profile idc number
does not mean it has more compression tools, and so it has better
compression performance. It may even be un-compatible with the lower
profile idc. For example, the SCREEN_CONTENT_CODING profile with idc
9 is not compatible with 3D_MAIN profile with idc 8.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/348>
Right now, all outputs are handled. The means that the registry object for
all but the last are leaked. As a result the sizes are not used correctly.
With two outputs, at first the mode and physical size of the second output
are used. If the first output changes the mode, then the physical size of
the second output is used in combination with the resolution of the first
output. The resulting pixel aspect ratio is incorrect.
There seems to be no way to determine on which output the window is shown,
so just use the first one to get consistent results.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/341>
These properties are used for support of tile encoding. We just
support uniform mode of tile encoding, that is, separating picture
equally by (num-tile-cols X num-tile-rows).
According to HEVC spec A1, the max number of tiles in column is 20
and in rows is 22, so add two constant definitions.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/294>
We need to use the chroma_format_idc as the index for getting the
SubWidthC and SubHeightC values as the spec 6.1(table 6-1) defines.
The wrong SubWidthC or SubHeightC make us calculate a wrong right
or bottom offset for crop size and generate garbage in output.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/334>
Since bufferproxy and surface are not referenced circularly, there's
no need to keep, in the buffer proxy, a reference to the GstMemory
where it is held. This patch removes that handling.
The bufferproxy may reference the surface and the surface may also
reference the bufferproxy, producing a circular reference, which might
lead to serious resource leak problems.
Now make the relationship clearer, the bufferproxy's references is
transfered to surface, while bufferproxy just keeps the surface's
address without increasing its reference count.
The surface can be created through a bufferproxy like in
gst_vaapi_surface_new_with_dma_buf_handle(), and the surface might
get its bufferproxy via gst_vaapi_surface_get_dma_buf_handle(). In
both cases the surface holds a bufferproxy's reference.
This fixed segfault when running the pipeline below with iHD driver
(commit efe5e9a) on ICL
gst-launch-1.0 videotestsrc ! vaapivp9enc tune=low-power ! vaapivp9dec ! \
fakesink
