OriginCluster: Restore HLS information when republish stream

[winlinvip]

如果重推RTMP流，对于HLS的影响是什么？

SRS Single Origin

对于SRS单进程来说，会插入一个DISCONTINUTY后继续切片和更新M3u8，客户端会继续播放。

Note: 注意Source清理，不能立刻清理，会导致丢失HLS的切片信息。而应该使用延迟清理，比如延迟1小时候清理，这样在1小时内重推流，可以继续切片。

Note: 注意有hls_dispose，在停止推流后，会清理切片，同样应该考虑实现延迟处理，而不应该直接清理。

而对于非单进程，比如NGINX RTMP多进程结构，或者SRS源站集群，重推可能会导致流推送到不同的进程，或者不同的SRS，这时候对于HLS会发生什么？

NGINX RTMP

先说结论：多进程的NGINX-RTMP解决过了重新推流对HLS的影响，但是如果要组多机器的NGINX RTMP源站集群，也一样存在HLS的序号不连续等问题。

搭建NGINX和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

开启多进程，重新推流时，也会继续HLS切片。有个ngx_rtmp_hls_restore_stream的函数，会恢复这些信息。

第一次推流：

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

第二次推流：

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

会在不同进程处理RTMP流和切片。

SRS Origin Cluster

SRS源站集群，客户端重新推流后，会推送到不同的源站SRS，导致M3u8和TS不连续，大概率造成播放器不可用。

Workaround: 如果只需要RTMP转HLS，可以用多端口独立源站，避免源站集群。

Workaround: 可以用on_hls，由业务系统重新生成HLS流，处理HLS在不同服务器之间漂移的问题。

Workaround：可以用vhost机制，实现不同的流回不同的源，而不用源站集群。

比较合理的解决方案，还是需要恢复HLS的切片信息，这样在推流漂移到其他服务器或进程线程，一样可以继续处理流。

[winlinvip]

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

TRANS_BY_GPT3

[winlinvip]

Dup to https://github.com/ossrs/srs/pull/3126 https://github.com/ossrs/srs/issues/3506