The parent class will allow the handle to be reused at the end of the function.
If we are still modifying the released fence, then another thread can acquire
the fence while we are still clearing some of its data and produce a data race
or a leaked fence depending on which thread wins.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8491>
This fix handles the case where the order of components in the cmpd box
does not correspond to the order used for a specific track. That
is the case where the uncC component_index values are something
other than 0, 1, 2, 3.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8483>
Add a button in the web interface to trigger pipeline dumps via websocket,
replacing the need to manually send SIGUSR1 to the process. Also set up
the pipeline-snapshot tracer with the proper websocket URL by default.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7999>
Suppose you invoke gst-launch with this invalid pipeline:
```
$ gst-launch-1.0 videotestsrc num-buffers=10 ! x264enc name=enc ! mux.sink_0 \
mpegtsmux name=mux ! fakesink
0:00:00.018631594 351169 0xb523090 ERROR GST_PIPELINE
subprojects/gstreamer/gst/parse/grammar.y:1151:gst_parse_perform_link:
could not link enc to mux
WARNING: erroneous pipeline: could not link enc to mux
```
The error message you get is not very helpful. This is a pity, because
this is where the error comes from:
```c
static GstPad *
gst_base_ts_mux_request_new_pad (GstElement * element, GstPadTemplate * templ,
const gchar * name, const GstCaps * caps)
{ // [...]
GST_ELEMENT_ERROR (element, STREAM, MUX,
("Invalid Elementary stream PID (0x%02u < 0x40)", pid), (NULL));
return NULL;
```
mpegtsmux posted an error with an explanation of why the linking failed.
However, since the error ocurred within gst_parse_launchv(), gst-launch
could not have set a bus handler, and the error message got discarded.
This patch attempts to make gst-launch more user-friendly by setting a
temporary bus handler during early bin construction to catch error
messages like this.
The errors are logged as ERROR level in the GST_PIPELINE category.
However, this is not enough, as GST_LEVEL_DEFAULT defaults to
GST_LEVEL_NONE in releases. In other words, outside of the dev
environment, GStreamer won't print ERROR logs by default.
To make sure the errors can reach users of packaged versions of
GStreamer, a new AtomicRcBox-based struct is added: reason_receiver_t.
graph_t owns a reference to reason_receiver_t and so does the temporary
bus handler.
When the temporary bus handler receives an error message, the `reason`
field of `reason_receiver_t` is filled with the error message.
Later, when SET_ERROR() is called as a consequence of the operation that
posted the error having returned failure, the reason message is
extracted and added to the GError message.
This is how the resulting error would look in the example from above:
WARNING: erroneous pipeline: could not link enc to mux --
GstMpegTsMux <mux> posted an error message: Invalid Elementary
stream PID (0x00 < 0x40)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8417>
This leads to spurious negotiation failures because the configured method can
change over time and caps queries (and thus transform_caps) are happening
independently from configuring caps. Instead prefer the transformed caps of the
current method, but always also return the transformed caps for all other
methods. Previously all other methods would've only been used if the current
method returned empty caps. If a different method is needed later when
configuring the caps, it will be and was selected regardless.
Later during caps fixation, prefer the caps of the current method too for the
fixated caps if possible in any way.
This should preserve the desired behaviour of preferring the current method if
possible but to change to a different method if nothing else is possible, while
also returning consistent (and not too narrow) caps every time.
The way how the current method was checked was also racy as the current method
might change at any moment during caps query handling, and apart from
inconsistent results also a NULL pointer dereference was possible here. Use the
GST_OBJECT_LOCK to protect access to the current method like in other places.
This part of the code was introduced in f349cdccf5
and tried to be fixed multiple times over the years without addressing the root
cause of caps queries and caps configuration happening independently from each
other, e.g. in !2687 and !2699.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8431>
