Failover with external push

[Apollo]

Been trying (and failing) to wrap my head around this for a while, and I just can't quite figure this out, so I figured I might as well just ask here.

I currently have a stream set up which I stream to from OBS (RTMP push input), and I have that set up to then be pushed to Twitch with an automatic push. This all works perfectly. But where I'm having issues is when I try to set up a fallback stream (my system isn't always super stable so I want a backup for when things go wrong). Ideally I'd like to have that fallback just pull from a VOD source (I would like to just make a little video that shows when things crash), but the push doesn't seem to pick up on the fallback. Also I'm having issues with the VOD stream itself, but that seems like a separate thing to me.

Anyway, is this just a limitation of MistServer, or is there a way to do this? I see there's some pretty advanced things I can do with triggers and whatnot, so I'd imagine it's possible, but I can't seem to figure out any way to do it.

[Balder Vietor]

Heya,

There's a few methods to go about this, but they are quite technical to set up. Then there's also a few things to note about how "good" the fallback is. Obviously for the fallback to truly work well it also needs to run on a remote server. Which does have the fun little problem that if you get locked out because of internet failure your stream would potentially be running that fallback until you turn it off. Not necessarily "bad" but something to keep in mind.

To explain the fallback option in MistServer:

This option is meant for viewers, not for sending out. When this option was first created it was made to make sure that viewers wouldn't get a stream offline, but instead can get forwarded to another stream. The option however is somewhat dated in comparison to the rest of MistServer so there's plenty of things we want to change to it. Being able to work for push out is one of them. Currently I would say this isn't going to be working for Push out easily. It can probably be done, but I wouldn't recommend using it and instead go a different route.

That said this is something on our wishlist for "fixing", but it is somewhat of a hard problem to solve without encoding which we currently don't do directly. So sadly there's only long answers of "other" things you can use to do this. So if you had something else in mind feel free to use that instead!

Getting the fallback to work

I can see two methods to get this to work "easily", though perhaps not perfectly. The first route would be going through encoder software, now this does mean that generally speaking the quality of the stream will take a small hit. You'd be re-encoding something and depending on the strength of the remote server you'd be stuck at a certain quality. 

The second route wouldn't need that encoder, but is more finicky and perhaps more technical to set up. However it wouldn't need an encoder and would assume you're using the same quality everywhere to get it to work.

1st route, encoding

Gstreamer has a perfect component to solve this issue in libgstfallbackswitch.so . It's a tool we've recommended to most users that do not have access to professional equipment to solve this problem. The only "problem" is that encoding is kind of harsh on the CPU and will require a server of "some" quality. That said if it's only 1 stream you want to do most servers and CPUs will do that just fine. The true difficulty is that this solution does not scale well, so don't try doing this with multiple streams.

I would expect this needs to run in Linux, I have no experience with using gstreamer under Windows/Mac, but I would hope it's not too different.

Installing gstreamer should be straightforward on any OS, it's a well known package.

Now installing fallbacksrc is somewhat more of a challenge as it isn't a standard package. 

We do have one pre-built for Ubuntu24, which should work in "most" other Linux OS as well. I've included it in this, hopefully that works, otherwise there's one hosted here for a while: 

https://transfer.ddvtech.com/get/Q47PyJ5fy0/gstreamer-fallbacksrc.tar.gz

To install:

Copy the `libgstfallbackswitch.so` into your gstreamer installation folder. For most OS this should be:
```
/usr/lib/x86_64-linux-gnu/gstreamer-1.0/
```

You know it'll work if you can inspect it:

```
gst-inspect-1.0 fallbacksrc
```

What is fallbacksrc

Fallbacksrc is a source for gstreamer within the libgstfallbackswitch.so. This input takes 1 main input and if that fails switches over to the backup input, whether that be another stream or a file. Now this obviously will do some encoding and that will cost CPU and depending on the settings lower the quality. Other than that it will run on 24/7 or until the script is stopped. Even then if you use this as a source within MistServer if there's an always on flag enabled it will restart & continue. So there's a few things to keep in mind when stopping this stream. It usually is easier to stop the push to Twitch and make sure the push is not set to active when you do so.

So all that is left is running gstreamer, telling it to pull a stream from MistServer and use a VoD file when the stream drops. This can be done through a command:


Command
```
gst-launch-1.0 -q fallbacksrc uri=http://127.0.0.1:8080/streamname.mkv  restart-on-eos=True fallback-uri=file:///path/to/file  name=d  d.video ! queue ! videoconvert ! vidmix. compositor name=vidmix background=black sink_0::xpos=0 sink_0::ypos=0 sink_0::width=1920 sink_0::height=1080 ! x264enc pass=qual speed-preset=ultrafast bframes=0 quantizer=25 key-int-max=25 bitrate=5000 ! mpegtsmux name=mux ! fdsink     d.audio ! queue ! audioconvert ! faac ! mux.
```
Now the above does set a few things such as resolution, keyframe interfal and bitrate, feel free to change/add to these, but I would recommend reading up on gstreamer to  change them all properly. The compositor + black background is included to make sure there's "something" should everything fail (namely a black screen). You'll also see this when the process boots up.

Other than that it's pulling from a localhost mistserver using the MKV output, which should be decently fast & reliable.

2nd route, no encoding

Now I'll not fully explain this as personally I think this route is of lesser quality than the first. But should you be interested in it I can explain it more detailed. 

The idea here is to create a recording of the same quality you'd be sending out as a fallback. Then using this video to create a playlist of 1 file (meaning MistServer will keep repeating that one file). We do currently have a problem with .mp4 source sin our .pls streams. So I would recommend TS or MKV when creating this file. 

The playlist itself is just a tekstfile ending on .pls with only the location of the VoD file (can use just the name.ts/mkv if it's the same folder) and a white line below it.

MistServer can ingest that and see it as an order to input the stream & keep repeating it. Making it a fake "live" stream.

This can then be used through push and custom variables to create a check on whether the main live stream is online, and start the push when it isn't. 

Now you'll also need something on the main live stream that when it's online the push by the fake live stream is stopped and you're done. They'd be able to switch between the two of them.

The downside however: Switching is a "new" push, so 100% Twitch will see this as a new stream when the fallback activates or when you go back. There's no "clean" transition and the chances of triggering any end of stream logic on Twitch's side is quite high. So I wouldn't really deem it a good option. However it might be better than nothing. 

Best,

Balder Vietor | Supreme tester

e: balder...@mistserver.org

--
You received this message because you are subscribed to the Google Groups "Mistserver.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mistserver+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/mistserver/48ec77ce-de43-41cd-b220-0cc9a8ba7d1cn%40googlegroups.com.