This code doesn't define the profile used by the internal encoder, but
it used to "predict" which is going to be used and to get the caps
restrictions.
Before the profile was predicted by checking the donwstream caps, but
sometimes they are not defined, setting an unknown profile. In order
to enhances this situation, the encoder asks to internal encoder if it
has one. If so, it is used.
To ask the internal encoder's profile a new accessor function was
added: gst_vaapi_encoder_get_profile()
The return value of vaGetConfigAttributes() of VAConfigAttribRTFormat
is a bitwise flag with *all* the supported chroma types.
Previously it was assumed that the return value was a single value,
thus when returning the GST_VAAPI_CHROMA_TYPE_XXX the code was a
simple case. But it is wrong.
This patch changes the case block with a sequence of ifs testing the
bitwise. For now we assume a "priority" list in the testing sequence.
gst_vaapi_profile_get_name() returns a proper name for
GstCaps. Nonetheless, there are many profiles which don't have a name
representation for that realm.
gst_vaapi_profile_get_va_name() returns the name of the profile
according to its VAProfile name.
This new funtion is used in the encoder error message.
Now that vaapipostproc can possible handle video-direction, it
should also handle the image-orientation event from upstream if
video-direction property is set to auto.
It is requiered to know if postproc is capable to change the video
direction before fixating the source caps.
In order to do it, it'ss required to know if there's a functional VPP,
but that's checked at create() vmethod, which occurs after caps
fixating.
This patch checks for a functional VPP at fixate caps and, if so,
checks for the enabled filtes and later do the caps fixations.
If the video direction is unsupported by the driver, an element
warning is posted in the bus to notify the application.
gst_vaapi_enum_type_get_nick() was added in the library thus it can
be used elsewhere. It retrives the nick from an enum gtype.
This patch locks the display before querying the pipeline caps and
stores the mirror and rotation capabilities, thus they are not queried
every time the video direction is set.
Commit 0afc8131 introduced a regression and only NV12 format were
admitted, failing in any other valid color format.
This patch sets the profile to GST_VAAPI_PROFILE_VP9_0 by default.
When set multiple settings of color balance like hue, saturation,
brightness and contrast for vaapipostproc, they should be set as
parameters of color balance filter, at the same color balance
filter calling.
Otherwise, multiple color balance filter calling will cause
previous setting get reset by the last calling with default value.
Fixes#182.
Signed-off-by: Yan Wang <yan.wang@linux.intel.com>
gst_vaapi_video_pool_reserve_unlocked() hit an undocumented behavoir
because it locks twice the same mutex.
Also, n had different meanings in the current code: as an increase
value and as a new total of allocated surfaces.
This patche removes the undocumented behavoir (usually a deadlock) and
fixes the meaning of n as the new total of allocated surfaces.
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
The main reason to demote the message's level is because it is not an
error, it's a possible output of the trial and there's a code path
that handles it.
Secondly, it's very annoying when using gallium driver for radeon.
ICQ is Intelligent Constant Quality. It will use the initial QP
vaule of icq-quality-factor to adjust QP at MB level intelligently
to improve subjective quality.
QVBR is Quality defined VBR. It will use qvbr-quality-factor to
adjust QP for each MB to get enough quality picture without waste
of bits.
The value return from GST_VAAPI_RATECONTROL_MASK will be used by
GST_VAAPI_POPCOUNT32 as its inpput. GST_VAAPI_POPCOUNT32 can only
deal with unsigned int. Otherwise there may be an error of out of
range of integer if we define few more rate-control mode.
Otherwise the queue will swallow all the available decoder's surfaces
reaching a dead-lock.
This setting might impact the bin's peformance, but it's a trade-off.
When the code path goes to push buffers downstream when no surface
available in decoder context, and it fails the code bails out with a
fatal error.
That behavior is wrong, since it shouldn't be fatal. The use case is
when the video stream is disabled.
This patch just ignores the errors in this situation and demotes the
level of a log message.
If display size is smaller than current frame size, then the crop size
will be set as display size, which either crashes the pipeline or the
output MD5 does not match. Rather it should use the actual decoded size.
This patch removes the cropping set. For rendering we can use aspect
ratio to set display size.
Fixes#175
Signed-off-by: Wang Zhanjun <zhanjunx.wang@intel.com>
Signed-off-by: Xu Guangxin <guangxin.xu@intel.com>
For some main-10 stream, sometime the luma is 8 bits while chrome is more
than 8 bits, which cause using the wrong NV12 surface as the render target
and decoding error.
Fix#176
For surfaces with different chroma type, it is prefer to initialize
a format which chroma type should be same with surface chroma type
instead of using fixed NV12.
When create vaapi surface, it is better to use the chroma type get
from jpeg file instead of using fixed 420 format. And the correct
chroma type can be determined by horizontal_factor/vertical_factor
flags that get from jpegparse.
The old mapping values return by gst_vaapi_utils_h265_get_profile_idc is
wrong, though GST_H265_PROFILE_IDC_MAIN and GST_H265_PROFILE_IDC_MAIN_10
happened to be the correct value.
We only support Annex A profile_idc (1-4).
If the allocation caps and negotiated caps are the same,
then ensure any previously negotiated video info is also
removed. This can occur when multi-resolution video
decoding returns to it's original resolution.
Fixes#170
When input frame's formate changes, vp{8,9} encoders don't reset their frame
counter, hence the newly created frame could become a P-frame, leading to some
major troubles (sigabrt in libdrm in case of vp9). This patch adds some frame
prediction-related reset logic to the `flush' methods of GstVaapiEncoderVP8 and
GstVaapiEncoderVP9 implementations.
There are many profile levels that can support
more than 102400 kbps. Thus, increase the max
allowed bitrate property value from 102400 kbps
to 2048000 kbps (same as msdk encoder plugins).
