夏楚

对 你异步解码就行。 事实上，现在解码器基本都是异步的 ，因为是多线程解码。 阻塞你的解码驱动调用线程的目的只是解码不过来 触发了限流罢了

推荐master分支 最新的分支。 zlm采用滚动发布机制，其他几点0分支相当于一个里程碑，在重大功能更新时，当前master分支会存档为几点0分支， 然后把大量修改后的分支推送为master分支。 一般来说几点0分支是比较稳定的，因为功能趋于稳定不变了，master分支也比较稳定了(刚发布时不太稳定)。 其他老的几点0分支基本没啥bug，但是功能会落后一些，而且基本不会同步bug修复补丁。 也就是说没所谓的LTS版本，主要是精力不够。推荐使用master分支，有bug会及时更新修复，支持更及时。 我们在修复用户反馈的bug时，都是建议更新到master分支(不太久远的也行)，如果还是存在，就会去及时修复。

不过zlm迭代这么久了 已经没有严重bug了，非常稳定了。

如果payload type和ssrc不一致 会被忽略

可以返回originUrl这个值 也就是getMediaList接口返回的那个。 你们拿到后自己去解析吧，不过在录制hook触发时 这个值不一定有，因为MediaSource可能已经注销了。 很多功能没实现，是由于代码层级结构和抽象后所限导致的。你说的录制hook不仅推流会触发，addStreamProxy也会触发， 但是这在zlmediakit中是统一的 你告诉我怎么从拉流代理中获取推流参数？

想想还是不好做 因为做起来有很多不完美的地方 干脆就不做算了

按道理 linux和Windows不应该出现差异性

我主要是没Windows开发环境 H264存档的文件发我看下？

感谢您的pr！ 现在HttpRequestSplitter对http请求长度有最大kMaxCacheSize(4MB, 配置文件默认40KB)的限制, 应该是无法实现内存溢出攻击的。 另外，zlm也对http连接是有超时端口的，您说的攻击貌似无法实现。

/index/api/broadcastMessage接口