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>
With the old method of adding build RPATHs, only the libsoup as
a subproject was supported. However, it's possible to use Homebrew for
libsoup too by adding libsoup as a dependency to the target (even
though we don't link to it).
Apple ld will not add a LC_LOAD_DYLIB entry for a library unless there
are symbols that need it because meson passes `-dead_strip_dylibs`, so
we can do this without issue.
As a bonus, this ensures the correct build RPATHs in all cases.
Additionally, we still need to explicitly add an LC_RPATH for the
installed case.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/4027
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8403>
In many places in the log tracer %d was used for data types we have
string format functions. This is especially problematic when the data
type is not immediately obvious to the reader (e.g. gboolean vs
GstFlowRet, where TRUE==1 but GST_FLOW_OK==0) or the values are not easy
to memorize (GST_STATE_CHANGE_PLAYING_TO_PAUSED==35).
This patch replaces all the integer codes with string representations so
that the logs are easier to understand by humans.
The formatting of GstBufferList by the log tracer is also updated to use
GST_PTR_FORMAT instead of a raw pointer, so the user can see the
timestamps, size and number of buffers.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8414>
For VPS, PPS, APS, OPI and DCI, the extension flags are the last syntax
in the structures, and according to the spec, should be ignored if set to 1.
Therefore, we can just ignore them rather than failing.
This fixes a few failures in fluster, like in the PSEXT_A_Nokia_2 stream.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8359>
If we find VPS/SPS/PPS in codec_data and call gst_h266_parse_process_nal
with them, we need to have negotiated before in order to correctly
process them with flags like h266parse->transform set or not depending
on the negotiation. This is important because in certain vvc1/vvi1 streams we
may have correct codec_data but faulty parameter sets in the stream and
we would want to push the parameter sets from codec_data first.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8359>
implement serialization of codec_data containing VvcDecoderConfigurationRecord
as defined in ISO/IEC 14996-15.
The VPS/SPS/PPS NALs are added to the codec_data. APS NALs could be
optionally included as well but will be pushed in-band instead, because:
1. Logic is easier that way. We'd have to filter out for PREFIX_APS only
(SUFFIX_APS aren't allowed in codec_data).
2. APS NALs can also be sent for every non-keyframe slice, and often are, so just pushing
them in-band makes more sense to have less to keep track and avoid possible
duplicates.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8359>
If collecting the backchannel stream after the stream has begun
preparing, make sure to join it to the RTSP media bin, as is
done for dynamic payloaders in the pad-added handler. Add a
new internal stream creation method for it, that could be
publically exposed later if it proves useful.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8378>
When prerolling / blocking an RTSP media, don't consider receiver
streams like onvif backchannel in the 'is everything blocked' check,
as those streams won't receive data until after the RTSP stream
is running.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8378>
When decoupling send/receive loops in rtsp-media using appsink/appsrc,
put the appsink in the bin before linking it, as this code path
had that wrong.
For both sender and receiver paths, if the pipeline already started
also add the other appsrc/appsink of the pair to the pipeline
immediately instead of putting it in the pending elements list,
as they won't get added later.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8378>
The example was switched to use autovideosink, which broke
current position calculation based on the last video frame.
Add code to retrieve the actual video sink from within autovideosink
to make it work again.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8378>
Suppose you're trying to debug why this pipeline doesn't work:
```
$ GST_DEBUG=GST_PIPELINE:DEBUG gst-launch-1.0 \
videotestsrc num-buffers=10 ! x264enc name=enc ! mux.sink_0 \
mpegtsmux name=mux ! fakesink
```
You will encounter this line in the logs:
> gst_parse_perform_link: linking some pad of GstX264Enc named enc to
> pad mux of GstMpegTsMux named mux (0/1) with caps "(NULL)"
It would seem that the element name is being read as a pad name as well,
and that made me wonder if the parsing was not working. However, it was
just a bug in the code printing that log. This patch fixes that bug.
Note that it is possible to specify more than one pad name for each side
of the link. For instance, the following is a valid pipeline that will
remux the video and audio of an MP4 file into MKV:
```
$ GST_DEBUG=GST_PIPELINE:DEBUG gst-launch \
filesrc location=input.mp4 ! qtdemux name=demux \
multiqueue name=mq \
matroskamux name=mux ! filesink location=output.mkv \
demux.video_0,audio_0 ! mq.sink_0,sink_1 \
mq.src_0,src_1 ! mux.video_0,audio_0
```
The new logging accomodates this by using a new utility function to join
strings of pad name lists instead of `PRETTY_PAD_NAME_FMT` (which only
supports one pad name). For example:
> linking pads {video_0, audio_0} of GstQTDemux named demux to pads
> {sink_0, sink_1} of GstMultiQueue named mq with caps "(NULL)"
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8415>
