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>
We can only reliably use the adaptation field discontinuity flag if our input is
properly timestamped on a regular basis (ex: UDP, DVB, RTP, etc...).
For HLS and other systems which don't provide that information, we should not
reset the base observations. Otherwise we would potentially end up picking a
reference time from a long time ago.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8480>
Adding new h264ccextractor element. This element will extract
closed caption meta from H.264 stream, and output in display order.
For the frame reordering, this element is implemented as a subclass
of h264decoder but without actual frame decoding.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6580>
Checking whether rtpjitterbuffer actually timestamps the buffers according to
the RFC7273 clock definition and rtpjitterbuffer configuration required looking
at the DEBUG logs.
This commit adds an entry in the rtpjitterbuffer stats to indicate if
conditions are met for RFC7273 to be active.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7829>
As per the C++ standard, any usage of a std::set::iterator after it has
been erased from the collection results in undefined behaviour. This has
resulted in application crashes due to CUDA illegal address errors.
This commit fixes the issue by copying and incrementing the iterator
within any for-loops that also invoke std::set::erase.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8472>
Previously there was no validation at all and the defaults were set if the
colorimetry was not set or invalid, but there's not really any connection
between colorimetry and chroma-site.
More validation could make sense in the future.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8258>
Since the documentation job is manually triggered, the latest docs might not be
in the most recent pipelines. Change the pipeline listing to iterate over all
pipelines until we find the last successful documentation build.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8463>
This doesn't always bring visible issue, but is formally incorrect:
not chaining up means that the code doesn't trigger GstObject and
GstElement "constructed" implementations.
In particular both GstElement's and GstObject's classes in
"constructed" may sign up this object for tracing and
GstObject's class sets GST_OBJECT_FLAG_CONSTRUCTED flag.
If we don't chain up none of this is going to be executed.
For example, before the fix leaks tracer couldn't detect this leak:
```c
int main (int argc, char **argv) {
g_setenv ("GST_TRACERS", "leaks(name=all-leaks)", TRUE);
g_setenv ("GST_DEBUG", "GST_TRACER:7", TRUE);
g_setenv ("G_DEBUG", "fatal-warnings", TRUE);
gst_init (&argc, &argv);
// leak audiomixer: doesn't detect because it's based on the aggregator
gst_element_factory_make ("audiomixer", "Jerry");
// leak videoconvert: this one is detected fine because it's not
// based on the aggregator
//gst_element_factory_make ("videoconvert", "Tom");
gst_deinit ();
return 0;
}
// $ cc tst.c $(pkg-config --cflags --libs gstreamer-1.0) -o tst && ./tst
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8416>
When the stream resolution change it is needed to negotiate
a new pools and to update the caps.
Resolution change could occurs on a new sequence or a new
picture so move resolution change detection code in a common
function.
Only call streamoff if the resolution occur while decoding a key frame.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8064>
We must drain the pending output picture so that subclass can renegotiate
the caps. Not doing so while still renegotiating would mean that the
subclass would have to do an allocation query before pushing the caps.
Pushing the caps now without this would also not work since these caps
won't match the pending buffers format.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8064>
