Pipeline stalling for no apparent reason?

[Florian Echtler]

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
>> gstreamer-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
> 
> 
> 
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> 


-- 
SENT FROM MY DEC VT50 TERMINAL

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20210527/ba994ce3/attachment.sig>