gstreamer issueshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues2022-11-10T09:20:48Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/229gst-stats: do stats on latency2022-11-10T09:20:48ZBugzilla Migration Usergst-stats: do stats on latency## Submitted by Guillaume Desmottes `@gdesmott`
**[Link to original bug (#781276)](https://bugzilla.gnome.org/show_bug.cgi?id=781276)**
## Description
I needed to do some stats on the latency information reported by the 'latency' tr...## Submitted by Guillaume Desmottes `@gdesmott`
**[Link to original bug (#781276)](https://bugzilla.gnome.org/show_bug.cgi?id=781276)**
## Description
I needed to do some stats on the latency information reported by the 'latency' tracer. gst-stats seem to be the best place to do that.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/228Unexpected ERROR if changing states while pushing a sticky event.2021-09-24T11:09:49ZBugzilla Migration UserUnexpected ERROR if changing states while pushing a sticky event.## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#781000)](https://bugzilla.gnome.org/show_bug.cgi?id=781000)**
## Description
Currently, if the downstream element is stopped or goes flushing while a sticky event is ...## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#781000)](https://bugzilla.gnome.org/show_bug.cgi?id=781000)**
## Description
Currently, if the downstream element is stopped or goes flushing while a sticky event is pushed downstream as caused by a buffer push, it will cause a castrophic failure as the gst_pad_push() will return GST_FLOW_ERROR.
I think it should return GST_FLOW_FLUSHING instead, so that it can be safely ignored if a flush caused it.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/227GstPushSrc.do_create and Gst.BaseSrc.do_query are not introspected properly i...2021-09-24T11:09:50ZBugzilla Migration UserGstPushSrc.do_create and Gst.BaseSrc.do_query are not introspected properly in bindings (Python)## Submitted by César Fabián Orccón Chipana
**[Link to original bug (#780945)](https://bugzilla.gnome.org/show_bug.cgi?id=780945)**
## Description
Created attachment 349314
Add annotations to vfuncs in base sources
For exampl...## Submitted by César Fabián Orccón Chipana
**[Link to original bug (#780945)](https://bugzilla.gnome.org/show_bug.cgi?id=780945)**
## Description
Created attachment 349314
Add annotations to vfuncs in base sources
For example,
When you use "do_create" vfunc in Python for a GstBaseSrc, you need to define the following method:
def do_create(self, buff):
# Implementation here
But what you actually should do is
def do_create(self):
# Implementation here
return buff
I am uploading a patch that fixes that.
PD: I also think that all vfuncs should be annotated.
**Patch 349314**, "Add annotations to vfuncs in base sources":
[0001-Add-annotations-to-vfuncs-in-base-sources.patch](/uploads/d32629f28c89585cda6e79c12ea5d6e0/0001-Add-annotations-to-vfuncs-in-base-sources.patch)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/226GstUri: add function to parse uri and set properties to object2022-11-10T09:20:48ZBugzilla Migration UserGstUri: add function to parse uri and set properties to object## Submitted by Marc Leeman `@den_erpel`
**[Link to original bug (#779765)](https://bugzilla.gnome.org/show_bug.cgi?id=779765)**
## Description
Created attachment 347499
pick up properties and set to object
As some core devel...## Submitted by Marc Leeman `@den_erpel`
**[Link to original bug (#779765)](https://bugzilla.gnome.org/show_bug.cgi?id=779765)**
## Description
Created attachment 347499
pick up properties and set to object
As some core developers sometimes claim, we (Barco) do 'crazy' stuff with URIs.
This patch adds the functionality to pick up the key value pairs from a URI and set them to an object.
This allows to encode element properties into an URI and have an easy way to set it onto self.
e.g.
rtsp://.......?debug=true&protocols=2
This combines with a number of patches we've submitted in the past; I will refresh them in the following days based on this submission.
~~**Patch 347499**~~, "pick up properties and set to object":
[0001-gsturi-add-uri-parser-to-set-props-to-obj.patch](/uploads/9df140a811b23f9ba67f9b789279627c/0001-gsturi-add-uri-parser-to-set-props-to-obj.patch)
Version: 1.10.4
### Blocking
* [Bug 738608](https://bugzilla.gnome.org/show_bug.cgi?id=738608)
* [Bug 746818](https://bugzilla.gnome.org/show_bug.cgi?id=746818)
* [Bug 748042](https://bugzilla.gnome.org/show_bug.cgi?id=748042)
* [Bug 779850](https://bugzilla.gnome.org/show_bug.cgi?id=779850)
* [Bug 779855](https://bugzilla.gnome.org/show_bug.cgi?id=779855)
* [Bug 780033](https://bugzilla.gnome.org/show_bug.cgi?id=780033)
* [Bug 746762](https://bugzilla.gnome.org/show_bug.cgi?id=746762)
* [Bug 781441](https://bugzilla.gnome.org/show_bug.cgi?id=781441)
* [Bug 781442](https://bugzilla.gnome.org/show_bug.cgi?id=781442)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/225timecode: Serialization/deserialization is lossy2022-11-10T09:20:48ZBugzilla Migration Usertimecode: Serialization/deserialization is lossy## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#779756)](https://bugzilla.gnome.org/show_bug.cgi?id=779756)**
## Description
When serializing a timecode, only the "visible" part of a timecode is serialized. The ti...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#779756)](https://bugzilla.gnome.org/show_bug.cgi?id=779756)**
## Description
When serializing a timecode, only the "visible" part of a timecode is serialized. The timecode configuration (framerate, drop-frame'ness, etc) is lost.
This is not a well-formed serialization then.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/224GST_DEBUG_BIN_TO_DOT: creates invalid .dot file when GstStructure parameter c...2021-09-24T11:09:51ZBugzilla Migration UserGST_DEBUG_BIN_TO_DOT: creates invalid .dot file when GstStructure parameter contains string with "@"## Submitted by Brendan Shanks `@bshankstd`
**[Link to original bug (#779668)](https://bugzilla.gnome.org/show_bug.cgi?id=779668)**
## Description
When GST_DEBUG_BIN_TO_DOT_FILE dumps a bin containing an element with a GstStructure ...## Submitted by Brendan Shanks `@bshankstd`
**[Link to original bug (#779668)](https://bugzilla.gnome.org/show_bug.cgi?id=779668)**
## Description
When GST_DEBUG_BIN_TO_DOT_FILE dumps a bin containing an element with a GstStructure parameter, if the GstStructure contains a string value with "@" in it, the resulting .dot file is invalid. xdot gives the error "unexpected char '\'"
I came across this bug when dumping the media-pipeline of a GStreamer RTSP server. The GstRtpSession sdes parameter is a GstStructure with a string parameter ("cname") that has an "@" symbol in it.
I haven't investigated why this happens, but it looks like GstStructure
does extra quoting on the output string when it contains "@", and then g_strescape() adds too many backslashes when escaping.
Here's the invalid label line from the .dot file when the string doesn't contain "@": label="GstCapsFilter\nhi@\n[0]\nparent=(GstPipeline) pipeline\ncaps=application/x-rtp-source-sdes, cname=(string)user2341dqw";
And with "@":
label="GstCapsFilter\ncapsfilter0\n[0]\nparent=(GstPipeline) pipeline\ncaps=application/x-rtp-source-sdes, cname=(string)\\\"user2341\\\\@dqw\\\"";
According to the DOT language guide (http://www.graphviz.org/content/dot-language): "In quoted strings in DOT, the only escaped character is double-quote ("). That is, in quoted strings, the dyad \" is converted to "; all other characters are left unchanged. In particular, \\ remains \\"https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/223Leaky queue might set latency max < min2022-11-10T09:20:48ZBugzilla Migration UserLeaky queue might set latency max < min## Submitted by Jan Alexander Steffens `@heftig`
**[Link to original bug (#779461)](https://bugzilla.gnome.org/show_bug.cgi?id=779461)**
## Description
The latency calculation for leaky queues doesn't take the minimum latency in acc...## Submitted by Jan Alexander Steffens `@heftig`
**[Link to original bug (#779461)](https://bugzilla.gnome.org/show_bug.cgi?id=779461)**
## Description
The latency calculation for leaky queues doesn't take the minimum latency in account, and as a result can set the maximum latency to lower than the minimum.
GStreamer 1.10.4
Version: 1.10.4https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/222multiqueue: limit queueing to absolute minimum when dealing with single stream2022-11-10T09:20:48ZBugzilla Migration Usermultiqueue: limit queueing to absolute minimum when dealing with single stream## Submitted by Carlos Rafael Giani
**[Link to original bug (#779069)](https://bugzilla.gnome.org/show_bug.cgi?id=779069)**
## Description
Run this test pipeline:
`GST_DEBUG=2,*decodebin3*:9 gst-launch-1.0 concat name=x ! decod...## Submitted by Carlos Rafael Giani
**[Link to original bug (#779069)](https://bugzilla.gnome.org/show_bug.cgi?id=779069)**
## Description
Run this test pipeline:
`GST_DEBUG=2,*decodebin3*:9 gst-launch-1.0 concat name=x ! decodebin3 ! fakesink sync=true silent=false urisourcebin uri=file://$(pwd)/test-1000ms-48000hz.wav ! identity ! x. urisourcebin uri=file://$(pwd)/test-1000ms-48000hz.wav ! identity ! x. -v `
From the logs and the verbose fakesink output you can then see that from the time decodebin3 to the time fakesink see the stream-start event, about 300ms pass.
(You can use audiotestsrc to generate test-1000ms-48000hz.wav like this: `audiotestsrc num-buffers=1 samplesperbuffer=48000 ! "audio/x-raw, rate=48000, format=S16LE, channels=1" ! wavenc ! filesink location=test-1000ms-48000hz.wav`)
multiqueue's max-size-time size is set to a pretty high value (250ms) for a single stream. One improvement that was suggested by thaytan was this:
``` diff
--- a/plugins/elements/gstmultiqueue.c
+++ b/plugins/elements/gstmultiqueue.c
@@ -1279,7 +1279,8 @@ calculate_interleave (GstMultiQueue * mq)
interleave = high - low;
/* Padding of interleave and minimum value */
/* FIXME : Make the minimum time interleave a property */
- interleave = (150 * interleave / 100) + 250 * GST_MSECOND;
+ if (mq->nbqueues > 1)
+ interleave = (150 * interleave / 100) + 250 * GST_MSECOND;
/* Update the stored interleave if:
* * No data has arrived yet (high == low)
```
However, as he said: "I don't want to break a case where we don't have any interleave and it causes a deadlock waiting to request a 2nd pad that would then have allowed interleave."
So I opened this bugreport for discussing this.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/221caps: simplify creates invalid caps with sets or ranges, intersect fails even...2022-11-10T09:20:48ZBugzilla Migration Usercaps: simplify creates invalid caps with sets or ranges, intersect fails even more on them## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#779058)](https://bugzilla.gnome.org/show_bug.cgi?id=779058)**
## Description
intersect() of sets of ranges is broken:
"video/x-h264, framerate=(fraction){ [ 5/1...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#779058)](https://bugzilla.gnome.org/show_bug.cgi?id=779058)**
## Description
intersect() of sets of ranges is broken:
"video/x-h264, framerate=(fraction){ [ 5/1, 240/1 ], [ 3/1, 5/1 ] }"
intersected with itself gives
"video/x-h264, framerate=(fraction){ [ 5/1, 240/1 ], 5/1, { 5/1, [ 3/1, 5/1 ] } }"
There should not be ranges inside sets to begin with, but the intersection result is even worse than that. It's of a different type than the input, and the set contains elements of different types.
And these sets of ranges are caused by simplify():
"video/x-raw, framerate=(fraction) [3/1, 30/1]; video/x-raw, framerate=(fraction) [3/1, 120/1]"
gives simplified
"video/x-raw, framerate=(fraction){ [ 30/1, 60/1 ], [ 3/1, 30/1 ], [ 60/1, 120/1 ] }"https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/220Pipelines don't pre-roll on empty segments after a segment seek.2021-09-24T11:09:53ZBugzilla Migration UserPipelines don't pre-roll on empty segments after a segment seek.## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#778471)](https://bugzilla.gnome.org/show_bug.cgi?id=778471)**
## Description
GstBaseSink doesn't complete the preroll on an empty segment after a segment seek. So the...## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#778471)](https://bugzilla.gnome.org/show_bug.cgi?id=778471)**
## Description
GstBaseSink doesn't complete the preroll on an empty segment after a segment seek. So the test case is to do a segment seek, which results in a segment event, immediately followed by a SEGMENT_DONE.. If you have more than one sink in the pipeline, then the other sinks wait in wait_preroll forever. The proposed solution is to just treat the SEGMENT_DONE event like EOS and complete the state change when it is received.
I'm not sure if I understand segment seeks correctly, or if they should just be ignored for prerolling purposes and that an actual buffer or EOS is needed?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/219race in gstpoll detected by TSan2022-11-10T09:20:48ZBugzilla Migration Userrace in gstpoll detected by TSan## Submitted by Fabrice Bellet `@bellet`
**[Link to original bug (#778079)](https://bugzilla.gnome.org/show_bug.cgi?id=778079)**
## Description
Created attachment 344776
ThreadSanitizer: data race gstreamer/gst/gstpoll.c:1371 in g...## Submitted by Fabrice Bellet `@bellet`
**[Link to original bug (#778079)](https://bugzilla.gnome.org/show_bug.cgi?id=778079)**
## Description
Created attachment 344776
ThreadSanitizer: data race gstreamer/gst/gstpoll.c:1371 in gst_poll_wait
This case detected by the ThreadSanitizer where the set->active_fds GArray is expanded/reallocated while another thread is calling ppoll() on it.
**Attachment 344776**, "ThreadSanitizer: data race gstreamer/gst/gstpoll.c:1371 in gst_poll_wait":
[gstpoll.txt](/uploads/b83ca44d20be07c2c4ad92a644dbeb7f/gstpoll.txt)
Version: 1.10.xhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/218race in gstpad detected by TSan2022-11-10T09:20:48ZBugzilla Migration Userrace in gstpad detected by TSan## Submitted by Fabrice Bellet `@bellet`
**[Link to original bug (#778038)](https://bugzilla.gnome.org/show_bug.cgi?id=778038)**
## Description
Created attachment 344717
ThreadSanitizer: data race gstreamer/gst/gstpad.c:5038 in st...## Submitted by Fabrice Bellet `@bellet`
**[Link to original bug (#778038)](https://bugzilla.gnome.org/show_bug.cgi?id=778038)**
## Description
Created attachment 344717
ThreadSanitizer: data race gstreamer/gst/gstpad.c:5038 in store_sticky_event
This case suggested by ThreadSanitizer happens in gst_pad_query_caps_default() when pad flags are read by GST_PAD_IS_PROXY_CAPS (pad), without lock.
**Attachment 344717**, "ThreadSanitizer: data race gstreamer/gst/gstpad.c:5038 in store_sticky_event":
[gstpad.txt](/uploads/961153854175d4b7ec224b84ca1a89fb/gstpad.txt)
Version: 1.10.xhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/217race in gst_base_src_loop() detected by TSan2022-11-10T09:20:47ZBugzilla Migration Userrace in gst_base_src_loop() detected by TSan## Submitted by Fabrice Bellet `@bellet`
**[Link to original bug (#778035)](https://bugzilla.gnome.org/show_bug.cgi?id=778035)**
## Description
Created attachment 344715
ThreadSanitizer: data race gstreamer/gst/gstpad.c:5543 in gs...## Submitted by Fabrice Bellet `@bellet`
**[Link to original bug (#778035)](https://bugzilla.gnome.org/show_bug.cgi?id=778035)**
## Description
Created attachment 344715
ThreadSanitizer: data race gstreamer/gst/gstpad.c:5543 in gst_pad_send_event_unchecked
This case suggested by the ThreadSanitizer occurs when updating the flags of the GstPad object while holding the object lock in gstpad.c, and when reading the flags in gst_base_src_loop(), unlocked:
if (G_UNLIKELY (src->priv->flushing || GST_PAD_IS_FLUSHING (pad)))
**Attachment 344715**, "ThreadSanitizer: data race gstreamer/gst/gstpad.c:5543 in gst_pad_send_event_unchecked":
[gstbasesrc.txt](/uploads/7ebb7bc755ed71ef0500d67b62a3c63c/gstbasesrc.txt)
Version: 1.10.xhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/216race in gstclock detected by TSan2021-09-24T11:09:55ZBugzilla Migration Userrace in gstclock detected by TSan## Submitted by Fabrice Bellet `@bellet`
**[Link to original bug (#778032)](https://bugzilla.gnome.org/show_bug.cgi?id=778032)**
## Description
Created attachment 344711
ThreadSanitizer: data race gstreamer/gst/gstclock.c:927 in g...## Submitted by Fabrice Bellet `@bellet`
**[Link to original bug (#778032)](https://bugzilla.gnome.org/show_bug.cgi?id=778032)**
## Description
Created attachment 344711
ThreadSanitizer: data race gstreamer/gst/gstclock.c:927 in gst_clock_adjust_unlocked
ThreadSanitizer reports a race in gst_clock_adjust_unlocked(), because priv->last_time is written while being in a reader seqlock sequence in gst_clock_get_time()
**Attachment 344711**, "ThreadSanitizer: data race gstreamer/gst/gstclock.c:927 in gst_clock_adjust_unlocked":
[gstclock.txt](/uploads/f984f4559533781488ffa09219e2097a/gstclock.txt)
Version: 1.10.xhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/215streamcollection: Supposed to be immutable but nothing enforcing that2022-11-10T09:20:47ZBugzilla Migration Userstreamcollection: Supposed to be immutable but nothing enforcing that## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#777643)](https://bugzilla.gnome.org/show_bug.cgi?id=777643)**
## Description
Quoting the docs, "Once posted, a GstStreamCollection is immutable.".
There is noth...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#777643)](https://bugzilla.gnome.org/show_bug.cgi?id=777643)**
## Description
Quoting the docs, "Once posted, a GstStreamCollection is immutable.".
There is nothing enforcing this, and at any time new streams can be added to the collection. The addition of streams is not even thread-safe.
I'd suggest using a GstObject flag, or some new boolean, in the stream collection to mark it is "sealed" (which could be done from application code, but will also be done when the collection is stored in a message). And then make sure that adding new streams fails from that point onwards.
Any opinions on which one is nicer?
### See also
* [Bug 777572](https://bugzilla.gnome.org/show_bug.cgi?id=777572)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/214GstStream: Thread-safety concerns and modification/refinement of stream details2022-11-10T09:20:47ZBugzilla Migration UserGstStream: Thread-safety concerns and modification/refinement of stream details## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#777572)](https://bugzilla.gnome.org/show_bug.cgi?id=777572)**
## Description
There seem to be two issues with the GstStream API as is currently.
1) Thread-safet...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#777572)](https://bugzilla.gnome.org/show_bug.cgi?id=777572)**
## Description
There seem to be two issues with the GstStream API as is currently.
1) Thread-safety
Currently the tags/caps/etc are locked with a mutex, which is good and solves the problem of one writer and multiple readers. However there could also be multiple writers according to the documentation (downstream could refine the information). In this case there is a race condition between getting the e.g. caps, modifying them and setting new caps. E.g. downstream could be a parser that is separated from the demuxer with some queue and refines the details from the demuxer.
2) How to decide when to refine specific details
These are actually a group of similar problems.
Consider the case of a demuxer knowing the resolution of a stream but not much more, and downstream a parser that adds more information (e.g. profile). Now at a later time, the resolution of the stream changes. How does the demuxer know whether it can update the resolution (maybe downstream was setting a more accurate resolution?), whether it has to remove other fields (they might not be valid anymore), and especially how would it know which fields were set by itself and which not (other than always remembering everything everywhere).
Another case, similar, would be a demuxer that first provides generic information without resolution. Then a parser adds the resolution. Then the demuxer also knows the resolution from somewhere. How would it decide whether to update it in the caps or not?
### See also
* [Bug 777643](https://bugzilla.gnome.org/show_bug.cgi?id=777643)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/213Playlist Support2022-11-10T09:20:47ZBugzilla Migration UserPlaylist Support## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#776613)](https://bugzilla.gnome.org/show_bug.cgi?id=776613)**
## Description
This is useful to support remote playlists and other formats than a simple
URI/filenam...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#776613)](https://bugzilla.gnome.org/show_bug.cgi?id=776613)**
## Description
This is useful to support remote playlists and other formats than a simple
URI/filename list. totem-plparser is rather small and doesn't do much more
than the name suggests.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/212Handling GST_RESOURCE_ERROR_NOT_FOUND for a stream2021-09-24T11:09:56ZBugzilla Migration UserHandling GST_RESOURCE_ERROR_NOT_FOUND for a stream## Submitted by Arnaud Rebillout
**[Link to original bug (#776495)](https://bugzilla.gnome.org/show_bug.cgi?id=776495)**
## Description
Dear Gst,
In the current version of GStreamer, when playing an audio stream, different erro...## Submitted by Arnaud Rebillout
**[Link to original bug (#776495)](https://bugzilla.gnome.org/show_bug.cgi?id=776495)**
## Description
Dear Gst,
In the current version of GStreamer, when playing an audio stream, different error cases lead to the same error:
GST_RESOURCE_ERROR: GST_RESOURCE_ERROR_NOT_FOUND
Could not resolve server name.
I identified clearly 2 error cases that lead to this error. I need to distinguish between these two error cases, and at the moment GStreamer doesn't provide a reliable way to do this.
----
There are clearly two different error cases that lead to this error message.
1. The network is done. Error reported by gst is as such:
Gst error msg: gst-resource-error-quark:3: Could not resolve server name.
Gst error debug: gstsouphttpsrc.c(1315): gst_soup_http_src_parse_status
(): /GstPlayBin:playbin/GstURIDecodeBin:uridecodebin0/GstSoupHTTPSrc:source:
Error resolving 'direct.fipradio.fr': Temporary failure in name
resolution (2), URL: http://direct.fipradio.fr/live/fip-midfi.mp3,
Redirect to: (NULL)
2. The server name in the uri is wrong. Error:
Gst error msg: gst-resource-error-quark:3: Could not resolve server name.
Gst error debug: gstsouphttpsrc.c(1315): gst_soup_http_src_parse_status
(): /GstPlayBin:playbin/GstURIDecodeBin:uridecodebin0/GstSoupHTTPSrc:source:
Error resolving 'direct.fipxxxxx.fr': Name or service not known (2),
URL: http://direct.fipxxxxx.fr/live/fip-midfi.mp3, Redirect to: (NULL)
In the 1st case, I want to keep on retrying, until the network is brought back up. In the 2nd case, I want to stop and report the error to the user. So I need to distinguish between these two error cases.
At the moment, the only way to do that would be to parse the debug string, since it contains the libsoup error string, and this gives me the information I want, as you can see in the debug messages above.
But parsing the debug string is not reliable, the content might change at any time.
This has been reported on the mailing list, and to quote Sebastian Dröge:
> There are ways to add additional information to error messages now, which you could use here. Maybe some kind of "try-again" flag.
----
Best regards,
Arnaud
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/211NULL GstStructures cannot be deserialized2022-11-10T09:20:47ZBugzilla Migration UserNULL GstStructures cannot be deserialized## Submitted by Stefan Kost `@ensonic`
**[Link to original bug (#776336)](https://bugzilla.gnome.org/show_bug.cgi?id=776336)**
## Description
When serializing a nested structure where a substructure is NULL, it will be serializes as...## Submitted by Stefan Kost `@ensonic`
**[Link to original bug (#776336)](https://bugzilla.gnome.org/show_bug.cgi?id=776336)**
## Description
When serializing a nested structure where a substructure is NULL, it will be serializes as:
sub=(structure)"\(NULL\)"
This cannot be serialized. Do we want to add support for (NULL) in the structure parser?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/210tracerrecord: Enable tracer logging when a tracer record is created2022-11-10T09:20:47ZBugzilla Migration Usertracerrecord: Enable tracer logging when a tracer record is created## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#776320)](https://bugzilla.gnome.org/show_bug.cgi?id=776320)**
## Description
See commit message## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#776320)](https://bugzilla.gnome.org/show_bug.cgi?id=776320)**
## Description
See commit message