同时主要优化点包括：
1、编译宏特性开关优化。
2、转协议复用器相关创建代码移动至Recorder类。
3、转协议复用器onAllTrackReady函数修改为addTrackCompleted。
4、startRecord/stopRecord/isRecording接口新增支持ts/fmp4/hls-fmp4协议。

Co-authored-by: xia-chu <771730766@qq.com>
Co-authored-by: linxiaoyan87 <linxiaoyan87@foxmail.com>

如果rtp时间戳增量很小，在rtp时间戳在转换单位为毫秒时无变化，
从而被认为是上一帧数据，由于处于丢包状态，此rtp数据将被一直丢弃。

FileChannel内部已经把做了转换为MB操作，外面无须再乘以1024x1024

1、调整 json 的源码引入，外部可以引入 json/json.h 使用；
2、针对 iOS 工程调整 cmake 配置，解决 iOS 环境下mk_util.h 找不到问题；同时在 iOS 工程中引入 MediaServer 静态库；

-t 0.001参数替换为-frames:v 1，只截图一帧

1.新增日志文件保存路径启动参数:log-dir
2.新增日志文件最大切片个数启动参数:log-slice
3.新增日志文件最大切片大小启动参数:log-size

H264 rtp打包模式是否采用stap-a模式(为了在老版本浏览器上兼容webrtc)还是采用Single NAL unit packet
per H.264 模式 有些老的rtsp设备不支持stap-a rtp，设置此配置为0可提高兼容性

ntp时间戳计算精度由毫秒调整为微秒，解决误差累积问题。

当客户端发起RTSP SETUP的时候，如果rtp传输类型和配置不一致则返回461 Unsupported
transport。迫使客户端切换到对应rtp传输协议并重新SETUP；目前支持FFMPEG和VLC。

- enable_server cmake选项生效;
- enable_tests 选项在api目录下的test同样生效;
- 增加stdio.h 防止编译失败;

有些设备在发送sender report rtcp时，其rtp和ntp时间戳一直为0，将导致zlmediakit计算出的ntp时间戳异常

在根据rtsp pts生成ntp时，由于pts可能回退，旧有逻辑不允许回退将导致ntp异常

实测发现 如果在点播推流时 如果切片大小设置比较小 一秒钟可能产生多个mp4切片
以前切片名称粒度最小为一秒 所以会存在文件覆盖问题

FindField改名为findSubString

https://github.com/ZLMediaKit/ZLMediaKit/issues/2526#issue-1740204646

通过用户反馈发现，遇到较多直播源时间戳混乱问题，包括rtsp流之rtcp ntp时间戳混乱，国标流时间戳混乱问题。
之前默认采用源流绝对时间戳，但是由于时间戳混乱会导致hls切片异常或视频播放不了等问题。
故默认改成相对时间戳(modify_stamp=2)，通过时间戳矫正器过滤了时间戳跳跃以及回退问题(强制加1ms)，
同时保留了对之前时间戳覆盖(modify_stamp=1)的兼容。
该修改同时兼容点播流，在点播流开启时间戳覆盖时，不起实质作用(采用原始绝对时间戳)。

Make available the media_info variable for the class inherited from WebRtcSession and HttpSession. (#2505 #2461)

当TCP RTP包大小为256字节时，可能触发RtpSplitter::onSearchPacketTail误判为EHOME格式。
这个修改一旦检测到数据不是EHOME格式，则后续不再进行尝试，以减小误判的风险。

当RFC4571封装的RTP包大小在0x2400到0x24ff之间时，会被误认为是RTSP Interleaved
封装的数据。因为0x24正好是'$'的ASCII码，而RtpSplitter::onSearchPacketTail通过'$'来识别RTSP
Interleaved数据。暂时没有想到什么好的办法能够百分之百的正确区分RFC4571数据和RTSP
Interleaved数据。增加一个状态变量记录之前的状态，一旦检测到数据不是RTSP
Interleaved格式，则后续不再进行尝试，以减小误判的可能性。