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).
This means we can use some newer features and get rid of some
boilerplate code using the G_DECLARE_* macros.
As discussed on IRC, 2.44 is old enough by now to start depending on it.
This fixes a deadlock in gst_vaapiencode_change_state, which was due to
srcpad's chain function was locked waiting for available buffers. Since the
coded buffers in codedbuf_queue become available after sinkpad consume the
encoded frames, Paused -> Ready state change leads to deadlock. Coded buffers
are never consumed and marked free, hence gst_vaapiencode_handle_frame waits for
available buffers and holds the stream_lock of the srcpad.
Adds vpp mirroring support to vaapipostproc. Use
property video-direction. Valid values are identity,
horiz or vert. Default is identity (no mirror).
Closes#89
v2: Use GstVideoOrientationMethod enum
v3: Don't warn for VA_MIRROR_NONE.
Use GST_TYPE_VIDEO_ORIENTATION_METHOD type.
v4: Query VAAPI caps when setting mirror value
instead of during per-frame processing.
v5: Return TRUE in warning cases when setting mirror value.
When enable low delay B, the reference list 1 will be same with
reference list 0, so need reset the num_ref_idx_l1_active_minus1
to num_ref_idx_l0_active_minus1.
Fixes: #160
g_assert will take no effect when glib's G_DISABLE_ASSERT macro is
defined. The function inside the g_assert will take no effect and
we will fail to set the correct slice number.
Use VAPictureParameterBufferHEVCExtension&
VASliceParameterBufferHEVCExtension to pass extension setting from
some extension profile clips which may include these information.
The hevc extension setting only supported after libva release 2.2.0
(API 1.2.0).
Allow users to set the target-percentage for
variable rate controls. The default value is
70 (as hard-coded prior).
v2: minimum allowed value changed from 0 to 1
v3: target-percentage unchanged if CBR used
Resolves#129
The advanced trellis algorithm is supported in VA driver. We add
its support as a property named "trellis" of encoder.
It only works for H264 now, should be more in future.
Can not find a suitable chrome_type for this GST_VIDEO_FORMAT_RGB
packed 24 format. Just use GST_VAAPI_CHROMA_TYPE_RGB32 as its chrome
type. This kind of surface will just be created by new API with fourcc
and no old style chrome based creation is available.
fixes: #151
Coverity scan bug:
If the function actually returns a null value, a null pointer
dereference will occur.
In gst_vaapi_encoder_ensure_param_roi_regions(): Return value of
function which returns null is dereferenced without checking
The decoder's surface chroma type should depend on the bit depth
of VP9's parser. For 10bits VP9 stream, we need to use P10LE kind
10 bits surface as the decoder result.
Fixes#155
https://bugzilla.gnome.org/show_bug.cgi?id=748184 has resurrected
with commit 3e992d8a
Since gst_vaapi_find_preferred_caps_feature() returns a color format
from caps negotiation, different from the default one (NV12), the
postproc enables the color transformation. But when GL_TEXTURE_UPLOAD
feature is negotiated, no color transformation shall be done.
Nonetheless, with commit 3e992d8a the requested format changes
firstly, because there's no video sink yet, so ANY caps are
negotiated; but later, when there's a video sink and a caps
renegotiation, the GL_TEXTURE_UPLOAD is negotiated though the color
format conversion still ongoing. It is required to reset that
conversion.
This patch force default color format when GL_TEXTURE_UPLOAD is
selected as preferred, thus avoiding the color conversion.
Fixes: #157
This patch fixes a regression from commit 5b1fe9c6.
max_qp, in rate control configuration, appeared in libva release
2.1 (API 1.1), thus it is required to guard the VA API version.
Fixes: #150
string_of_va_chroma_format() gets a wrong string format description.
For example, the YUV420_10BPP get a string of 0x00000100 as output.
It's because VA_RT_FORMAT_xxx values are macro definitions. And
STRINGIFY(VA_RT_FORMAT_xxx) will expand to its real value
0x00000XXX.
To avoid the macro evaluation, it is changed to show only the color
format without VA_RT_FORMAT_ prefix.
When the downstream has any caps, then raw video feature will
be used. At this situation, the preferred format should be chose
from caps which contains "vide/x-raw" feature instead of from
the fist allowed caps.
Fixes#142
