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>
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>
The name is already passed via the signal parameters so it doesn't have
to be retrieved again via GstObject API, which would crash on other
GObjects. Child proxy child objects can be any kind of GObject and the
code here otherwise handles this correctly already.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6938>
When using such a launch line:
fakesrc ! "audio/x-opus, channel-mapping=(int)<0, 1>" ! fakesink
the caps string, with spaces escaped but no quotes gets passed to
gst_caps_from_string(), which then fails to parse the array because it
contains spaces.
When using an explicit capsfilter instead:
fakesrc ! capsfilter caps="audio/x-opus, channel-mapping=(int)<0, 1>" ! fakesink
the caps string, with spaces escaped and quotes gets passed through
gst_value_deserialize, which first calls gst_str_unwrap() on it and only
then gst_caps_from_string() on the result.
This fixes the inconsistency by using a custom version of str_unwrap()
in the parser, which doesn't expect a quoted string.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4181>
When using the child proxy notation (child::property=value) it may
happen that the target child does not exist at the time of parsing
(i.e: decodebin creates the encoder according to the contents of the
stream). On this cases, we want to delay the setting of the property
to later, when new elements are added. Previous logic performed a
delayed set even if the target child was found but the property
was not found in it. This should be treated as a failure because,
unlike missing elements, properties should not appear dynamically.
By not failing, typos in property names may go unnoticed to the end
user.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2908>
GLib guarantees libintl is always present, using proxy-libintl as
last resort. There is no need to mock gettex API any more.
This fix static build on Windows because G_INTL_STATIC_COMPILATION must
be defined before including libintl.h, and glib does it for us as part
as including glib.h.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2028>
