Workerman不处理RTSP转码，需FFmpeg拉流转封装为FLV/TS，再由Workerman通过WebSocket透传给前端flv.js播放；其仅适合信令中转，不建议exec调用FFmpeg。
Workerman本身不处理RTSP转码，得靠FFmpeg中转
Workerman是PHP异步框架，擅长WebSocket连接管理、消息广播和状态维护，但它没有音视频编解码能力。想把RTSP流推到网页，必须用ffmpeg完成拉流、转码、封装，再由Workerman把转好的流（如FLV或MSE分片）通过WebSocket分发出去。常见误区是以为Workerman能“直接读RTSP”，实际它只能接收已解码/已封装的数据流。
正确链路：ffmpeg拉RTSP → 输出HTTP-FLV或MPEG-TS → Workerman WebSocket透传
浏览器不支持RTSP，也不原生支持RTMP；但能用fetch或MediaSource加载HTTP-FLV或MSE兼容的TS片段。所以推荐走这条轻量路径：
-
ffmpeg命令示例（稳定拉流+低延迟输出）：ffmpeg -i "rtsp://admin:12345@192.168.1.100:554/h264/ch1/main/av_stream" \ -vcodec libx264 -acodec aac \ -f flv -flvflags no_duration_filesize \ -r 25 -s 640x360 -g 50 \ http://127.0.0.1:2345/flv/live
- Workerman监听
http://127.0.0.1:2345/flv/live这个HTTP端点（需自行实现HTTP Server或用Workerman\Protocols\Http），收到FLV头+Tag后，不做解析，直接广播给所有WebSocket客户端 - 前端用
flv.js播放：new FlvPlayer({url: 'ws://your-domain/ws?stream=live'}) - 注意：不要让Workerman去调用
exec('ffmpeg ...')——子进程生命周期难控，容易漏帧或崩溃
WebRTC方案更优，但Workerman只适合做信令中转
如果对延迟敏感（信令交换（如交换SDP、ICE candidate）。真正的媒体流走P2P或经mediamtx等专用媒体服务器转发。Workerman无法替代mediamtx或janus-gateway做DTLS/SRTP加解密、NAT穿透或Jitter Buffer管理。
- WebRTC真正干活的是浏览器和
mediamtx，Workerman只负责socket.emit('offer', sdp)这类消息路由 - 若强行在Workerman里用PHP解析RTP包，性能会断崖式下跌，且无标准库支持H.264 Annex-B NALU提取
- 测试时务必关掉
ffmpeg的-re参数——它会让推流按原始帧率“模拟”读取，导致卡顿
容易被忽略的三个硬约束
很多项目跑通Demo就上线，结果压测时崩在第三天：
- FFmpeg进程必须设置
-timeout 30和-rtsp_transport tcp，否则RTSP长连接断开后不会自动重连 - Workerman的
worker_num建议设为CPU核数，但每个Worker不能同时处理超过20路FLV流——内存和fd消耗会指数上升 - 前端
flv.js默认缓存8秒，要降低首帧延迟，得改config.lazyLoadMaxDuration = 2并配合ffmpeg的-g 50（关键帧间隔2秒）
