[Gstreamer srtsrc] Open SRT connection and drop buffers until my program decides to start reading

[ivan94fi]

Hi everyone,

I have an SRT source, and my program (server) is supposed to receive the stream with Gstreamer, decode it, process it and send the resulting video stream to other clients when they request it.

This is a brief description of the order of operations:

1. my server is started first (it is the listener in the SRT connection)
2. at some point it receives the SRT stream from the source (it is the caller in the SRT connection)
3. at some other non predictable times, one or more client connect to the server

What I have now

As of now I implemented this workflow, and it works to some degree. What is missing is that once I establish the SRT connection in point 2, the server immediately starts to receive buffers and, if no client connects to the server, I briefly start to get error messages like the following:

srtlib core.cpp:9676:processData: : @1037521072:No room to store incoming packet seqno 1585376592, insert offset 929. Space avail 0/8192 pkts. Packets ACKed: 8191 (TSBPD ready in -7207 : -1541 ms), not ACKed: 0, timespan 5666 ms. GETTIME_MONOTONIC drift 0 ms.

which later sometimes bring to

0:00:31.818478662 1328523 0x70df94006290 WARN                  srtlib core.cpp:9657:processData: : @372209367:SEQUENCE DISCREPANCY. BREAKING CONNECTION. seq=1279580743 buffer=(1279565961:1279565960+1279574152), 6592 past max. Reception no longer possible. REQUESTING TO CLOSE.

and a subsequent crash of my server.

The problem here is that the server starts to receive buffers from the SRT source as soon as the connection is done, and whene the queues in my pipeline fill up, packets start to be dropped and the errors appear.

If I start the server, the SRT source and the clients in rapid succession, none of these errors appear, the queues mitigate this problem.

What I would like to have

I would hope to "block" SRT reception until I decide that I am ready to consume buffers. Now, I think that it is not strictly possible with SRT and I am fine with that, but I am asking this here to also understand if my reasoning is sound and if someone has already solved this use case.

A solution that I tried is blocking the srtsrc element in gstreamer when no client is present, but the errors stil appear as the internal buffers are filled with packets and then dropped.

[ethouris]

Frankly, I can't speak for GStreamer, as we were not part of the development for these elements in GStreamer.

I've been already through many problems like that and I've seen that most of the streaming applications expect from the medium something like from UDP: the stream may already run, but if the application doesn't read anything, data simply fall on the floor. Unfortunately SRT doesn't work this way and if this way of working is expected in particular app scenario, an appropriate adapting code must be provided to "simulate" that behavior.

I'm not sure how srtsrc and others have been actually written in GStreamer, but at least I can tell you that that if it doesn't take this little problem into account, it must be fixed. When you have an SRT connection already engaged, the application must start reading from it (no matter if reading is expected or not) and if the element is not expected to provide any data at the moment, the data read from the connection should be simply dropped.

[ivan94fi]

Thank you for your answer. I "solved" my problem just as you describe, that is, by dropping data until someone is actually ready to read. Thanks again, you made clear what I just supposed.