Some profile, such as H265_MAIN_444 on new Intel platform, may only
support ENTRYPOINT_SLICE_ENCODE_LP entrypoint. This leads two
problems:
1. We need to specify the tune mode like `vaapih265enc tune=low-power`
every time when we need to use this kind of profile. Or we can not
create the encoder context successfully.
2. More seriously, we set the entrypoint to a fixed value in
init_context_info() and so the create_test_context_config() can not
create the test context for these profile and can not get the
supported video formats, either.
We now change the entrypoint setting based on the tune option of the
encoder. If no tune property provided, we just choose the first
available entrypoint.
Instead of init_context_info() setting the passed profile, it is
assumed that it has to be set by each encoder.
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
The symbol GST_VAAPI_ENTRYPOINT_INVALID is just a representation of
zero, which was already used as an invalid value tacitly. This patch
only makes it explicit.
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
We use GST_VAAPI_OBJECT_NATIVE_DISPLAY with wrong parameter for x11
pixmap creation, which causes crash if we run the internal test case
of:
test-decode --pixmap
The old way make the one config for each profile/entrypoint pair,
which is not very convenient for description the relationship
between them. One profile may contain more than one entrypoints
to within it, so a set like data structure should be more suitable.
GstVaapiMiniObject and GstVaapiObject are deprecated.
This is the first step to remove them by porting GstVaapiSurface as
a GstMiniBuffer descendant.
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
There are several internal functions with 'create' name, but they
don't create any new structure, but rather it initializes that
structure. Renaming those function to reflect better their purpose.
GstVaapiMiniObject and GstVaapiObject are deprecated.
This is the first step to remove them by porting GstVaapiCodedBuffer
as a GstMiniBuffer descendant.
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
GstVaapiMiniObject and GstVaapiObject are deprecrated. This is the
first step to remove them, by porting GstVaapiImage as a
GstMiniObject.
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
The GstVaapiMiniObject is obsolete and we need to replace it. This
patch turns GstVaapiContext into a plain C structure with its own
reference counting mechanism.
Also this patch removes unused overlays attributes.
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
Issue detected by Coverity
`info_to_pack.h264_slice_header` is always allocated by
gst_vaapi_feipak_h264_encode(), thus checking it to free it afterwards
in doesn't make much sense. But it requires to be free on the error
path.
There may be a null pointer dereference, or else the comparison
against null is unnecessary.
In gst_vaapi_encoder_h264_fei_encode: All paths that lead to this null
pointer comparison already dereference the pointer earlier
Issue detected by Coverity
An unsigned value can never be negative, so this test will always
evaluate the same way.
In add_slice_headers: An unsigned value can never be less than 0
Issue detected by Coverity
There may be a null pointer dereference, or else the comparison
against null is unnecessary.
In gst_vaapi_encoder_h264_fei_encode: All paths that lead to this null
pointer comparison already dereference the pointer earlier
Issue detected by Coverity
`info_to_pak` variable in gst_vaapi_encoder_h264_fei_encode() is
declared in the stack, but it is free in
gst_vaapi_feienc_h264_encode() as if declared on the heap.
This patch initializes the structure and removes the free.
A non-heap pointer is placed on the free list, likely causing a crash
later.
In gst_vaapi_encoder_h264_fei_encode: Free of an address-of
expression, which can never be heap allocated.
Issue detected by Coverity
If the FEI mode is not handled the created resources should be
released and return and error code.
The system resource will not be reclaimed and reused, reducing the
future availability of the resource.
In gst_vaapi_encoder_h264_fei_encode: Leak of memory or pointers to
system resources
Don't try to decode until the first I-frame is received within the
currently active sequence. i965 H265 decoder don't show any artifact
but it crashes.
Fixes: #98
GST_VAAPI_FORMATS_ALL collects all declared formats in video-format
as a caps template string, and make them available in caps with
memory:VASurface feature.
Fixes: #199
The code is essentially the same for getting all op default
values. Thus, use a macro to help minimize code duplication
and [hopefully] encourage using the same mechanism for all
default getters.
Currently the parameter of skin-tone-enhancement filter is forced
to zero. In fact it could be set different value by the user.
So create a new property named as "skin-tone-enhancement-level"
for accepting the used defined parameter value.
At the same time, skin-tone-enhancement is marked as deprecated.
When skin-tone-enhancement-level is set, skin-tone-enhancement
will be ignored.
g_return_val_fail() documentations says:
If expr evaluates to FALSE, the current function should be
considered to have undefined behaviour (a programmer error).
The only correct solution to such an error is to change the
module that is calling the current function, so that it avoids
this incorrect call.
So it was missused in a couple parts of the H264 and H265 internal
decoders. This patch changes that to plain conditionals.
Also, it was included a couple code-style fixes.
Found by static analysis. encoder->mb_width * encoder->mb_height
is evaluated using 32-bit arithmetic before widen. Thus, cast
at least one of these to guint64 to avoid overflow.
The YUV formats have no ambiguity for drivers, so we can add them all.
Some old driver(i965) does not implement full get/put image functions
but can use derive image funtions for the YUV format. It does not
report that kind of formats correctly in image query, but will derive
that YUV format image from surface. The dynamic mapping of YUV format
will block that manner.
Adding more YUV format mapping has no side effect. So considering the
legacy driver conformance, we add all YUV formats mapping statically
and dynamic mapping RBG formats
Fix: #189Fix: #190
Multiple different scenarios could break the display thread creation and
end up blocking waiting for thread o be created. Fix them all by
correctly waiting for a new boolean to become valid.
Some streams have error data introducing unknown NAL type. There are
also kinds of NAL types we do not want to handle. The old manner will
set a decoder error when encounter this, which cause a latent crash bug.
The decoder may successfully decode the picture and insert it into DPB.
But there are error NAL units after the AU which cause the post unit error
and make that frame dropped. The later output of the picture still want
to ref that frame and crash.
No need to set decoder error when can not recognize or handle the NAL
unit, just skip it and continue.
Fix: #191
This patch makes use of GST_PARAM_USER_SHIFT to define the internal
param in encoders to decide which parameters to expose. Thus
gstreamer-vaapi will not interfere with any change in GStreamer in the
future.
Also, the internal symbol was change to
GST_VAAPI_PARAM_ENCODER_EXPOSURE to keep the namespacing.
The command line:
gst-launch-1.0 filesrc location=some_name.mjpeg ! jpegparse !
vaapijpegdec ! videoconvert ! video/x-raw,format=I420 ! vaapisink
will crash on i965 driver because of no pointer check.
We now generate the video format map between GST format and VA format
dynamically based on the image format returned by vaQueryImageFormats.
i965 driver does to report image format of 444P and Y800 forcc, while
the jpeg decoder context VASurfaceAttribPixelFormat use them. We can
not recognize these format and pass a NULL pointer to
gst_vaapi_surface_new_from_formats.
We need to add a pointer check here and let the fallback logic handle
this case correctly.
Other drivers work well.
Improve the mapping between va format and gst format. The new map
will be generated dynamically, based on the query result of image
format in VA driver. Also consider the ambiguity of RGB color
format in LSB mode.
