Prevent a condition where splitmuxsink won't go back to NULL state
after a child element fails to change state by making sure that
a READY->READY state change doesn't fail, and by returning
GST_FLOW_ERROR or GST_FLOW_FLUSHING upstream to shut down streaming
as quickly as possible.
This can happen after (for example) setting an invalid filename
on the sink element. In that case, the READY->PAUSED transition
fails, but with internal elements still in the NULL state. Trying
to set splitmuxsink back to NULL then ends up trying to bring
those NULL elements up to READY with a READY->READY transition,
(which fails, prevent splitmuxsink from getting to NULL)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/1023>
There is currently no way for users to receive incoming events from
appsink while keeping them properly serialized with the buffers flow.
This can be especially useful when application is injecting custom
downstream events into the pipeline and needs to know when they reached
appsink.
Solving this by adding a new signal notifying about new incoming events
and a set of action signals and method to pull those events.
The API is actually pulling the samples and events all together as they
are actually fetched from the same queue.
Having a specific API to pull only events would have the side effect of
discarding samples (and pulling samples would discard events) making
this API not convenient for users.
Partially fix#247
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1046>
The problem is that EGLNativeWindowSurface and wl_egl_surface are the
same object underneath, so we must recreate both together. As an
optimization, the EGLNativeWindowSurface wrapper is only re-created
if the window_handle changed.
On Mesa, this would cause crash, which will be fixed by:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11979
And will lead to proper errors in the future or on other GL stack. This
issue was encounter using a permanent GstGLDisplay after cycling one of
multiple independent pipelines through NULL state.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1230>
120 bytes in 5 blocks are definitely lost in loss record 7,615 of 9,510
at 0x484486F: malloc (vg_replace_malloc.c:380)
by 0x58A2938: g_malloc (gmem.c:106)
by 0x58BA1F4: g_slice_alloc (gslice.c:1069)
by 0x588F059: g_list_prepend (glist.c:335)
by 0x5B9C5C0: select_best_master_clock (gstptpclock.c:756)
by 0x5B9CA8E: cleanup_cb (gstptpclock.c:1930)
by 0x589AD20: g_timeout_dispatch (gmain.c:4889)
by 0x589A4CE: UnknownInlinedFun (gmain.c:3337)
by 0x589A4CE: g_main_context_dispatch (gmain.c:4055)
by 0x58EE4E7: g_main_context_iterate.constprop.0 (gmain.c:4131)
by 0x5899A92: g_main_loop_run (gmain.c:4329)
by 0x5B9BA4C: ptp_helper_main (gstptpclock.c:1980)
by 0x58C8C31: g_thread_proxy (gthread.c:826)
576 bytes in 24 blocks are definitely lost in loss record 8,782 of 9,510
at 0x484486F: malloc (vg_replace_malloc.c:380)
by 0x58A2938: g_malloc (gmem.c:106)
by 0x58BA1F4: g_slice_alloc (gslice.c:1069)
by 0x588F059: g_list_prepend (glist.c:335)
by 0x5B9C5C0: select_best_master_clock (gstptpclock.c:756)
by 0x5B9EFA0: handle_announce_message (gstptpclock.c:934)
by 0x5B9EFA0: handle_ptp_message (gstptpclock.c:1765)
by 0x5B9EFA0: have_stdin_data_cb (gstptpclock.c:1851)
by 0x589A4CE: UnknownInlinedFun (gmain.c:3337)
by 0x589A4CE: g_main_context_dispatch (gmain.c:4055)
by 0x58EE4E7: g_main_context_iterate.constprop.0 (gmain.c:4131)
by 0x5899A92: g_main_loop_run (gmain.c:4329)
by 0x5B9BA4C: ptp_helper_main (gstptpclock.c:1980)
by 0x58C8C31: g_thread_proxy (gthread.c:826)
by 0x5DA4298: start_thread (pthread_create.c:481)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/852>
Currently the decoder selection is very naive: The type with the highest
rank that matches the current caps is used. This works well for software
decoders. The exact supported caps are always known and the static caps are
defined accordingly.
With hardware decoders, e.g. vaapi, the situation is different. The decoder
may reject the caps later during a caps query. At that point, a new decoder
is created. However, the same type is chosen an after several tries,
decodebin fails.
To avoid this, do the caps query while adding the decoder and try again
with other decoder types if the query fails:
1. create the decoder from the next matching type
2. add and link the decoder
3. change the decoder state to READY
4. do the caps query
if it fails then remove the decoder again and go back to 1.
5. expose the source pad
6. sync the decoder state with the parent.
This way, the decoder is already part of the pipeline when the state change
to READY happens. So context handling should work as before.
Exposing the source pad after the query was successful is important:
Otherwise the thread from the decoder source pad may block in a blocked pad
downstream in the playsink waiting for other pads to be ready.
The thread now blocks trying to set the state back to NULL while holding
the SELECTION_LOCK. Other streams may block on the SELECTION_LOCK and the
playsink never unblocks the pad. The result is a deadlock.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1201>
When the window is called, we properly destroy all surfaces, which effectively
will unmap that surface and should make it disapear on screen, but we also
destroy the wl_source, a GSource that is resposibble of dispatching and executing
messages to/from the Wayland server.
As a side effect, the server never gets the message and the surfaces are
"leaked" on the server. We fix this using wl_display_flush() before destroying
the wl_source.
Fixes#815
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1226>
Previously one of the branches did not check for the property value. To
avoid this in the future, check inside the QoS calculation function
instead.
As a side effect this now always prints the debug messages into the logs
when samples are dropped, which is useful information even without the
QoS messages.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1224>
If a buffer is dropped during resyncing on a discont because either its
end offset is already before the current output offset of the
aggregator or because it fully overlaps with the part of the current
output buffer that was already filled, then don't just assume that the
next buffer is going to start at exactly the expected offset. It might
still require some more dropping of samples.
This caused the input to be mixed with an offset to its actual position
in the output stream, causing additional latency and wrong
synchronization between the different input streams.
Instead consider each buffer after a discont as a discont until the
aggregator actually resynced and starts mixing samples from the input
again.
Also update the start output offset of a new input buffer if samples
have to be dropped at the beginning. Otherwise it might be mixed too
early into the output and overwrite part of the output buffer that
already took samples from this input into account.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/912
which is a regression introduced by https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1180/
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1224>
A video decoder can now receive subframes and start decoding
instead of waiting for the full frame to be complete.
Subframe support will reduce latency as described in the
video encoder base class.
A unit test illustrating this API is available in
tests/check/libs/videodecoder.c.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/454>
Instead of using the new "application/x-cbcs" caps, we are just adding
a new structure field "ciphe-mode", to indicate which encryption scheme
is used: "cenc", "cbcs", "cbc1" or "cens".
Similarly for the protection metadata, we add the "cipher-mode" field
to specify the encryption mode with which the buffers are encrypted.
"cenc": AES-CTR (no pattern)
"cbc1": AES-CBC (no pattern)
"cens": AES-CTR (pattern specified)
"cbcs": AES-CBC (pattern specified, using a constant IV)
Currently only "cenc" and "cbcs" are supported.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/1013>
When getting backtraces, we were always creating a new Dwfl context and then
discarding it. The problem with that is that it resulted in having to re-scan a
lot of information for every single backtrace.
In order to fix that issue, use a global on-demand Dwfl context and use it with
a lock.
Furthermore, we were scanning the mappings of the
process (dwfl_linux_proc_report) for *every single step* in the backtrace, and
that function is horrendously expensive (does sscanf on /proc/PID/maps
...). While there is a possibility that new mappings might be available (new
plugins being loaded for example), we can limit ourselves to just do it once per
backtrace.
These two modifications speed up the elements_leaks unit test (which traces all
pads with full backtraces) by a factor of 6.
Partially fixes#567
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/504>
Implement 8-bit values of SMPTE RP 2019-1:2014. The bar widths and
heights are the result of fractions as integers. The remainders of
widths are distributed in a way that they match the values in Table
C.1 (a) in the specification.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1063>
