当HlsPlayer拉取索引失败后会触发PlayerProxy的重试机制.
但是这里就有一个bug会导致重试次数不准确.
因为HlsPlayer播放失败会调用onShutdown.
然后回调PlayerProxy.
之后如果触发重试, 那么在HlsPlayer析构的时候又会在调用一次onShutdown.
这时候是安全的, 因为_on_shutdown已经被置空.
但是如果重试时又再次失败, 那么首先会调用
onPlayResult
这时候在PlayerProxy中会再次触发重试, 紧接着HlsPlayer析构, 又会调用一次onShutdown, 那么就又会触发一次重试.

修复方法有很多, 最简单的就是直接在
onShutdown中判断如果没有_demuxer就不需要父类的onShutdown方法来释放资源与重连了.
因为针对HlsPlayer来说, 如果重试拉取索引没有成功, 应该没有什么资源需要在onShutdown方法中释放了.

当然更完善的修复应该是在PlayerProxy中增加相关的判断逻辑, 给rePlay一个状态.
确保rePlay执行完成前, 不再执行一次rePlay.

具体哪种方式, 大佬您可以看着办.

This reverts commit 471a8b77

* Update main.cpp

* 双重保险, 避免重启失败

业务繁忙的服务器当子进程崩溃后,
虽然延时了3秒, 但是如果服务器负载很高, 或者开启了coredump
会导致拉起子进程时, 仍旧端口占用导致子进程重启失败而直接退出主进程.

因此, 这里做了双重保险, 当子进程拉起时如果端口占用, 那么子进程会继续重试.

2.修复由于丢弃sei帧导致ffplay不能正常播放

* Update HttpChunkedSplitter.h

* 避免m3u8文件为chunked时崩溃

具体问题见
https://github.com/ZLMediaKit/ZLMediaKit/issues/1407

当数据最后小于2个字节时, 应该放弃回调.
做个保险, 避免导致溢出后崩溃.

这个bug很难出现, 但是的确存在. 一些特殊的服务器采用chunked返回的m3u8文件解析时, 有可能会遇到.

* Update HttpChunkedSplitter.cpp

Co-authored-by: 夏楚 <771730766@qq.com>

* hls拉流时应该适当重试

hls拉取索引文件失败时, 不应该直接上报,而应该内部适当重试几次.
避免由于网络抖动造成的客户端播放不流畅.

* Update HlsPlayer.cpp

少了一次构造调用,为什么不用呢?

修复HlsPlayer播放器BUG

在负载比较重的机器上重启子进程太快了.
很容易导致端口仍旧还未释放完毕导致的错误
端口已被占用
从而主进程直接退出.
因此适当延长重启的间隔时间

当拉取加密流时, 因为不能正常播放, 所以不会触发playresult.
因此一直不会回调api请求.

修正未初始化导致的播放异常问题

使用clone替代fork
因为fork子进程有时会导致提前写时复制, 进而影响性能.
而vfork又会引起父进程阻塞
所以使用clone来产生子进程运行ffmpeg