This commit negotiate F32 audio format if MODE_FLOAT used in wavpack file.
Wavpack float mode is always in 32-bit IEEE format.
The following pipeline plays distorted audio if source file is encoded in float mode:
gst-launch-1.0 filesrc ... ! wavpackparse ! wavpackdec ! pulsesink
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/894>
The crash is caused by a race condition where the render thread
calls a method on the QtGLVideoItem instance that was
previously destroyed by the main thread.
Also, less frequently, QtGLVideoItem::onSceneGraphInitialized
is called when QQuickItem::window is null, also causing a crash.
Fixes#798
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/777>
- introduce two new properties:
* temporal-scalability-layer-flags:
Provide fine-grained control of layer encoding to the
outside world. The flags sequence should be a multiple of
the periodicity and is indexed by a running count of encoded
frames modulo the sequence length.
* temporal-scalability-layer-sync-flags:
Specify the pattern of inter-layer synchronisation (i.e.
which of the frames generated by the layer encoding
specification represent an inter-layer synchronisation).
There must be one entry per entry in
temporal-scalability-layer-flags.
- apply temporal scalability settings and expose as buffer
metadata.
This allows the codec to allocate a given frame to the correct
internal bitrate allocator. Additionally, all the
non-bitstream metadata needed to payload a temporally scaled
stream is now attached to each output buffer as a
GstVideoVP8Meta.
- add unit test for temporally scaled encoding.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/728>
With recent libvpx versions, multithreading can be enabled on
a per-tile basis, instead of on a per tile-column basis.
In combination with the new tile-rows property, this allows the
encoder to make much better use of the available CPU power.
Bump minimum libvpx version to 1.7.0
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/707>
With Qt 5.15 multiple qmlgloverlay elements would produce:
ASSERT: "!m_gl->property(QSG_RENDERCONTEXT_PROPERTY).isValid()" in file /path/to/qt5/qtdeclarative/src/quick/scenegraph/qsgdefaultrendercontext.cpp, line 121
Workaround by setting the (seeminigly unused) property before
initialization.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/695>
Range errors are already turned into EOS when the size is not known.
Do the same thing if the request as outside the known content size.
This can be triggered by seeking in a queue2:
- Ensure that the range containing the end of the file is available.
- Seek into this range from a different range.
- queue2 creates a seek event with start=<file-size>
- this results in a "Requested Range Not Satisfiable" error
Fixes#452
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/385>
As part of this also change the default bitrate value to 0. The default
value was 256000 previously. In reality, if the property was not set the
bitrate value would be scaled according to the resolution which is not
very intuitive behavior. It is better to use 0 for this purpose. Now
together with newly introduced property "bits-per-pixel" 0 means to
assign the bitrate according to resolution/framerate.
The default bitrates are now
- 1.2Mbps for VP8 720p@30fps
- 0.8Mbps for VP9 720p@30fps
and scaled accordingly for different resolutions/framerates.
Previously the default bitrate was also not scaled according to the
framerate but only took the resolution into account.
This also fixes the side effect of setting bitrate to 0. Previously
encoder would not produce any data at all.
Addition from Sebastian Dröge <sebastian@centricular.com> to assume
30fps if no framerate is given in the caps instead of not calculating
any bitrate at all.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/611>
For VP8 it's possible to signal width or height to be 0, but it does
not make sense to do so. For VP9 it's impossible. Hence, we most
likely have a corrupt stream. Trying to negotiate caps downstream with
either width or height as 0 will fail with something like
gst_video_decoder_negotiate_default: assertion 'GST_VIDEO_INFO_WIDTH (&state->info) != 0' failed
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/610>
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.
