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
In hevc, we can consider the -intra profile a subset of the none
-intra profile. The -intra profiles just contain I frames and we
definitely can use the none -intra profiles's context to decode
them.
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
This is a workaround for intel-media-driver bug
https://github.com/intel/media-driver/issues/865
The driver will force the RC method to CBR for HEVCe
when it parses the HRD param. Thus, any RC method
param submitted "prior" to the HRD param will be lost.
Therefore, VBR, ICQ and QVBR for HEVCe can't be
effectively enabled if the RC method param "precedes"
the HRD param.
To work around this issue, set the HRD param before
the RC method param so the driver will parse the RC
method param "after" the HRD param.
Afaict, other codecs in the driver (and other drivers)
do not appear to be dependent on the order of HRD and
RC param submission.
GstVaapiPixmap is an abstract base class which only implementation
were GstVaapiPixmapX11. This class were used for a special type of
rendering in the tests apps, utterly unrelated in GStreamer.
Since gstreamer-vaapi is no longer a general-user wrapper for VA-API
we should remove this unused API.
This removal drops libxrender dependency.
