作者：忘篱
来源：SRS开源服务器

没有 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，HTTP-FLV 或 HLS。

• 移动端 Native，用 RTMP 或 HTTP-FLV。

目前直播的云服务，这三个协议都是支持的，如果不能支持，自己用 SRS 搭建直播源站，转协议后分发，就可以支持了。

而且 SRS 还能将 RTMP 转成 WebRTC，是居家必备的不二之选。

用什么播放器？

这个问题就比较简单了，根据协议可以选择播放器：

• HTTP-FLV，PC 上用 flv.js，移动端用 Fijkplayer。

• HLS，PC 上用 hls.js，Safari、iOS、Android 可以 H5 直接播。

• WebRTC，PC 上用 H5（得自己写代码调 API），移动端得用 SDK。

「视频云技术」你最值得关注的音视频技术公众号，每周推送来自阿里云一线的实践技术文章，在这里与音视频领域一流工程师交流切磋。