Offline Loop / Offline Image / Offline Fallback

[ezadoo]

I'm sorry that I'm bothering you again with a feature request, but while evaluating some use-cases I found some interesting additions.

Is your feature request related to a problem? Please describe.
Whenever a source disconnects due to an connection issue or an other technical problem, the stream goes offline.

The same applies if the source hasn't started publishing or the stream has ended.

But if the stream is offline the user doesn't know if it's a problem on his side or on the server side.

Describe the solution you'd like
So it would be very useful to have the option to define a video (or image?) wich then is looped when the stream is offline.
And if the source reconnects the stream replaces the loop again, and everything is working again.

This could also be extended to play a pre-roll loop (the same loop file), until the live source starts publishing.
This would create an always-on stream, which can also be very useful in some use cases, but without the need of continuous streaming.

I think you should be able to define the loop on a per stream basis.
The same applies to the feature in general, and you should be able to enable/disable it on a per stream Basis too.

This would be like an combination of LoopUntilLive, an Plugin for Wowza Streaming Engine, and the streamRIP plugin for nginx-rtmp.

Also it should be combined with other features, like recording, so that the looping isn't recorded at all, but only the actual stream from the source itself.

Describe alternatives you've considered
Using other services, but they are not as good in regarding latency or not open-source.
Or using a combination of streamRIP and OME, wich adds a lot of latency, so this doesn't make much sense over using only nginx-rtmp.

Additional context
Have a look at Wowza's LoopUntilLive and streamRIP for nginx-rtmp.

[fcqpl]

+1 for looped .ts file!

[command-tab]

Ooh, this is a great idea 👏🏻

[basisbit]

this would make it difficult to detect on the client side that the stream ended / died and automatic fall-back to another source URL would be broken.

Imho you'd better handle such problems in your client side code

[ezadoo]

@basisbit I don‘t See a problem with my feature proposal.
Have you even read my entire proposal?

I think you should be able to define the loop on a per stream basis.
The same applies to the feature in general, and you should be able to enable/disable it on a per stream Basis too.

As it shouldn’t be mandatory to use a fallback loop, you should be able to decide (on a per stream basis) if you want to use a loop or not.

But there are also occurencies where a professional-broadcast-like behavior with a loop would be the better choice or even needed.
Also there may be some cases where the stream goes into multiple applications on wich you don’t have the possibility to change the client side behavior.

I don’t want this feature to be mandatory, and I agree with you in this part, that there may be situations where it isn’t needed or is even an unwanted difficulty.
But on the other hand there may be also situations where an feature like this would be needed or at least really useful.

[getroot]

I think this is a good idea. I will create this task in our backlog.

However, this is a very large task for the following reasons, so it will probably take a very long time to be supported.

1. Supports file input (OME is focused on low latency live, so this task is very low priority)
2. Since there is no per-stream setting in OME, the concept of a persistent stream must be introduced.
3. The persistent stream should be able to receive input through multiple providers and share timestamps between providers.
4. The case where the codec profile of the file and the codec profile replaced by the live input is different must be handled (in this case, only the encoded stream will be played normally)
   ==> How does Wowza or nginx handle this? As far as I know, if you use this feature in wowza and the transcoder is not used then playback will break in the player. How about nginx?

[bchah]

I agree with @basisbit.

It's definitely easy to get excited about the many possibilities of OME, but the best thing for everybody is if the OME team can focus on the core functions, compatibility and performance. Your request might get more traction in the OvenPlayer project actually.

The good news is, OvenPlayer already has methods and hooks which should let you accomplish what you're looking for.

E.g. player.on('stateChanged') or player.on('allPlaylistEnded') could then trigger player.load({yourFallbackSource})

And OME has a REST API which can quickly tell you if the stream is actually online - you could periodically query the status of the live stream from the client and if it's not online, reload the fallback source whenever the player fires a 'complete' event.

The REST API alone solves this concern:

But if the stream is offline the user doesn't know if it's a problem on his side or on the server side.

E.g. a REST API call might change the error message on the player from 'Connection Error' to 'Stream Offline'.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ezadoo]

Keep active for the future

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ezadoo]

Not stale

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[getroot]

This has been released.
#1461

You can do this with the right combination of FallbackStream and Program.

[basisbit]

@getroot can you please provide a full sample configuration where such an offline media -> live stream -> (internet of streamer dies) -> offline media -> live stream transition works? The many partial section samples make it difficult to figure out what a full minimal typical working config would look like.

[getroot]

#1461 (comment)