背景
当存在一个推流客户端正在向rtmp://xxx.com/live/yyy推流时,又有另外一个推流客户端同时对这个地址进行推流,会发生什么呢?
查阅了 Adobe RTMP Spec 发现规范本身并未说明和定义这个场景下RTMP服务器应该怎么处理。
最近在实际工作中遇到部分客户对推流地址资源管理不恰当而导致重复推流报错的问题,且在查问题的过程中发现各个CDN厂商对“抢流”的处理各不相同,查阅相关文档说明发现资料甚少,故专门对它们的抢流行为做如下分析。
步骤
- 打开Wireshark捕获网卡,过滤规则:
tcp && tcp.port == 1935
(之所以不直接写rtmpt
是因为还想观察传输层的行为) - 获取对应厂商的推拉流URL,假设推流地址是:
rtmp://xxx.com/live/yyy
- 使用
ffmpeg
推送一个本地电影文件:ffmpeg -re -i Movie-1.flv -vcodec h264 -f flv "rtmp://xxx.com/live/yyy"
- 使用另一个
ffmpeg
推送另一个本地电影文件到同个URL:ffmpeg -re -i Movie-2.flv -vcodec h264 -f flv "rtmp://xxx.com/live/yyy"
- 使用
ffplay
播放拉流地址内容 - 观察现象并分析Wireshark抓包结果
厂商
数据
注:下列结果仅代表发表本文的时候的各CDN厂家行为,随着厂商对服务器的更新迭代,可能会有所改变。
结论
总的来说,按当前实验结果来看,在这种细枝末节的功能点上,金山云的文档说明最清晰最规范,点个赞!
网宿的行为符合Flash AS3
的定义,至少有据可依。
而腾讯云与七牛云的文档说明均存在错误的地方(至少本次实验中是这样的),尤其是腾讯云的现象让我很意外。
而阿里云竟然连这块的文档都没有。。(也许是我没搜到,若有的话望指正)