I have already implemented this on the periphery and found that the cost of implementing it on the server is too high and not suitable.

In fact, Sun Wukong's solution can still be improved by removing the dependency on storage:

Two servers can cut similar HLS streams, and each SRS adds a GO server as a frontend web server for hot backup.
Use GO to write this frontend web server and hook the on_hls event of SRS, which can back up all the streams pushed up.
Each GO server, upon receiving the on_hls event, stores the local SRS's ts slices in the local directory.
Each GO server stores the ts slices of the hot backup GO server in the remote directory.
The two GO servers use a voting algorithm to elect a master, which stores the data in the main directory for service provision.
In other words, at any given time, only local or remote is available because main is a replica of either local or remote.
winlinvip@dbcd7d8
Added a script to check if two HLS streams are hot backups.

Checking if two HLS streams are hot backups:

./research/hls/check_hls_backup.sh \
http://ossrs.net:1984/hls/live/livestream/live.m3u8 \
http://ossrs.net:1996/hls/live/livestream/live.m3u8

The following two HLS streams are hot backups, generated by two SRS instances:

./research/hls/check_hls_backup.sh \
 http://ossrs.net:1984/hls/live/livestream/live.m3u8 \
http://ossrs.net:1996/hls/live/livestream/live.m3u8

However, these two streams themselves are not hot backups (they become hot backups after synchronization):

./research/hls/check_hls_backup.sh \
 http://ossrs.net:1984/hls_local/live/livestream/live.m3u8 \
http://ossrs.net:1996/hls_local/live/livestream/live.m3u8

TRANS_BY_GPT3

Uh oh!

HLS fault backup, HLS hot standby #351

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions