Mapping a pointer event needs to consider both size and
video-direction operations together, not just one or the other.
This fixes an issue where x,y were not being mapped correctly
for 90r, 90l, ur-ll and ul-lr video-direction. In these directions,
the WxH are swapped and GST_VAAPI_POSTPROC_FLAG_SIZE is set. Thus,
the first condition in the pointer event handling was entered and
x,y scale factor were incorrectly computed due to srcpad WxH
swap.
This also fixes all cases where both video-direction and scaling
are enabled at the same time.
Test that all pointer events map appropriately:
for i in `seq 0 7`
do
GST_DEBUG=vaapipostproc:5 gst-launch-1.0 -vf videotestsrc \
! vaapipostproc video-direction=${i} width=300 \
! vaapisink
GST_DEBUG=vaapipostproc:5 gst-launch-1.0 -vf videotestsrc \
! vaapipostproc video-direction=${i} width=300 height=200 \
! vaapisink
GST_DEBUG=vaapipostproc:5 gst-launch-1.0 -vf videotestsrc \
! vaapipostproc video-direction=${i} height=200 \
! vaapisink
GST_DEBUG=vaapipostproc:5 gst-launch-1.0 -vf videotestsrc \
! vaapipostproc video-direction=${i} \
! vaapisink
done
Advertise to upstream that vaapipostproc can handle
crop meta.
When used in conjunction with videocrop plugin, the
videocrop plugin will only do in-place transform on the
crop meta when vaapipostproc advertises the ability to
handle it. This allows vaapipostproc to apply the crop
meta on the output buffer using vaapi acceleration.
Without this advertisement, the videocrop plugin will
crop the output buffer directly via software methods,
which is not what we desire.
vaapipostproc will not apply the crop meta if downstream
advertises crop meta handling; vaapipostproc will just
forward the crop meta to downstream. If crop meta is
not advertised by downstream, then vaapipostproc will
apply the crop meta.
Examples:
1. vaapipostproc will forward crop meta to vaapisink
gst-launch-1.0 videotestsrc \
! videocrop left=10 \
! vaapipostproc \
! vaapisink
2. vaapipostproc will do the cropping
gst-launch-1.0 videotestsrc \
! videocrop left=10 \
! vaapipostproc \
! identity drop-allocation=1 \
! vaapisink
The encoder is a true gstobject now and all the properties are using
gobject's properties mechanism. Add help functions to handle the properties
between encode and encoder class.
The basic idea is mapping the same property between encoder and encode. All
the encoder's properties will have the same name, the same type in encode.
The set/get property function just forward the property setting/getting to
the encoder using the same property name and value. Because the encoder is
created on needed, we need to cache the property setting in encode.
While ensuring the allowed sink pad caps, the filter attributes set
the frame size restriction, but it is not ensured, at that moment,
that the filter is already instantiaded.
In order to silence the glib logs, this patch add only calls
gst_vaapi_filter_append_caps() if the filter is instantiated.
In commit 18031dc6 surface's parent context is not assigned because of
circular references. Since then (2013), there's has no issue with
subpictures attached to a context, the current only users of this API.
This patch cleans up all of related code with the unused surface's
parent context.
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()
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.
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.
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.
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.
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
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.
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
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
The vaapi internal encoder's property id are negative, thus they are
different from GObject's property ids.
gst_vaapi_encoder_set_property() should map to the internal encoder
property id, assigned in gst_vaapiencode_default_set_property().
When downstream has any caps, vaapi should not shovel vaapi featured
buffers, but rather plain raw video, assuming always the worst case
scenario (downstream cannot handle featured video memory but raw
system memory buffers).
This patch query the peer caps without any filter, to know if
donwstream just ask for any caps, if so jump to the color space
checking, otherwise do the caps intersection and continue with the
feature selection algorithm.
Fixes: #139
We prefer to use the same format between image and surface for gst
vaapi allocator. The old way may choose different formats between
image and surface. For example, the RGBA image may have a NV12 surface.
So we need to do format conversion when we put/get image to surface.
Some drivers such as iHD can not support such conversion and always
cause a data flow error. There may also have some performance cost
for format conversion when put/get images.
So we prefer to use the same format for image and surface in the
allocator. If the surface can not support that format, we then
fallback to find a best one as the surface format.
Co-authored-by: Víctor Jáquez <vjaquez@igalia.com>
[wl_shell] is officially [deprecated], so provide support for the
XDG-shell protocol should be provided by all desktop-like compositors.
(In case they don't, we can of course fall back to wl_shell).
Note that the XML file is directly provided by the `wayland-protocols`
dependency and generates the protocol marshalling code.
[wl_shell]: https://people.freedesktop.org/~whot/wayland-doxygen/wayland/Client/group__iface__wl__shell.html
[deprecated]: 698dde1958
Fix the deinterlace black frame when playing with glimagesink:
gst-launch-1.0 filesrc location=test.264 ! h264parse ! vaapih264dec \
! vaapipostproc deinterlace-mode=1 deinterlace-method=1 ! glimagesink
The gst_vaapi_plugin_base_get_allowed_raw_caps is used for both sink
pad and src pad, which cause some bugs. For sink pad, we need to verify
vaPutImage() while for the src pad we need to verify vaGetImage().
For vaapidecoderXXX kind of plugins, the case is more complex. We need
to verify whether the decoded result(in some surface, NV12 format most
of the time) can be vaGetImage to some raw image format. Add more check
to fix all these problems.
https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/issues/123
Signed-off-by: He Junyan <junyan.he@hotmail.com>
Add 444 10bit yuv format Y410, which can be used to decode
main-444 10bit streams. Currently, this feature is only
supported by media-driver in Icelake.
The extract_allowed_surface_formats function just check whether
we can support some kind of surface/image format pair. We just
need to create a surface, create an image with the same video-format
and putImage from image to surface. All these operations success,
that kind of video-format is supported.
The old manner do not work for some kind of video-format. For example,
the RGBA kind of format will create a NV12 surface and RGBA image,
and the putImage will fail because the format is not same. And so
the RGBA format is not supported but actually it is supported.
gst_vaapi_plugin_base_close() removed the raw caps that are used indirectly
in gst_vaapipostproc_transform_caps(). The usage is already protected by
the mutex.
This is needed when the pipeline is stopped during startup.
gl_platform_type in gst_vaapi_get_display_type_from_gl_env generate
unused-variable warning and may block build when Werror enabled.
Several functions like gst_vaapi_display_egl_new_with_native_display
have no prototype warning and link error when GL is enabled but EGL
is disabled. Fix all these warning and link error.
https://bugzilla.gnome.org/show_bug.cgi?id=797358
Signed-off-by: Junyan He <junyan.he@intel.com>
Add 422 10bit yuv format Y210, which can be used to decode
main-10-422 10bit streams. Currently, this feature is only
supported by media-driver in Icelake.
https://bugzilla.gnome.org/show_bug.cgi?id=797264
The current vaapipostproc calls driver's video processing
pipeline for deinterlacing only if it is Advance deinterlacing.
Modify in the way that it always tries with driver's video
processing pipeline for deinterlacing, and falls back to software
method of appending picture structure meta data only if it fails
with driver's method.
https://bugzilla.gnome.org/show_bug.cgi?id=797095
Removed exposed macros GST_VAAPI_OBJECT_DISPLAY() and
GST_VAAPI_OBJECT_ID() to plugins, keeping them only for internal
library usage.
The purpose is readability.
https://bugzilla.gnome.org/show_bug.cgi?id=797139
If the unit could not be parsed, just skip this nal and keep parsing
what is left in the adapter. We need to flush the broken unit in the
decoder specific parser because the generic code does not know about
units boundary. This increases error resilliance.
Before this, the broken unit would stay in the adapter and EOS would be
returned. Which stopped the streaming. Just removing the EOS would have
lead to the adapter size growing indefinitely.
https://bugzilla.gnome.org/show_bug.cgi?id=796863
On systems with an Nvidia card, this error is output each time
the registry is rebuilt, which happens pretty often when
using gst-build as a development environment.
https://bugzilla.gnome.org/show_bug.cgi?id=796663
gst_vaapi_display_egl_new_with_native_display() has been broken since
it wasn't used.
Currently it's needed to call this API to create a display providing
the EGL display, so it could avoid duplicated calls to the native
display (eg. eglTerminate).
Signed-off-by: Victor Jaquez <vjaquez@igalia.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795391
The commit 67e33d3de2 ("vaapiencode: h264:
find best profile in those available") changed the code to pick a profile
that is actually supported by the hardware. Unfortunately it dropped the
downstream constraints. This can cause negotiation failures under certain
circumstances.
The fix is split in two cases:
1\ the available VA-API caps doesn't intersect with pipeline's allowed
caps:
* The best allowed profile (pipeline's caps) is set as the encoding
target profile (it will be adjusted later by the available profiles
and properties)
2\ the available VA-API caps does intersect with pipeline's allowed
caps:
* The intersected caps are fixed, and its profile is set as the
encoding target profile. In this case the is not the best profile,
but the minimal one (if VA-API reports the profiles in order).
Setting the minimal profile of the intersected caps is better for
compatibility.
This patch fixes other tests related with caps negotiation, for
example, it handles baseline profile, even when VA only supports
constrained-baseline.
Original-patch-by: Michael Olbrich <m.olbrich@pengutronix.de>
https://bugzilla.gnome.org/show_bug.cgi?id=794306
Instead of using our own context handling for looking for GstGL
parameters (display, context and other context), this patch changes
the logic to use the utility function offered by GstGL.
https://bugzilla.gnome.org/show_bug.cgi?id=793643
The parameters of gst_gl_ensure_element_data() have to be not
local variable since they are going to be used to see if they're
set in gst_element_set_context() inside the API.
This is basically a revert of commit 3d56306chttps://bugzilla.gnome.org/show_bug.cgi?id=793643
Through "gst.vaapi.app.Display" context, users can set their own
VADisplay and native display of their backend.
So far we support only X11 display, from now we also support Wayland
display.
Attributes:
- wl-display : pointer of struct wl_display .
https://bugzilla.gnome.org/show_bug.cgi?id=705821
Instead to look for the best profile in the allowed profiles by
downstream, the encoder should look for the base profile in the
available profile in VA-API.
https://bugzilla.gnome.org/show_bug.cgi?id=794306
Instead of copying the metada in prepare_output_buffer() vmethod,
it is done in append_output_buffer_metadata() thus deinterlaced
buffers could also have the proper metas.
GstVideoCropMeta now it is copied internally and it is decided via
transform_meta() vmethod.
A new internal method, copy_metadata() was added to handle VPP
transformation where non-GstVideoVaapiMeta metas were lost.
When importing buffers to a VA-base buffer, it is required to copy
the metas in the original buffer, otherwise information will be
lost, such as GstVideoRegionOfInterestMeta.
https://bugzilla.gnome.org/show_bug.cgi?id=768248
Generate system allocated output buffers when downstream doesn't
support GstVideoMeta.
The VA buffer content is copied to the new output buffer, and it
replaces the VA buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=785054
When downstream can't handle GstVideoMeta it is required to send
system allocated buffers.
The system allocated buffers are produced in prepare_output_buffer()
vmethod if downstream can't handl GstVideoMeta.
At transform() vmethod if the buffer is a system allocated buffer,
a VA buffer is instanciated and replaces the out buffer. Later
the VA buffer is copied to the system allocate buffer and it
replaces the output buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=785054
This patch add the member copy_output_frame and set it TRUE when
when downstream didn't request GstVideoMeta API, the caps are raw
and the internal allocator is the VA-API one.
https://bugzilla.gnome.org/show_bug.cgi?id=785054
This function will inform the element if it shall copy the generated
buffer by the pool to a system allocated buffer before pushing it
to downstream.
https://bugzilla.gnome.org/show_bug.cgi?id=785054
VA-API based buffer might need a video meta because of different
strides. But when donwstream doesn't support video meta we need to
force the usage of video meta.
Before we changed the buffer pool configuration, but actually this
is a hack and we cannot rely on that for downstream.
This patch add a check fo raw video caps and allocator is VA-API,
then the option is enabled without changing the pool configuration.
In this case the element is responsible to copy the frame to a
simple buffer with the expected strides.
https://bugzilla.gnome.org/show_bug.cgi?id=785054
vaapsink, when used with the Intel VA-API driver, tries to display
surfaces with format NV12, which are handled correctly by
Weston. Nonetheless, COGL cannot display YUV surfaces, making fail
pipelines on mutter.
This shall be solved either by COGL or by making the driver to paint
RGB surfaces. In the meanwhile, let's just demote vaapisink as
marginal when the Wayland environment is detected, no matter if it is
Weston.
https://bugzilla.gnome.org/show_bug.cgi?id=775698
In propose_allocation() if the numer of allocation params is zero, the
system's allocator is added first, and lastly the native VA-API
allocator.
In decide_allocation(), the allocations params in query are travered,
looking for a native VA-API allocator. If it is found, it is reused as
src pad allocator. Otherwise, a new allocator is instantiated and
appended in the query.
https://bugzilla.gnome.org/show_bug.cgi?id=789476
GST_VAAPI_VIDEO_ALLOCATOR_NAME was added in commit 5b11b8332 but it
was never used, since the native VA-API allocator name has been
GST_VAAPI_VIDEO_MEMORY_NAME.
This patch removes GST_VAAPI_VIDEO_ALLOCATOR_NAME macro.
https://bugzilla.gnome.org/show_bug.cgi?id=789476
Don't subscribe to button press events when using a foreing window,
because the user created window would trap those events, preveting the
show of frames.
https://bugzilla.gnome.org/show_bug.cgi?id=791615
Check for display's color-balance properties, available by the VA-API
driver, before setting them.
Also logs an info message of those unavailable properties.
https://bugzilla.gnome.org/show_bug.cgi?id=792638
gst_vaapipostproc_ensure_filter might free the allowed_srcpad_caps
and allowed_sinkpad_caps. This can race with copying these caps in
gst_vaapipostproc_transform_caps and lead to segfaults.
The gst_vaapipostproc_transform_caps function already locks
postproc_lock before copying the caps. Make sure that calls to
gst_vaapipostproc_ensure_filter also acquire this lock.
https://bugzilla.gnome.org/show_bug.cgi?id=791404
gst.vaapi.app.Display context is made for applications that will
provide the VA display and the native display to used by the
pipeline, when are using vaapisink as overlay. There are no use
case for encoders, decoders, neither for the postprocessor.
In the case of the vaapisink, it shall query for gst.vaapi.Display
upstream first, and then, if there is no reply,
gst.vaapi.app.Display context will be posted in the bus for the
application. If the application replies, a GstVaapiDisplay object
is instantiated given the context info, otherwise a
GstVaapiDisplay is created with the normal algorithm to guess the
graphics platform. Either way, the instantiated GstVaapiDisplay
is propagated among the pipeline and the have-message bus message.
Also only vaapisink will process the gst.vaapi.app.Display, if
and only if, it doesn't have a display already set. This is
caused because if vaapisink is in a bin (playsink, for example)
the need-context is posted twice, leading to an error state.
https://bugzilla.gnome.org/show_bug.cgi?id=790999
As buffers negotiated with memory:VASurface caps feature can also be
mapped, they can also be configured to use VA derived images, in other
words "direct rendering".
Also, because of the changes in dmabuf allocator as default allocator,
the code for configuring the direct rendering was not clear.
This patch cleans up the code and enables direct rendering when the
environment variable GST_VAAPI_ENABLE_DIRECT_RENDERING is defined,
even then the memory:VASurface cap feature is negotiated.
https://bugzilla.gnome.org/show_bug.cgi?id=786054
Set if source pad can handle dmabuf only if the GstGL context comes
from downstream.
It is possible to know that at two moments:
1\ In the case of GstGLTextureUpload caps feature is negotiated and
downstream pool reports back gst.gl.GstGLContext.
2\ When GstGLContext is found as GstContext from dowstream.
https://bugzilla.gnome.org/show_bug.cgi?id=788503
In function gst_vaapi_find_gl_context() add a direction parameter to
return back the direction where the GstGL context was found.
This is going to be useful when checking if downstream can import
dmabuf-based buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=788503
This patch refactors the code by adding the function
vaapi_plugin_base_set_srcpad_can_dmabuf(), it determines if the passed
GstGLContext can handle dmabuf-based buffers.
The function is exposed publicly since it is intended to be used later
at GstVaapiDisplay instantiation.
https://bugzilla.gnome.org/show_bug.cgi?id=788503
Tis patch, allows some properties that we want to be set on
runtime. (eg. bitrate)
Note that all properties are under control by num_codedbuf_queued.
https://bugzilla.gnome.org/show_bug.cgi?id=786321
VPP support is only needed for advanced deinterlacing, which is not
enabled by default either. Error out if it is selected but VPP is not
supported, and otherwise just work without VPP support.
https://bugzilla.gnome.org/show_bug.cgi?id=788758
When creating the test display for querying capabilites, it try in
certain order: DRM, Wayland and finally X11. GLX nor EGL are tried
since they are either composited with X11 or Wayland.
The reason for this is to reduce the posibility of failure that could
blacklist the plugin.
https://bugzilla.gnome.org/show_bug.cgi?id=782212
We returned FALSE from ::start() if VPP support is not available, but it
is only really needed for complex filters and during transform we check
for that. For simple deinterlacing it is not needed.
Instead of reusing a parameter variable for the return value of
gst_vaapipostproc_transform_caps(), this patch uses the function
scoped pointer. Thus, the code is cleaner.
https://bugzilla.gnome.org/show_bug.cgi?id=785706
Instead of reusing a parameter variable for the return value of
gst_vaapipostproc_fixate_caps(), this patch uses the function scoped
pointer. Thus, the code is cleaner.
https://bugzilla.gnome.org/show_bug.cgi?id=785706
When glimagesink negotiates the caps feature memory:DMABuf the
exported dmabufs buffers with NV12 format are not well rendered, thus
setting only planar.
https://bugzilla.gnome.org/show_bug.cgi?id=788229
Instead of using gst_vaapi_display_set_property() or
gst_vaapi_display_get_property(), this patch set replace it usage
with g_object_set() or g_object_get().
Also the internal helper cb_set_value() is removed since it is not
used anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=788058
Make sure vaapisink create a va surface backed buffer pool and all
required attributes get assigned correctly for drm display type.
This is needed to make the below pipeline working:
gst-launch-1.0 filesrc location= raw_video.mov ! videoparse format=uyvy
width=320 height=240 framerate=30/1 ! vaapisink display=drm
https://bugzilla.gnome.org/show_bug.cgi?id=786954
A new FEI based encoder element for h264 is added: vaapih264feienc
FEI is a an extension to VA-API which is providing low level
advanced control over different stages of encoding.
Extending vaapih264enc with fei support is possible, but it will
make the code too much complicated and will be difficult
to debug. So adding the new encoder element, but keeping
the rank as 0 , vaapih264enc will stay as the primary
encoder for normal use cases.
The vaaih264feienc is mainly useful for customers who want to play
with MotionVectors and Macroblock Predictions. Also user can
do one stage of encoding(eg: only the Motion Vector Calculation)
in software and offload trasformation/entroy-coding etc to
Hardware (which is what PAK module is doing) using FEI element.
vaapih264feienc can work in different modes using fei-mode properoty
eg: gst-launch-1.0 videotestsrc ! vaapih264feienc fei-mode=ENC+PAK ! filesink location=sample.264
Important Note: ENC only mode won't produce any encoded data which is expected.
But ENC alwys requires the output of PAK in order to do the inter-prediction
over reconstructed frames.
Similary PAK mode alway requires MV and MBCode as input, so unless there is an
upstream element providing those buffers, PAK only won't work as expected.
In a nutshell, ENC_PAK and the ENC+PAK modes are the only options we can verify
with vaapih264feienc. But ideally, EN+PAK mode verification is enough to make sure
that ENC and PAK are working as expected since ENC+PAK mode always invoke ENC and PAK
separately in vaapih264feienc.
People contributed:
Wang, Yi <yi.a.wang@intel.com>
Leilei <leilei.shang@intel.com>
Zhong, Xiaoxia <xiaoxia.zhong@intel.com>
xiaominc <xiaomin.chen@intel.com>
Li, Jing B <jing.b.li@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=785712https://bugzilla.gnome.org/show_bug.cgi?id=784667
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
When vaapih264dec's base-only profile is set to TRUE, fake SVC profile
support in caps.
https://bugzilla.gnome.org/show_bug.cgi?id=732266
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
Instead including particular gstgl header files in a header file
that doesn't export a gstgl symbol, the main gstgl header file is
included in gstvaapipluginutil.c where the symbols are used.
https://bugzilla.gnome.org/show_bug.cgi?id=786597
Coverity scan bug:
An unsigned value can never be negative, so this test will always
evaluate the same way.
As len is guint32, there is no need to check it if it is equal or
bigger than zero.
Coverity scan bug:
The variable will contain an arbitrary value left from earlier
computations.
Variable base_only is fetched from base-only property, and it may be
not assigned. It needs to be initialized.
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.
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
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
There is a regression in 7a206923, since the buffer pool ditches all
the buffers generated by them because the pool config size is
different of the buffer's size.
Test pipeline:
gst-launch-1.0 filesrc location=big_buck_bunny_1080p_h264.mov \
! qtdemux ! vaapih264dec ! vaapipostproc ! xvimagesink \
--gst-debug=GST_PERFORMANCE:5
The allocator may update the buffer size according to the VA surface
properties. In order to do this, the video info is modified when the
allocator is created, which reports through the allocation info the
updated size, and set it to the pool config.
Refactor the set_config() virtual method considering a cleaner
approach to allocator instanciation, if it it not set or if it is
not valid for the pool.
https://bugzilla.gnome.org/show_bug.cgi?id=783599
The vaapi video decoders might have different allocation caps from
the negotiation caps, thus the GstVideoMeta shall use the negotiation
caps, not the allocation caps.
This was done before reusing gst_allocator_get_vaapi_video_info(),
storing there the negotiation caps if they differ from the allocation
ones, but this strategy felt short when the allocator had to be reset
in the vaapi buffer pool, since we need both.
This patch adds gst_allocator_set_vaapi_negotiated_video_info() and
gst_allocator_get_vaapi_negotiated_video_info() to store the
negotiated video info in the allocator, and distinguish it from
the allocation video info.
https://bugzilla.gnome.org/show_bug.cgi?id=783599
Renamed local video info structure names in set_config() vitual
method. The purpose of their renaming is to clarify the origin
of those structures, whether come from passed caps parameter
(new_allocation_vinfo) or from the configured allocator
(allocator_vinfo).
https://bugzilla.gnome.org/show_bug.cgi?id=783599
Renamed private GstVideoInfo structure video_info to allocation_vinfo
and alloc_info to negotiated_vinfo.
The purpose of these renaming is to clarify the origin and purpose of
these private variables:
video_info (now allocation_vinfo) comes from the bufferpool
configuration. It describes the physical video resolution to be
allocated by the allocator, which may be different from the
negotiated one.
alloc_info (now vmeta_vinfo) comes from the negotiated caps in
the pipeline. It represents how the frame is going to be mapped
using the video meta.
In Intel's VA-API backend, the allocation_vinfo resolution is
bigger than the negotiated_info.
https://bugzilla.gnome.org/show_bug.cgi?id=783599
When state of vaapisink is changed from PLAYING to NULL, the handle_events
flag is set to FALSE, and never recovered, and then event thread is never
going to run.
So we should allow to set the flag only when users try it.
https://bugzilla.gnome.org/show_bug.cgi?id=782543
Handles new custom event GstVaapiEncoderRegionOfInterest
to enable/disable a ROI region.
Writes a way to use new event to document.
https://bugzilla.gnome.org/show_bug.cgi?id=768248
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
This bin should have similar classification as decodebin which is
"Generic/Bin/Decoder" otherwise it will appear wrongly as video
decoder.
Signed-off-by: Victor Toso <victortoso@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=782063
