N(>=3)年前Adobe官宣了2020年底就不支持Flash了，最近发现非常多的朋友，到了真正完全不能用时，才考虑如何逃生，一顿狂问“没有Flash了怎么播放RTMP”，“该选HTTP-FLV还是WebRTC”，“用什么播放器播HTTP-FLV”。
没有Flash了怎么做直播？
答案是：PC用H5。
为什么不说客户端？
因为客户端上早就没有Flash，不会问这个问题。客户端上浏览器，比如微信的浏览器，如果要播放直播可以用HLS。如果是微信小程序，可以用RTMP的。如果是自己的Native客户端，那可以用各种云厂商的SDK，或者开源的基于FFmpeg的方案，比如Fijkplayer。
反正，一句话说来，客户端因为早就习惯没有Flash了，这个问题不存在。
PC怎么用H5呢？本质上有两个技术：
- MSE：目前很成熟的技术，是js的解码器，把MP4格式的文件，送到MSE解码播放。其实很多播放器底层都是用的MSE，比如flv.js播放HTTP-FLV或者WebSocket-FLV，比如hls.js播放HLS，比如dash.js播放DASH切片。
- WebRTC：目前做直播还不太成熟，是做RTC通信还算比较成熟的一套技术，有自己的编解码逻辑。做直播不太成熟，是因为它本身不是干这个的，有些逻辑不太一样比如录制，另外通信比直播复杂太多了，所以如果只是做直播的话，肯定是不推荐上这么高难度骚操作的。
这两个技术又涉及到了几个问题，我们下面继续讲。
用HTTP-FLV还是HLS？
答案是：
- 看你的业务的延迟要求，2-5秒用HTTP-FLV，5-10秒用HLS。如果是替代RTMP，一般来说要用HTTP-FLV，因为RTMP延迟也是3秒左右。
- 看业务对平台的要求，跨平台要求很强就用HLS，比如要在PC和移动端浏览器中都能播放那就要选HLS了。
所谓延迟，就是推流和播放器的延迟，可以用OBS抓一个网页的秒表，然后播放器上观看，对比这两个时钟的差异，就是延迟了。
HLS是否就不能做3秒延迟呢？比较难，但是HLS延迟可以做一些优化，估计能到5秒左右，详细可以参考百毫秒超低延迟直播方案中HLS延迟优化的配置。
如果选择了HTTP-FLV，那么在移动端就不能用浏览器播放，但是移动端可以用Fijkplayer播放，这是为了追求更低延迟要付出的兼容性代价。当然，并非所有业务，都要求移动端浏览器观看，所以这个要根据自己的业务来。
是否保守点直接选HLS？如果对延迟有一定的要求，那么就不合适，所以还不能这么武断的全部选择HLS。
用HTTP-FLV还是WebRTC？
答案是：HTTP-FLV。
WebRTC是做通信的，不是用来做直播。在直播业务中，目前并没有经过大规模的验证，配套的东西也不如直播这么完善，比如微信小程序就没法用WebRTC了。
现在云服务也开始推出WebRTC直播服务，当然是可以用的，问题是云服务也支持HTTP-FLV，为什么不选择更通用的方案？除非延迟要求非常低，比如1秒之内的延迟。
自己问下自己的业务，是否要做到1秒之内的延迟。那么就需要牺牲更多的兼容性代价，如果这个代价是可以接受的，那么WebRTC做直播也不是不能选的。可能有那么一天，WebRTC直播也成为普通的选择，那就是另外一回事了。
有没有更好的协议？
答案是：RTMP、HTTP-FLV和HLS一起用。
最好的替代场景是这样的：
- PC浏览器，延迟有要求的用HTTP-FLV，延迟没要求的用HLS。
- 移动端浏览器，用HLS，兼容性比较好，几乎都支持。
- 移动端微信小程序，用RTMP，或HLS。
- 移动端Native，用RTMP或HTTP-FLV。
用什么播放器？
这个问题就比较简单了，根据协议可以选择播放器：
- HTTP-FLV，PC上用flv.js，移动端用Fijkplayer。
- HLS，PC上用hls.js，Safari、iOS、Android可以H5直接播。
- WebRTC，PC上用H5（得自己写代码调API），移动端得用SDK。
引用 SRS开源服务器
