OriginCluster: Restore HLS information when republish stream

[winlinvip]

What is the impact on HLS if the RTMP stream is re-pushed?

SRS Single Origin

For SRS single process, it will insert a DISCONTINUITY and continue slicing and updating the M3u8. The client will continue playing.

Note: Pay attention to the Source cleaning, it should not be cleaned immediately as it will result in the loss of HLS slicing information. Instead, delayed cleaning should be used, for example, cleaning after a delay of 1 hour. This way, if the stream is re-pushed within 1 hour, slicing can continue.

Note: Pay attention to hls_dispose, after stopping the stream, it will clean up the slices. Similarly, delayed processing should be implemented instead of direct cleaning.

For non-single processes, such as NGINX RTMP multi-process structure or SRS source station cluster, re-publishing may result in the stream being pushed to different processes or different SRS instances. In this case, what will happen to HLS?

NGINX RTMP

First, let's state the conclusion: The impact of re-publishing on HLS has been resolved in the multi-process NGINX-RTMP solution. However, if you want to set up a multi-machine NGINX RTMP source station cluster, you may still encounter issues such as discontinuous sequence numbers in HLS.

Set up NGINX and NGINX-RTMP.

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-MEDIA-SEQUENCE:2
#EXT-X-TARGETDURATION:10
#EXTINF:2.108,
livestream-2.ts

#EXT-X-DISCONTINUITY
#EXTINF:5.000,
livestream-3.ts
#EXTINF:9.760,
livestream-4.ts
#EXTINF:5.040,
livestream-5.ts
#EXTINF:0.226,
livestream-6.ts

#EXT-X-DISCONTINUITY
#EXTINF:5.000,
livestream-7.ts

Enable multi-processes, so that HLS slicing continues even when re-streaming. There is a function called ngx_rtmp_hls_restore_stream that restores this information.

First streaming:

nginx   75246 video   19u    IPv4 0x57675c0d66f7a73      0t0                 TCP localhost:macromedia-fcs->localhost:58938 (ESTABLISHED)
nginx   75246 video   20w     REG               1,4     3572           124988646 /private/tmp/hls/livestream-6.ts

Second streaming:

nginx   75248 video   16u    IPv4 0x57675c0c6d03a73      0t0                 TCP localhost:macromedia-fcs->localhost:59025 (ESTABLISHED)
nginx   75248 video   17u    unix 0x57675b2759a2043      0t0                     ->0x57675b2759a210b
nginx   75248 video   18w     REG               1,4    42676           124989220 /private/tmp/hls/livestream-17.ts

Will process RTMP streams and slicing in different processes.

SRS Origin Cluster

In an SRS origin cluster, when a client re-pushes the stream, it will be pushed to different SRS origins, resulting in discontinuity in M3u8 and TS files, which will likely render the player unusable.

Workaround: If only RTMP to HLS conversion is needed, multiple independent origin servers can be used on different ports to avoid using an origin cluster.

Workaround: on_hls can be used to regenerate the HLS stream by the business system, addressing the issue of HLS drift between different servers.

Workaround: The vhost mechanism can be used to direct different streams to different sources without the need for a source cluster.

A more reasonable solution is to restore the HLS segment information so that the stream can continue to be processed even when it is migrated to other servers or process threads.

TRANS_BY_GPT3

[winlinvip]

Essentially, it is a problem of statelessness in HLS for the Origin Cluster.

TRANS_BY_GPT3

[winlinvip]

Dup to #3126 #3506