Pipeline stalling for no apparent reason?
floe at butterbrot.org
Thu May 27 20:16:25 UTC 2021
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?
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 . 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
>>  https://github.com/floe/surface-streams/blob/master/scripts/gst-mixer.py
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
SENT FROM MY DEC VT50 TERMINAL
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 203 bytes
Desc: OpenPGP digital signature
More information about the gstreamer-devel