问题背景：
今年疫情的原因导致直播卖货、快抖短视频、视频会议和在线教育都迎来了井喷。这些业务的落地技术方向基本就是两大类，一类是在传统直播技术上的一些演进，另外一类就是以WebRTC技术为核心或者极其变种的低延时实时通信。
前者无非就是上行编码推流------->传输----->下行拉流解码，这一块技术方案是比较成熟的，其中就以SRS为代表，可以用SRS搭建运营级的互联网直播服务器集群。以前公司业务针对下行，有很多模块，有些是HLS协议下行分发，有些是RTMP下行协议分发，HTTP-FLV也有。这些模块零零散散，对应核心功能在SRS中都已经实现而且比较稳定，着实没必要重复造轮子。近期我们就做了一些事情，把这些成熟下行协议逐渐迁移到SRS中来，迁移过程肯定有些坑，这里简单记录下，对于一些问题给出基本的解决思路和方案，供大家参考，详细内容可以后台留言沟通。
方案落地：
问题1：怎么把公司内部私有流、私有协议对接到SRS？
思路：开发一个流媒体代理服务，将公司私有流、私有协议转成成标准协议如RTMP-FLV即可，这样就可以将该路流推到SRS，接下来这一路流到用户端用HLS、RTMP、HTTP-FLV都可以，只取决于业务调用方调用代理接口指定需要的拉流方式即可，代理服务返回对应的拉流URL，真正做流媒体分发逻辑的SRS只需要添加相关配置启动即可，一般情况下不用改任何代码；
问题2：推流链接和拉流链接怎么生成和管理？
由于需要先将公司私有流先推到SRS上，则需要代理服务生成RTMP推流链接和播放端想要的拉流链接，推流地址的ip和端口就是SRS的RTMP所在服务器IP和端口，如果在一个机房则直接用内网地址即可，app/stream这块规划是：app跟业务有关系，其中表示将公司那块业务的流转成标准流推出去（有些流来自自营摄像头有些来自国标第三方设备和平台。也有些来自回放云储存流），stream则根据每次请求会话生成，主要包含了流源端的一些信息如设备ID号和会话ID等信息。拉流URL则配置拉流协议类型、Domain、app、stream等信息，这里的app/stream和推流链接中是保持一致的（只要请求的该路流已经在推流则有会话复用逻辑），从而便于SRS完成该路流不同协议的下行分发。
后续只要是对该路推流的观看，都是app/sream不变，只变URL的Token部分即可。
如果你对这块内容不清楚可以先参考：
https://blog.csdn.net/weixin_34143774/article/details/92715230
对一个设备的推流链接和对该路流的多个播放链接示例:
RTMP-FLV推流链接：
rtmp://10.12.10.108:1935/oss/eHh4eFNfN2NhN2IwMzE1N2M1OmEwYzBhshwMtMWRjNWUyMC0wMzY4NWM4NA
HTTPS-FLV播放链接：
A播放端播放链接：
https://stg.cqwlw.com/oss/eHh4eFNfN2NhN2IwMzE1N2M1OmEwYzBhshwMtMWRjNWUyMC0wMzY4NWM4NA.flv?token=YTBjMGE2Yy0xZGM1ZTIwLTAzNjg1Yxx0OjE2MDM0MjQzNjU
B播放端播放链接：
https://stg.cqwlw.com/oss/eHh4eFNfN2NhN2IwMzE1N2M1OmEwYzBhshwMtMWRjNWUyMC0wMzY4NWM4NA.flv?token=YTBjMGE2Yy0xZGM1ZTIwLTA1OTVlY2U0OjE2MDM0MjQ2NTY
问题3：拉流链接URL的Token鉴权怎么管理？
代理服务给播放端返回了拉流URL，则含有token信息其中包含了有效期等，当客户端用拉流链接向SRS拉流时则会回调到代理服务中做鉴权，通过则让SRS下行分发，鉴权不通过直接拒绝客户端请求，其中SRS回调代理服务的地址可以在配置文件中直接配置。
具体参考：
https://github.com/ossrs/srs/wiki/v3_CN_HTTPCallback
https://github.com/ossrs/srs/wiki/v3_CN_DRM#token-authentication
问题4：拉流请求链接如HTTP-FLV方案如果走HTTPS，怎么进行？
SRS前面加一个反向代理服务如Nginx，生成证书和私钥配置下就行。其次代理服务需要返回对应的HTTPS-FLV拉流链接。
当然官方也给了类似的方案：
https://www.bilibili.com/video/BV1bK4y1x7Ut/
问题5：怎么适配多端播放需求？
这个要看业务诉求（对延时、视频质量，以及对接的业务方是否有开发能力等因素），一般情况下：
1. PC Web端播放，前端借助flv.js直接返回HTTP(s)-FLV拉流链接即可；
2. 移动APP用SDK开发即可，本质那种协议都可以对接，包括公司的私有流私有协议都可以；
3. 如果微信小程序对延时不敏感返回HLS播放链接，对延时敏感客户端有开发能力则用RTMP-FLV和HTTP(s)-FLV都可以，一般基于微信小程序的live-player媒体组件即可。
参考：
https://developers.weixin.qq.com/miniprogram/dev/component/live-player.html
问题6：265码流怎么适配多端播放？
两种解决手段：
1. 一种协议自身就支持或者稍微改改就可以支持的，如HLS对于265码流则用HLS FMP4方案或者DASH FMP4，对于RTMP和HTTP,则只需要FLV扩展下CodeId即可，这个SRS4.0已经支持，我们用的3.0则自己实现了下。
2. 另外一种则服务端进行转码，我们在代理服务向SRS推流之前则完成H.265到H.264的转码，然后还是用标准的RTMP推流出去即可。
https://github.com/ossrs/srs/pull/1747
问题7：代理服务什么时候停掉推流？
如果向SRS3.0推一路RTMP流，如果不主动停掉则会一直推流下去，浪费带宽也没必要。我们采用的手段是代理服务会定时查询app/stream这路流是否有人观看和拉流，如果没有则会主动停掉，浪费不必要的带宽和资源。
参考：
https://github.com/ossrs/srs/wiki/v3_CN_HTTPApi
问题8：问题排查是否有啥好的手段？
用下来，SRS对于常用的协议支持还是比较稳定的，除了性能并发数限制外，没有啥大的问题。其次SRS提供了RESTFul API来查询会话拉流等信息，这块稍微集成下搞一个查问题工具即可，当然也可以通过看日志 核心业务监控等方式，对于代理服务也提供类似API，供外部排查问题工具集成。
https://github.com/ossrs/srs/wiki/v3_CN_HTTPApi
后续规划：
利用了SRS之后的确可以解放一部分人力，排查问题和一些重复劳动都可以利用SRS的现成能力取代，比如集群，协议转换和转封装、录制等，即使没有去SRS代码上扩展也是比较容易的。
1. 对于低延时场景后面会将代理服务或者设备侧推流逐渐切换到SRT协议上和SRS4.0进行对接，下行可以使用基于UDP的WebRTC协议等，为一些低延时场景提供方案；
2. SRS4.0提供了国标GB28181接入，我们有自己的国标接入网关，所以暂时没用，后面可以考虑接入，这样可以减少视频流传输路径经过的节点，让整个后端流媒体服务架构更清晰。
3. 可以参考SRS的一些方案和实现，搞一些创新性方案比如景区直播画中画，添加摄像头直播时的背景音乐和广告等；
