同时新增程序启动日期、是否开启编译ffmpeg选项

* 部分hls中会出现类似[../]或者[./]的相对地址, 因此写了一个解析的方法

* 有时候上游http协议不规范会导致直接输出eof, 特别是在自动重试机制开启下, 容易造成定时器没办法初始化从而拉不到流但是session一直存在,所以需要做一个判断,如果没数据直接报错

* 优化MultiMediaSourceMuxer头文件包含

* 将MediaSinkDelegate和Demux移到MediaSink中

* MediaSource头文件重构, 独立出PacketCache.h
精简Frame和Track的头文件

* Rtmp头文件重构

* Rtsp头文件重构

* webrtc头文件重构

* 规范.h头文件包含，并将其移到.cpp中:
- 尽量不包含Common\config.h
- Util\File.h
- Rtsp/RtspPlayer.h
- Rtmp/RtmpPlayer.h

* 删除多余的Stamp.h和Base64包含

- MediaSource引入shortUrl和getUrl来简化日志输出
- WebApi引入fillSockInfo

* 修改hls拉流后closestream崩溃的bug

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

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

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

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

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

* 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

* 动态计算切片超时时间

设置最大超时时间倍数和最小倍数,然后根据上一个切片的下载情况动态增加或者减少切片的超时时间.

* Update HlsPlayer.cpp