MSVC warns about this because it's a C++ compiler, and this actually
results in useful things such as the incorrect 'gboolean' return value
for functions that return GstFlowReturn, so let's do explicit
conversions to reduce the noise and increase its efficacy.
With MSVC, this gives the following warning:
warning C4305: 'function': truncation from 'double' to 'gfloat'
Apparently, MSVC does not figure out what type to use for constants
based on the assignment. This warning is very spammy, so let's try to
fix it.
The headers we include already define boolean on Windows with MSVC, and
it leads to a typedef redefinition error with jpeglib.h which tries to
redefine it in jmorecfg.h
When only linking the element, the upload object will be created from
_transform_caps() but will never be unreffed as the only case is in _stop().
Add an unref if non-NULL to a new finalize handler for this case.
It's possible that the window may have been destroyed when a winsys
event comes in for it.
Fixes an assertion in make -C tests/check generic/states.check
The buffer data is not always copied in _Fill, and will be
read in _DecodeFrame. We unmap at the end of the function,
whether we get there via failure or early out, and keep a
ref to the buffer to ensure we can use it to unmap the
memory even after _finish_frame is called, as it unrefs
the buffer.
Note that there is an access beyond the allocated buffer,
which is only apparent when playing from souphttpsrc (ie,
not from filesrc). This appears to be a bug in the bit
reading code in libfdkaac AFAICT.
https://bugzilla.gnome.org/show_bug.cgi?id=772186
This is specific to when the waylandsink is not being embedded. In
this patch we pass the render lock to the window so it can safely
call gst_wl_window_set_render_rectangle() with the new size.
https://bugzilla.gnome.org/show_bug.cgi?id=722343
We already take the render lock from the wlqueue thread in some other
place which indicates that there is no use of this atomic instead of
a proper locking mechanism.
When we don't have a viewporter (scaling support), we can't use the
1x1 scaleup image trick. Instead, we need to allocate a buffer with
the same size as the area that need to have black background.
This add support for non-standard strides to be used. Note that
some extra work is needed for multi-plane format which may have
a different GstMemory object per plane. This is not currently a
problem since SHM interface is limited to 1 memory.
The buffer pool API does not allow multiple of owner. This otherwise
lead to error when renegotiation take place. Aso consider the
allocation query "need_pool" boolean.
Fixes an assertion when moving from passthrough to non-passthrough
Without an explicit reconfigure, glfiter won't have created the GL
resources such as the FBO, GL bufferpool, etc and basetransform will
allocate sysmem buffers instead.
This makes the viewporter interface optional. The end result is
obviously far from optimal, though it greatly helps testing on older
compostitors or gnome-wayland. We can make it strictly needed later when
this new interface get widely adopted.
When start qmlglsink app, it will set NULL buffer to GstQSGTexture
in which case that qt_context_ will be a random value and cause
gst_gl_context_activate() fail.
https://bugzilla.gnome.org/show_bug.cgi?id=770925
Previously it was created in the init function and destroyed in ::stop, which
lead to segfaults when reusing the element.
Now the upload object is created in ::transform_caps if it is NULL, which is the
earliest we need it. The other vfuncs already bail out if the upload object is
NULL, which means that negotiation wasn't done.
