This fixes a build error if Qt was build without accessibility support:
../../../../../gstreamer/subprojects/gst-plugins-good/ext/qt/qtglrenderer.cc:
In member function 'bool GstQuickRenderer::init(GstGLContext*, GError**)':
../../../../../gstreamer/subprojects/gst-plugins-good/ext/qt/qtglrenderer.cc:341:13:
error: 'QCoreApplication' was not declared in this scope; did you mean 'QApplication'?
../../../../../gstreamer/subprojects/gst-plugins-good/ext/qt/qtglrenderer.cc:341:31:
error: 'app' was not declared in this scope
../../../../../gstreamer/subprojects/gst-plugins-good/ext/qt/qtglrenderer.cc:341:37:
error: 'QCoreApplication' is not a class, namespace, or enumeration
[...]
../../../../../gstreamer/subprojects/gst-plugins-good/ext/qt/qtglrenderer.cc:458:5:
error: 'QEventLoop' was not declared in this scope; did you mean 'QEvent'?
../../../../../gstreamer/subprojects/gst-plugins-good/ext/qt/qtglrenderer.cc:459:9:
error: 'loop' was not declared in this scope
If accessibility is enabled, the includes for QCoreApplication and QEventLoop
are indirectly pulled via QWidget.
Add the required headers as documented in [1] and [2].
[1] https://doc.qt.io/qt-5/qcoreapplication.html
[2] https://doc.qt.io/qt-5/qeventloop.html
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4815>
Previously, we would create a new GstMemory per write operation
and then append them to the GstBuffer. This would cause a reallocation
every 16 Memories which is an issue since the png encoder will usually
do write in a pattern of 4, 8 and 8k bytes repeating until the frame
is done.
Instead allocate a single GstMemory and keep writting it into it
with a manual index. Much like the jpegenc does.
Doing some basic testing With a testsrc snow pattern at 4k and 8k
the same pipeline would take ~3.30s to encode a 4k frame and ~23s
for an 8k. At 4k 0.70s/33% is taken by memory allocations, while at
8k its ~10.5s/45%.
With this patch, at 4k the pipeline takes ~2.40s and at 8k only 9.60s
making this 28% and 58% faster accordingly on my laptop, and
allocation runtime is dropped to subsecond times.
Here's the test pipeline used, increase num-buffers in image freeze
to gather more samples.
```
gst-launch-1.0 videotestsrc num-buffers=1 pattern=snow ! imagefreeze num-buffers=1 ! \
video/x-raw,width=7680,height=4320 ! pngenc ! fakesink
```
Close#2717
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4944>
lc3enc:
- encodes raw audio into lc3 format
- uses the default bitrate property and frame duration
from the caps to determine the byte count of
the encoded frames if it is not specified in
the downstream caps after negotiation
- uses the same byte count value for all the channels
- all the common session configuration parameters
are passed in the src caps
lc3dec:
- decodes an lc3 encoded audio
- sink caps should contain all the common session configuration
params
- uses frame_duration and frame_bytes (byte count) in the sink
caps as parameters along with sample rate and channel count
- byte count is same for all the channels
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4376>
`srt_rejectreason_str` doesn't give us a unique string for every
possible reason. Peers can define their own reasons and SRT just gives
us the string `"Application-defined rejection reason"` for all of them.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4948>
When gst_element_set_state is called in _setup_locked and errors, the
callback is already processed before we reach handle_current_async, and
the timer is started even though it's finished processing, which results
in a NULL pointer crash later in async_timeout_cb.
To fix this, we check that it's still processing before calling
handle_current_async.
Fixes#1683
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4936>
The aim of this example is to show how to make use of the accept-certificate
signal from a GTK GUI, and prompt user in case of invalid certificate.
There are two subtleties to be aware of:
1. the signal is emitted from the GStreamer streaming thread, therefore the
caller can't modify the GUI straight away, instead they must do it from the
main thread (eg. by using g_idle_add())
2. in case of a redirection, then a TLS failure, the caller won't know
about the redirection. Actually, it's possible to be notified of the
redirection by watching "message:element" and inspecting http-headers,
but even in that case, the signal will be received *after* the signal
"accept-certificate" (even though the redirection happened *before*).
This second point is tricky. It's not uncommon to have servers that redirect
http requests to https. So errors of the type "HTTP -> HTTPS -> TLS error"
happen, and if the caller doesn't care about redirection, they might prompt
users with a message such as "TLS error for URL http://...", which wouldn't make
much sense.
This example shows how to handle that right, by connecting to the signal
"message:element", inspecting the http-headers, and in case of redirection,
updating the TLS error dialog to indicate that the request was redirected.
Here are a few examples of streams that exhibit TLS failure (at the time of
this commit, of course):
* https://radiolive.sanjavier.es:8443/stream: unknown-ca
* https://am981.ddns.net:9005/stream.ogg: unknown-ca
* http://stream.diazol.hu:7092/zene.mp3: redir then bad-identity
* https://streaming.fabrik.fm/izwi/echocast/audio/index.m3u8: unknown-ca
(this one is a HLS stream)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4925>
With libsoup 2.x, it was possible to know when there was a TLS failure, as
libsoup provided the "special http status code" SOUP_STATUS_SSL_FAILED.
However these special codes were dropped with libsoup 3.x: now libsoup emits
the accept-certificate signal when there's a TLS failure.
This commit adds a signal "accept-certificate" to SoupHttpSrc, which is in fact
just about forwarding the signal from SoupMessage (which is, itself, forwarded
from GTlsConnection). Note that, in case of libsoup 2.x, the signal is never
emitted.
Fixes: #2379
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4925>
Adding new subtitle overlay element. It's a bin which is wrapping
two internal elements dwritesubtitlemux and dwritetextoverlay.
* dwritesubtitlemux: A new internal element to aggregate subtitle
buffers and to attach the aggregated subtitle buffers on
video buffer as meta.
* dwritetextoverlay: Extracts/renders the subtitle meta and
discard the meta after rendering.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4934>
In the current implementation, we support for most pixel format left
and top padding by changing the offset in the video meta. Though, to
align driver bytesused to the offset, we recalculate the offset, which
removed the modification we did before.
Instead, save the plane size, and truncate the driver reported bytesused
to the expected size, which ensures that the offsets still match. This
should also fix issues were the buffer size ended up bigger then the
pool size due to driver introduced padding.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4920>
There's no reason to release GstMemory manually at all.
If we do release GstMemory, corresponding GstBuffer will be
discarded by GstBufferPool baseclass because the size is changed
to zero.
Actual cause of heavy CPU usage in case of fixed-size pool
(i.e., decoder output buffer pool) and if we remove GstMemory from
GstBuffer is that GstBufferPool baseclass is doing busy wait in acquire_buffer()
for some reason. That needs to be investigated though, discarding
and re-alloc every GstBuffer is not ideal already.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4935>
