We don't do any blending by ourselves since a while now.
Note that this is a regression in "supported" formats: previously
ARGB64 was supported, for example, but in practice it caused blending to
not take place at all.
Without a qmlglsink, we need to retrieve the window system display
ourselves rather than relying solely on qmlglsink to have priority on
the choice of display.
deleting a QOpenGLFrameBufferObject needs to occur on the same thread it
was created on in order to actually free the relevant resources
immediately. Otherwise, they will be queued for deletion and not freed
until the associated QOpenGLContext is destroyed.
By explictly including QtGui/qopengl.h we force the code path that
defines GLsync in the Qt-specific way. Without that, some platforms
failed to compile the qmlgl plugin, since neither Qt nor gstreamer
defined GLsync then, leading to e.g.:
```
make[4]: Entering directory '/.../gst-plugins-good-1.16.1/ext/qt'
CXX libgstqmlgl_la-qtitem.lo
In file included from gstqtgl.h:32,
from qtitem.h:27,
from qtitem.cc:28:
/.../usr/include/gstreamer-1.0/
gst/gl/gstglfuncs.h:93:17: error: expected identifier before ‘*’ token
ret (GSTGLAPI *name) args;
^
/.../usr/include/gstreamer-1.0/
gst/gl/glprototypes/sync.h:27:1: note: in expansion of macro
‘GST_GL_EXT_FUNCTION’
GST_GL_EXT_FUNCTION (GLsync, FenceSync,
^~~~~~~~~~~~~~~~~~~
```
Disable session sharing and cookie jar when cookies property is set.
The cookie jar actually replaces or removes any existing Cookie header
set on the message, so the cookies property was effectively being
ignored. There doesn't appear to be a way to inject the cookies into the
jar without having to specify matching domains etc., so it's not
possible to simulate the old behaviour of unconditionally sending the
cookies with all messages, besides simply disabling the cookie jar.
In Google webrtc, the setting VP8E_SET_STATIC_THRESHOLD is set to 1
(except when the content is known to be static very often in which
case it is set to 100, i.e. when sharing screen with Google Hangouts).
The cpu usage drops a lot when using 1 for above setting because it
allows the encoder to skip static/low content blocks. The current
0 default value uses too much cpu and confuses the user regarding
the cpu usage expectations. User expects vp8enc to use low cpu by
default.
Documentation of VP8E_SET_STATIC_THRESHOLD:
https://github.com/webmproject/libvpx/blob/master/vpx/vp8cx.h#L188
chromium/webrtc:
b484ec0082/modules/video_coding/codecs/vp8/libvpx_vp8_encoder.cc (822)Closes#58
If Mesa is built without X11 headers, building against Mesa EGL headers
requires a dependency on egl.pc, to define MESA_EGL_NO_X11_HEADERS.
This fixes a build error when compiling ext/qt/gstqtglutility.cc:
In file included from /usr/include/EGL/egl.h:39,
from /usr/include/gstreamer-1.0/gst/gl/egl/gstegl.h:44,
from ../gst-plugins-good-1.16.1/ext/qt/gstqtglutility.cc:43:
/usr/include/EGL/eglplatform.h:124:10: fatal error: X11/Xlib.h: No such file or directory
By passing `NULL` to `g_signal_new` instead of a marshaller, GLib will
actually internally optimize the signal (if the marshaller is available
in GLib itself) by also setting the valist marshaller. This makes the
signal emission a bit more performant than the regular marshalling,
which still needs to box into `GValue` and call libffi in case of a
generic marshaller.
Note that for custom marshallers, one would use
`g_signal_set_va_marshaller()` with the valist marshaller instead.
If the the height is not a multiple of the macro block size then the memory
of the last line is reused for all extra lines. This is no problem if the
last line is duplicated properly. However, if the extra lines are not
initialized properly during encoding, then the last visible line is
overwritten with undefined data.
Use a extra buffer to avoid this problem.
Used to print:
|Run-time dependency vpx found: YES 1.7.0
|Message: libvpx provides VP8 encoder interface (vpx_codec_vp8_cx_algo)
|Message: libvpx provides VP8 decoder interface (vpx_codec_vp8_dx_algo)
|Message: libvpx provides VP9 encoder interface (vpx_codec_vp9_cx_algo)
|Message: libvpx provides VP9 decoder interface (vpx_codec_vp9_dx_algo)
|Dependency vpx found: YES (cached)
|Dependency vpx found: NO found '1.7.0' but need: '>=1.8.0'
|Run-time dependency vpx found: NO (tried pkgconfig and cmake)
We can check the version of the found dep in a way that
doesn't produce this confusing output.
Port objects acquired with jack_get_ports() need to be freed with
jack_free(3), not stdlib free().
On Windows, Jack may be linked against different libc than GStreamer
libraries so free()ing port objects directly might cause crash because
of libc mismatch.
As of Qt >= 5.5, qmake do not link to opengl32 by default anymore. This commit adds opengl32.lib to the .pro
file so that the plugin can be build using QtCreator on Windows.
On other OSes, it's not possible to have qmake or the qt5 pkg-config
files and not have moc, and `moc` will not be in `PATH`, so this only
causes problems.
The FLAC specification states that the data is processed in blocks, regardless of the number of channels. Thus, The latency can be calculated using the blocksize and rate. For example a 1 second block sampled at 44.1KHz has a blocksize of 44100
It is possible that PulseAudio adds formats that are not yet supported
in pulsesink, and in those cases, we want to gracefully skip them rather
than cause an assert on a NULL caps.
This was originally added for fixing conflicting definitions between
Android and Qt, but times have changed and now this breaks the build
on iOS:
[...]/OpenGLES.framework/Headers/ES3/gl.h:1006:48: error: unknown type name 'gst_qt_GLsync'
GL_API void GL_APIENTRY glGetSynciv (GLsync sync, GLenum pname, GLsizei bufSize, GLsizei* length, GLint* values) OPENGLES_DEPRECATED(ios(7.0, 12.0), tvos(9.0, 12.0));
^
../ext/qt/gstqtgl.h:49:16: note: expanded from macro 'GLsync'
#define GLsync gst_qt_GLsync
^
6 errors generated.
Instead, we simply avoid defining GLsync ourselves if we're using Qt.
It makes no sense for a decoder to output a BYTES segment, and
many elements one would plug downstream of a video decoder assume
the segments they receive are in TIME format, for example this fixes:
gst-validate-1.0 filesrc location=opacity01.svg ! gdkpixbufdec ! \
videobalance ! videoconvert ! fakesink
In that case, videobalance was emitting an assertion when trying to
call gst_object_sync_values()
Needs gnustl for C++ STL support, which is the GNU STL on Android API
19 and older, and is a wrapper for the llvm-libc++ STL on newer APIs.
QtGui C++ templates use GL functions, so GLESv2 is needed at link time
The android code path is slightly different than the EGLFS one,
so I added previously a HAVE_QT_ANDROID define for use with qmake.
Here I also add it in meson, although I expect nobody will ever use
meson to build this, as it's complicated.
it is perfectly legal to use the <module/class> style of includes with Qt
and it avoids the need for having the module's include dir in the include path
Binding the vertex array to 0 will unbind everything else already.
In the previous order older versions of the Intel GL driver caused
errors to be printed for every single call when disabling the vertex
attrib arrays after binding the vertex array to 0.
This is needed as a precursor to allowing capture of IEC61937
formats. We now also need to include the channel map while converting
format info to caps so that a correct channel mask is generated for
pulsesrc's caps.
PA_INVALID_INDEX, the default value, is unfortunately !0.
Setting the volume before the stream is created will put the ring
buffer in error state. Unfortunately, that's what spice-gtk does.
If the pipeline consumes the data slower than the available network speed,
for example because sync=true, is useless to increase the blocksize and
reading in too big blocksizes can cause the connection to time out
Closes#463
In 2018 khronos changed the gl header guards. If we don't detect
this properly we would end up with plenty of symbol redifinition
(since we would be importing twice the "same" header).
Instead detect if the "newer" header was already included and if
so define the "old" define to avoid this situation
Fixes#523
Pull in video frame fields into local variables. Without this the
compiler must assume that they could've changed on every use and read
them from memory again.
This reduces the inner loop from 6 memory reads per pixels to 4, and the
number of writes stays at 3.
PulseAudio defines PA_RATE_MAX as the maximum sampling rate that it
supports. We were previously exposing a maximum rate of INT_MAX, which
is incorrect, but worked because nothing was really using a rate greater
than 384000 kHz.
While playing DSD data, we hit a case where there might be very high
sample rates (>1MHz), and pulsesink fails during stream creation with
such streams because it erroneously advertises that it supports such
rates.
Since PA_RATE_MAX is #define'd to (8*48000U), we can't just use it in
the caps string. Instead, we fix up the rate to what we actually support
whenever we use our macro caps.
This allows us to use the GstVideoOverlayComposition API and correctly
handle pre-multiplied alpha, while also only doing the alpha conversion
once instead of twice for the whole frame.
At a later point we can attach the meta to the buffer instead of
blending ourselves if downstream supports that.
https://bugzilla.gnome.org/show_bug.cgi?id=797091
The speex headers assume that WIN32 will always be defined when
building on Windows, but this is only true by default on MinGW.
Always set it explicitly.
We now have options for all plugins, so we will just disable these in
the cerbero recipe instead. These require external deps, so they won't
affect gst-build either.
This effectively (but optionally) requires libjpeg-turbo which
ships with a .pc file and is what pretty much everyone these days
uses anyway for libjpeg, so shouldn't be a problem hopefully.
https://bugzilla.gnome.org/show_bug.cgi?id=796947
Otherwise there may be no valid typedef of GLsync.
...
/usr/include/gstreamer-1.0/gst/gl/gstglfuncs.h:93:24: note: in definition of macro 'GST_GL_EXT_FUNCTION'
ret (GSTGLAPI *name) args;
^~~~
/usr/include/gstreamer-1.0/gst/gl/glprototypes/sync.h:33:23: error: 'GLsync' has not been declared
(GLsync sync))
^~~~~~
...
https://bugzilla.gnome.org/show_bug.cgi?id=796879
gst_structure_get() is declared with G_GNUC_NULL_TERMINATED, ie
__attribute__((__sentinel__)), which means gcc will generate a
warning if the last parameter passed to the function is not NULL
(where a valid NULL in this context is defined as zero with any
pointer type).
The C code callers to gst_structure_get() within gst-plugins-good
use the C NULL definition (ie ((void*)0)), which is a valid sentinel.
However gstid3v2mux.cc uses the C++ NULL definition (ie 0L), which
is not a valid sentinel without an explicit cast to a pointer type.
Upstream-Status: Pending
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Note from Edward Hervey: Patch from git.yoctoproject.org
musl libc generates warnings if <sys/poll.h> is included directly.
Upstream-Status: Pending
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Tested on linux with X11/wayland and semi-tested on Windows.
Windows crashes on item destruction however this is better than nothing.
Fix up some win32 build issues on the way with mismatched {} and
G_STMT_{START,END}
Like pngenc, automatically send an EOS message.
Example of bin:
appsrc ! jpegenc snapshot=true ! filesink location=out.jpg
This is especially useful for limited/slow hardware.
Otherwise calling gst_video_convert_sample() is a better option
(internally uses videoconvert and videoscale).
https://bugzilla.gnome.org/show_bug.cgi?id=755453
If a lot of seek method is called very quickly, sometimes data reading
and do_request occurs while seek flush event is occurring and error
occurs because retry_count
reaches to the max. Thus, reset retry_count if flush occurs after
do_request and read_buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=790199
Some cameras fail to send an end-of-image marker (EOI)
and can't be properly decoded by either JPEG or libjpeg.
This commit parses the frame, making sure it has an EOI.
If there isn't one, the EOI gets added to the buffer.
A similar fixup is done in the rtpjpegdepay element,
and it makes sense to do it in jpegdec as well.
Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
https://bugzilla.gnome.org/show_bug.cgi?id=791988
