`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>
Fixes test: validate.uridecodebin.expose_raw_pad_caps
testsrcbin (currently part of debugutilsbad) is an useful element for
validate tests.
validate.uridecodebin.expose_raw_pad_caps makes use of it.
Unfortunately, because validate tests with GStreamer only run with
whitelisted plugins and `debugutilsbad` wasn't in the whitelist, the
test was failing and being auto-skipped.
This patch adds debugutilsbad to the whitelists used by validate tests
in subprojects with a validate/meson.build.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4931>
The current way of using gst_video_info_set_format() will change all
fields of the GstVideoInfo. We only need to change its format, stride
and offset fields.
In order to keep the consistency with th common drm API, we rename the
gst_va_video_info_from_dma_info() into gst_va_dma_drm_info_to_video_info().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4883>
The current way only selects the best video format from the first
structure of the caps. The caps like:
video/x-raw(memory:VAMemory),drm-format=(string)NV12; \
video/x-raw(memory:VAMemory),format=(string){ NV12, Y210 }
Will just choose NV12 as the result, even the bitstream is 10 bits.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4928>
