voc / srtrelay

SRT relay server for distributing media streams to multiple clients.
MIT License
134 stars 37 forks source link

Relay Push mode #27

Open VideoFX opened 1 year ago

VideoFX commented 1 year ago

This is amazing, i am trying it today for the first time. I came here looking for a relay push mode to experiment with. I am wondering if there is a way to achieve this with srtrelay. Is there a feature, similar to sls, where you can specify a relay type push method to push it to another srtrelay node?

This is fantastic btw, thank you. Testing now.

ravenium commented 1 year ago

I cobbled together something to do that - apologies as it might be a little dusty but should still work: https://github.com/ravenium/fragconsole . Basically you'd run it with -f and specify a relay. Our use case was getting users with spotty ISPs onto a local reflector, then having that reflector utilize our internal backbone for transport. Is that sort of what you're looking to do?

VideoFX commented 1 year ago

Yes exactly what I am doing! Thank you @ravenium I will check it.

iSchluff commented 1 year ago

I was thinking about implementing automatic reflection using consul as synchronization backend. Basically similar to sls clustering for rtmp. Pulling a stream from one of the relays would automatically fetch it from the origin.

ravenium commented 1 year ago

@iSchluff I like the idea, but maybe redis as a backend would keep it simpler for the average docker-compose user?

I've been looking for an excuse to k8s-ify this but I couldn't find a good way to find out which backend is ingesting what stream.

iSchluff commented 1 year ago

@ravenium well redis is not easily distributed, so there would be no benefit to using it. There would be ways to do this without an additional piece software, it's just more complicated. e.g. using https://github.com/hashicorp/memberlist and distributing data between manually

ravenium commented 1 year ago

You're probably onto a better solution - I was thinking of just pointing all of them at a central redis container as a sort of state tracking, but then again that probably wouldn't account for dead/stale nodes and...well, a lot of things :)