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.
We no longer need this obsolete set_property function now after
switch to standard gobject's property manner.
Also delete the old encoder's property enum in the header file.
G_PARAM_CONSTRUCT make all properties init correctly, we do not
need to init the properties manually.
G_PARAM_FLAG_VAAPI_ENCODER_EXPOSURE is a vaapi encoder specific
flag, means need to expose the property to according encode class.
Install properties for h264 encoder fei class. Also set the new get/set
property functions for gobject class. Still use the old properties
way now and this new feature will be enabled later.
