Pipeline stalling for no apparent reason?

[GStreamer-devel mailing list]

Hello everyone,

I have a rather complex streaming pipeline that's constructed/managed from a
Python script [1]. There are 2 (or more) clients that send MPEG transport
streams over UDP to the pipeline, which then sends a "remixed" version of those
streams back.

One issue I'm having now is that the pipeline works just as intended if the
clients connect/start sending sequentially with 1-2 seconds of gap between, but
if 2 or more clients already are sending when the pipeline launches, then it
gets stuck in PAUSED state. (This started happening once I added the audio
mixing branch to the pipeline.)

Weirdly enough, I checked the debug graph output and it seems to be 1:1
identical, so exactly the same elements get created and linked in both cases
(see attachments).

I already checked the output with GST_DEBUG=4 and couldn't find any concrete
reason for why this happens. I assume it's some sort of race condition related
to how the SSRC and transport stream demuxer pads get added, but I'm at a bit of
a loss about how to debug this...

Any suggestions highly appreciated!

Best, Florian

[1] https://github.com/floe/surface-streams/blob/master/scripts/gst-mixer.py
--
SENT FROM MY DEC VT50 TERMINAL

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[GStreamer-devel mailing list]

A brief update: I've been playing around with gst-debugger, which is awesome,
and discovered that the issue is apparently related to caps negotiation: on the
newly-added branches, some of parts of the pipeline have caps set to NULL.

I've partly fixed my issue by just handling the linking of mixers etc. in a
timer function that's triggered with a short delay after all decoder pads have
been added, but I still have the same problem with 3 or more clients now.

Is there a way to wait for caps negotiation to complete before adding new parts
to the pipeline, or can I force a renegotiation somehow for the elements that
still have NULL caps?

Best, Florian

On 24/05/2021 17:49, Florian Echtler via gstreamer-devel wrote:

> Hello everyone,
>
> I have a rather complex streaming pipeline that's constructed/managed from a
> Python script [1]. There are 2 (or more) clients that send MPEG transport
> streams over UDP to the pipeline, which then sends a "remixed" version of those
> streams back.
>
> One issue I'm having now is that the pipeline works just as intended if the
> clients connect/start sending sequentially with 1-2 seconds of gap between, but
> if 2 or more clients already are sending when the pipeline launches, then it
> gets stuck in PAUSED state. (This started happening once I added the audio
> mixing branch to the pipeline.)
>
> Weirdly enough, I checked the debug graph output and it seems to be 1:1
> identical, so exactly the same elements get created and linked in both cases
> (see attachments).
>
> I already checked the output with GST_DEBUG=4 and couldn't find any concrete
> reason for why this happens. I assume it's some sort of race condition related
> to how the SSRC and transport stream demuxer pads get added, but I'm at a bit of
> a loss about how to debug this...
>
> Any suggestions highly appreciated!
>
> Best, Florian
>
> [1] https://github.com/floe/surface-streams/blob/master/scripts/gst-mixer.py
>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>

--
SENT FROM MY DEC VT50 TERMINAL


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[GStreamer-devel mailing list]

And one more update: in the end, I discovered an older post on this list which
mentions that any tee or demuxer should basically always feed directly into
queues, so I changed that and now things are working ~95% reliable. There still
is an occasional hard-to-reproduce lockup when a new client connects, but that
can be fixed by just restarting the whole pipeline while the clients continue
streaming, only leads to 1-2 second dropout.

However, this leads me to a follow-up question: I've been observing the running
pipeline with gst-debugger, and many of the queues never seem to actually buffer
any data, they are constantly at 0/0/0 for all current-level properties. I'm
trying to keep latency low here, so are there any generic tips for optimization?

Best, Florian

On 26/05/2021 16:51, Florian Echtler via gstreamer-devel wrote:

> A brief update: I've been playing around with gst-debugger, which is awesome,
> and discovered that the issue is apparently related to caps negotiation: on the
> newly-added branches, some of parts of the pipeline have caps set to NULL.
>
> I've partly fixed my issue by just handling the linking of mixers etc. in a
> timer function that's triggered with a short delay after all decoder pads have
> been added, but I still have the same problem with 3 or more clients now.
>
> Is there a way to wait for caps negotiation to complete before adding new parts
> to the pipeline, or can I force a renegotiation somehow for the elements that
> still have NULL caps?
>
> Best, Florian
>
> On 24/05/2021 17:49, Florian Echtler via gstreamer-devel wrote:
>> Hello everyone,
>>
>> I have a rather complex streaming pipeline that's constructed/managed from a
>> Python script [1]. There are 2 (or more) clients that send MPEG transport
>> streams over UDP to the pipeline, which then sends a "remixed" version of
>> those streams back.
>>
>> One issue I'm having now is that the pipeline works just as intended if the
>> clients connect/start sending sequentially with 1-2 seconds of gap between,
>> but if 2 or more clients already are sending when the pipeline launches, then
>> it gets stuck in PAUSED state. (This started happening once I added the audio
>> mixing branch to the pipeline.)
>>
>> Weirdly enough, I checked the debug graph output and it seems to be 1:1
>> identical, so exactly the same elements get created and linked in both cases
>> (see attachments).
>>
>> I already checked the output with GST_DEBUG=4 and couldn't find any concrete
>> reason for why this happens. I assume it's some sort of race condition related
>> to how the SSRC and transport stream demuxer pads get added, but I'm at a bit
>> of a loss about how to debug this...
>>
>> Any suggestions highly appreciated!
>>
>> Best, Florian
>>
>> [1] https://github.com/floe/surface-streams/blob/master/scripts/gst-mixer.py
>>
>> _______________________________________________
>> gstreamer-devel mailing list
>> [hidden email]
>> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>
>
>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>

--
SENT FROM MY DEC VT50 TERMINAL


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel