SRT stream not sending

[Mart Raudsepp]

Ühel kenal päeval, T, 21.04.2020 kell 12:17, kirjutas Samuel Hurst:
> Hello!
> 
> I'm experimenting with using the SRT [1] protocol and I noticed that
> GStreamer has a collection of SRT elements, so I've been trying to
> get
> them to work. However, I can't actually get any streaming to actually
> start.
> 
> With my distro not offering any SRT packages, I've compiled up a full
> GStreamer instance from git sources (so up to date on 1.17 as of
> yesterday morning) with libsrt at version 1.4.1.
> 
> As a first step, I've been following a guide from Collabora [2] to
> experiment with it, and I'm using the following pipelines as server
> and
> client respectively (on the same physical machine):
> 
> > gst-launch-1.0 videotestsrc ! video/x-raw,height=800,width=600 !
> > videoconvert ! x264enc tune=zerolatency ! video/x-h264,profile=high 
> > ! srtsink uri=srt://:8888/
> > gst-launch-1.0 srtsrc uri=srt://127.0.0.1:8888/ ! decodebin !
> > autovideosink
> 
> The pipeline on both sides of the equation enter the PLAYING state,
> and
> I can see the two peers connect and perform the handshake, but the
> playback counter on the server never begins counting and I never get
> a
> video window opening on the client side.
> 
> With GST_DEBUG="srt:9", I can see that the server seems to be stuck
> waiting for a caller request after the client has "connected":
> 
> > 0:00:02.768093620 16974 0x555ed162d8f0 DEBUG  srtobject
> > gstsrtobject.c:679:thread_func:<srtsink0> Waiting a request from
> > caller
> 
> Reading through the code, I can't figure out how the caller is
> supposed
> to submit a request, that will presumably kick off the sending of the
> stream. The client is just sat there waiting for frames it seems.
> 
> Does anyone have any experience with these elements and might be able
> to
> shed some light on what these problems are?

If you change srt://:8888 to srt://127.0.0.1:8888, then you make it be
a caller iirc, so careful with that.
SRT has a caller and a listener - listener waits for callers. You could
think of a listener as the server and caller as a client in most
scenarios. So one side needs to be a listener, and the other a caller.
You should be able to enforce it in the URL, e.g
srt://127.0.0.1:8888?mode=listener
or the mode property on the srt elements.
There's also a rendezvous mode (both set sides that then) for some
firewall punching use cases and such. Often one side is an actual
server and doesn't have firewall trouble and thus is the listener.

In my experience UDP on the same machine can be rather troublesome with
an out of the box kernel configuration, so I suggest also trying it
with the sending and receiving pipelines on different computers.
I've also had a bit better luck by using the router assigned local NAT
IP instead of loopback address for quick tests with both sides on the
same machine.


Mart