SRT stream target without knowing the SRT receiver address ?

[Daniel_Rossi]

I have tested an SRT stream target distribution with gstreamer. Using something like this

gst-launch-1.0 srtclientsrc uri=srt://ip:8081 ! decodebin ! autovideosink

Is there a way for Wowza to allow for clients to pull the SRT stream without having to specify the target ip and working around NAT. There may be many clients trying pull this SRT distribution for rebroadcasting over HDMI.

So instead of setting them up for RTMP pull, using SRT instead ?

[Rose_Power-Wowza_Com]

Thanks for using our forums @Daniel Rossi. Right now there is no way to do that unfortunately. You have to set up the stream target to push to a destination and identify that target.The only way to do this for the following workflow is to push and we don’t support a workflow right now where clients can pull that SRT stream for redistribution.

This is what we currently support for SRT:

source --> WSE --(via SRT)-->client 

WSE needs to set up a stream target:
source --> WSE (stream target to client)--(via SRT)--> client

[Daniel_Rossi]

I just ran a remote test with a client. I think I had to muck around with NAT on my EdgeRouter and gstreamer still couldn’t pick it up.

Is there a chance of a rendevous mode to work around NAT ? Gstreamer supports this.

So for each receiver, it needs a seperate stream target and have NAT configured and the network admin required for that ? This is a complicated setup for easy end user distribution.

Think of the receiver like a wowza to wowza distribution for IPTV playback on special receivers.

So what IP does gstreamer have to target ,the local port or the server ?

Something like this ?

gst-launch-1.0 -v srtclientsrc uri=“srt://192.168.1.10:7001?mode=rendez-vous” ! fakesink

[Daniel_Rossi]

After alot of mucking around getting gstreamer installed as there is zero working packages for Ubuntu/Debian with SRT configured.

A test push I can see NAT issues. So is there now documentation to setup NAT for this push setup ? I have setup the receiver as the server.

I did a test with the encoder acting as the server, with the receiver acting as a client and this is working as intended. So if this is the requirement. The receiver needs to pull from the encoder instead of wowza. Or Wowza needs rendevous support.

gst-launch-1.0 videotestsrc ! video/x-raw, height=360, width=640 ! videoconvert ! x264enc tune=zerolatency ! video/x-h264, profile=high ! mpegtsmux ! srtclientsink uri=“srt://receiverip:8081/”

[Daniel_Rossi]

I believe I have to setup the receiver as a server like this. I got it working locally on the wowza server but I think I have NAT issues to figure out

gst-launch-1.0 -v srtserversrc uri=“srt://127.0.0.1:8888” ! decodebin ! autovideosink

[Rose_Power-Wowza_Com]

Cool, glad you got it working on the Wowza server.

[Daniel_Rossi]

I was able to get a local receiver server working with gstreamer 1.17 and a local Wowza like so. It can’t bind to any ip to connect to the c class lan ip

gst-launch-1.0 -v srtsrc uri=“srt://:8888?mode=listener” ! decodebin ! videoconvert ! autovideosink

A test gstreamer push encode is like so

gst-launch-1.0 videotestsrc ! video/x-raw, height=360, width=640 ! videoconvert ! x264enc tune=zerolatency ! video/x-h264, profile=high ! mpegtsmux ! srtsink uri=“srt://192.168.4.55:8888?mode=caller”

I was still unable to get Wowza connecting or using a gsteamer push through the NAT. I also had a Windows firewall getting in the way but even opening this port was a problem still.

I think the rendevous mode is required still see

gst-launch-1.0 -v srtclientsrc uri=“srt://192.168.1.10:7001?mode=rendez-vous” ! fakesink

https://gstreamer.freedesktop.org/documentation/srt/srtsrc.html?gi-language=c

[Rose_Power-Wowza_Com]

This isn’t something we’ve really tested @Daniel Rossi so the engineers suggest you submit a support ticket and they can look at this workflow with you.

You can submit that here:

https://www.wowza.com/support/open-ticket

[Daniel_Rossi]

OK. Well I still can’t seem to get the push working through NAT. Only works coming from the server. Distributing receivers to end users and supporting NAT issues is going to be difficult.

[Daniel_Rossi]

I got UDP forwarding working. I have a bridged pppoe interface and had to choose that on the EdgeRouter router not my bridging port.

I will ask about rendevous mode once I figure out how it works

[Daniel_Rossi]

Sorry one more thing. I don’t get what the passphrase needs to be on wowza and receive end. It wants a 16 character key but how do I generate that ? Is it clear text passphrase on the receiver ?

[Daniel_Rossi]

Now I have this partially working. I realised now, Wowza could be in SRT Receiver Server mode with SRT encoders pushing to it like so. Instead of Wowza setup as an SRT pull client.

gst-launch-1.0 videotestsrc ! video/x-raw, height=360, width=640 ! videoconvert ! x264enc tune=zerolatency ! video/x-h264, profile=high ! mpegtsmux ! srtsink uri=“srt://192.168.4.55:8888?mode=caller”

[Rose_Power-Wowza_Com]

Hi @Daniel Rossi sounds like you’re making great progress. Here is how to generate that 16 character key:

https://www.wowza.com/docs/how-to-secure-apple-http-live-streaming-aes-128-external-method#using-genkey

[Rose_Power-Wowza_Com]

If you are using AES-128 then you would use a value of 16. We have an article that covers this.

https://www.wowza.com/docs/how-to-specify-per-stream-settings-in-stream-files#srtstreams

From the article.

• srtKeyLength: Integer
  Specifies the key length used for encryption. If set to 0, no encryption is used. You can set the srtKeyLength to 16 to configure 128-bit AES encryption or 32 to configure 256-bit AES encryption.
  Default: 0