1

When live streaming in outdoor with weak network conditions, there are some devices to aggregate networks like MPTCP router. But packet loss in MPTCP, will cause the live streaming problem, like stream interruption.

So if publish multiple live streams to server, it's much robust than single stream. My question is: How to switch between streams, if some stream has problem, without reconnect for player?

For example, publish two streams:

  • streamA rtmp://xxx/app/streamA
  • streamB rtmp://xxx/app/streamB

Play the stream, whatever which stream is selected:

  • stream rtmp://xxx/app/stream

If streamA is poor quality or interrupted, administrator could switch to streamB, and player still play stream without reconnection.

In addition, there is no need to refresh the playback end, stream will not interrupt, video content will not repeat or jump frame.

Winlin
  • 1,136
  • 6
  • 25
四丿季
  • 11
  • 3

1 Answers1

0

To support multiple streams fault tolerance, there are some solutions:

  1. Server solution: Publish streams with the same name, play only one stream.
  2. Server solution: Publish streams with different names, play only one stream.
  3. Client solution: Publish streams with different names, play a list of streams.

Client Solution

It's the most simple solution, for example, let's say publish two streams:

  • streamA rtmp://xxx/app/streamA
  • streamB rtmp://xxx/app/streamB

Player get the playlist from your backend server:

  • streamA rtmp://xxx/app/streamA
  • streamB rtmp://xxx/app/streamB

If serverA is unavailable, user will switch to streamB. Highly recommend this solution, because it's simple and robust, and no change need to be made for the streaming system.

Note: Player also could play HTTP-FLV/HLS or WebRTC, please read this post

Server solution: Multiple URLs

If publish multiple streams, each with its URL, like this:

  • streamA rtmp://xxx/app/streamA
  • streamB rtmp://xxx/app/streamB

The media server will merge these URLs to one URL, for switching automatically if stream is unavailable, to enable the player always use one URL to play the stream:

  • stream rtmp://xxx/app/stream

Note: Player also could play HTTP-FLV/HLS or WebRTC, please read this post

For SRS, this feature is named Alias for Stream, which is not supported right now(at 2022.01), but there is a workaround, use FFmpeg to covert streamA to stream:

ffmpeg -f flv rtmp://xxx/app/streamA -c copy -f flv rtmp://xxx/app/stream

If streamA is unavailable, administrator should switch to streamB by start a new FFmpeg cli, after killed the previous FFmpeg process:

killall -9 ffmpeg
ffmpeg -f flv rtmp://xxx/app/streamB -c copy -f flv rtmp://xxx/app/stream

This solution is much simple, nothing need to be done for the streaming system and player, it should works perfect.

Server solution: One URL

If publish multiple streams with the same URL:

  • streamA rtmp://xxx/app/stream
  • streamB rtmp://xxx/app/stream

It requires the media server or cluster support this feature. SRS has no plan for this, because it's not simple enough than previous solutions.

However, some video cloud platforms already support this feature, like Tencent Cloud Streaming Services.

Other Issues

If switch between streams, there always be some issues, like content repeating, or lagging. Think about the first solution, player play a playlist with two streams, if switch to another one, it's impossible to play the same timestamp because it's live streaming.

You could try HLS, to switch between streams, and play from the next ts file of another stream, but I'm not sure whether it works.

I think when stream switching, it means some big problems like network fail or device corrupts, it seems OK unless the stream is unavailable.

Winlin
  • 1,136
  • 6
  • 25