Refactor gst_vaapi_plugin_base_create_gl_context() in order to check
the return value of gst_gl_ensure_element_data(). The result is a code
bit cleaner.
The function g_bit_nth_lsf() may return -1 if the request bit position
is not avaible. Thus, this patch check if the return value is not -1
in order to continue.
Added a new property "compliance-mode", which default is the normal
strict compliant mode.
The second mode, "restrict-buf-alloc", is to limit the coded buffer
allocation size to improve performance in some specific Intel
platforms (there is asignificant performance improvement in parallel
encodings). Under this new mode, we use the MinCR field in A.3.1 for
pre-calculating the coded-buffer size.
https://bugzilla.gnome.org/show_bug.cgi?id=784590
Intel's MSDK uses libva 0.99.0, meanwhile open source libva bumped
its API version to 1.0.0. Thus we have to blacklist only the MSDK's
libva (0.99.0)
https://bugzilla.gnome.org/show_bug.cgi?id=784398
Fix PKG_CHECK_MODULES rule for with_gtk=check condition to
set USE_GTK=0 if gtk+-3.0 is not available.
Since commit 85856c29a7
Author: Hyunjun Ko <zzoon@igalia.com>
Date: Wed Jul 5 15:59:43 2017 +0900
tests: elements: add testsuite of vaapi context
...configure fails if gtk+-3.0 development files are missing.
The "with_gtk" option defaults to "check" in configure.ac
which implies that if it is not explicitly requested then
configure will only enable it if it's available on the system.
However, the PKG_CHECK_MODULES rule that get's activated on
"check" condition did not provide default when gtk+-3.0 devel
packages are not found on the system. Thus, it resulted in
configure failure.
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=785452
Replacing GstVaapiDisplay during rendering might be hiding problems
at some cases, even though it's safe currently since we use cache
of GstVaapidisplay.
Play safe by failing if this happens.
https://bugzilla.gnome.org/show_bug.cgi?id=766704
Through "gst.vaapi.app.Display" context, users can set their own VADisplay
and native display of their backend.
Attributes:
- display : pointer of VADisplay
- x11-display : pointer of X11 display (Display *), if they're using.
This patch creates GstVaapidisplayX11 if information provided through
"gst.vaapi.app.Display"
https://bugzilla.gnome.org/show_bug.cgi?id=766704
Push frames downstream as soon as possible instead of waiting until
they are ejected from the DPB.
This patch makes the decoder not comply with the H.264 specification,
but it is required for some video cameras.
https://bugzilla.gnome.org/show_bug.cgi?id=762509
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
If the picture is IDR, also submit a SPS header.
This means when frame number reaches to keyframe-period or an force
key unit event arrives, we insert SPS/PPS again.
https://bugzilla.gnome.org/show_bug.cgi?id=776712
GST_VIDEO_CODEC_FRAME_IS_FORCE_KEYFRAME() is a flag usually used to manage
the `frame-lost` event in the case of streaming, such as RTP.
In case of this event, it is needed to start new GOP rather than just
produce an I-frame.
https://bugzilla.gnome.org/show_bug.cgi?id=776712
Insert an AUD as the first NAL of each encoded frame.
Some applications require Access Unit Delimiter for decoding the
stream.
The AU delimeter insertion is done only when the aud parameter is
TRUE (by default is disabled). The reason of this it is because this
header is only available from Intel Gen9 and the VA intel driver
should be 1.8 or superior. Otherwise, the output will be corrupted.
https://bugzilla.gnome.org/show_bug.cgi?id=776712
Signed-off-by: Victor Jaquez <vjaquez@igalia.com>
Currently when num_views is changed by multiview-mode on sink caps, it produces
wrong MVC encoded stream since the array view_ids is not set properly according
to changed num_views.
So this patch initializes all of the array sequentially to handle this case.
Side effect is not going to happen by this patch since this array is being
handled by num_views.
https://bugzilla.gnome.org/show_bug.cgi?id=784321
Until now, the encoder ignored the profile in src caps and chose one
according with the given parameters. But the encoder must honor the
profile specifed in src caps.
This patch do that, and if the encoder needs to choose the profile,
it will do it by following these rules:
1\ If given parameters are not compatible with given profile, the
encoder will bail out with an error.
2\ The encoder will choose the higher profile indicated in the
src caps.
https://bugzilla.gnome.org/show_bug.cgi?id=757941
So far vaapi encoder does not set profile to src caps. This patch makes it
setting profile to src caps, which is determined by itself.
In addition, if encoder chose different profile, which is not negotiated with
downstream, we should set compatible profile to make negotiation working.
https://bugzilla.gnome.org/show_bug.cgi?id=757941
Check if the requested profile in source caps, is supported by the
VA driver. If it is not, an info log message is send saying that
another (compatible?) profile will be used.
https://bugzilla.gnome.org/show_bug.cgi?id=757941
First check if downstream requests ANY caps. If so, byte-stream is
used and the profile will be choose by the encoder. If dowstream
requests EMPTY caps, the negotiation will fail.
Lately, byte-stream and profile are looked in the allowed caps.
https://bugzilla.gnome.org/show_bug.cgi?id=757941
The check for avc stream format was done in the vaapi encoder's
vmethod get_caps(), but that is wrong since it has to be check
when encoder set_format().
https://bugzilla.gnome.org/show_bug.cgi?id=757941
vaapipostproc didn't negotiate the proper multiview caps losing
downstream information.
This patch enables the playing of MVC encoded stream by setting
the proper multiview mode/flags and views to src caps, according
to sink caps.
https://bugzilla.gnome.org/show_bug.cgi?id=784320
There is another regression with 7a206923 when setting the video
info for the video meta, it should be the one from the image's
allocator rather from the allocation caps.
Test pipeline:
gst-launch-1.0 filesrc location=bug766184.flv ! decodebin \
! tee ! videoconvert ! videoscale \
! video/x-raw, width=1920, height=1080 ! xvimagesink
