请注意,本文编写于  242  天前,最后编辑于  242  天前,内容可能已经不具有时效性,请谨慎参考。

flashdie.png

N(>=3)年前Adobe官宣了2020年底就不支持Flash了,最近发现非常多的朋友,到了真正完全不能用时,才考虑如何逃生,一顿狂问“没有Flash了怎么播放RTMP”,“该选HTTP-FLV还是WebRTC”,“用什么播放器播HTTP-FLV”。

没有Flash了怎么做直播?

答案是:PC用H5。

h5.jpeg

为什么不说客户端?

因为客户端上早就没有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开源服务器

Q.E.D.

知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议

Do what i love and just do it !