有些人吶，真是不見棺材不落淚，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？
答案是：
所謂延遲，就是推流和播放器的延遲，可以用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。
各位收好，不謝。