關於直播，有很多相關技術文章，這裡不多說。 作為前端，我們比較關心我們所需要的。
直播的大致流程：
但實際我們需要處理一些不可控的情況，這是非常麻煩的。
比如說，直播方網路不好，直播方關閉了攝像頭，這些情況都會導致推流斷掉，在文章後面，我們詳細說這一塊。
目前我們先考慮直播的三種狀態： 直播前，直播中，結束。
針對每個狀態我們肯定會有不同的顯示，這三種狀態可以是三個頁面，相互切換，或者乙個頁面，控制頁面相關隱藏和顯示。
可是我們怎麼知道，當前主播已經切換成某種狀態了呢？ 通過輪詢嗎？ 當然不是，輪詢肯定是可以實現的。 不過我們用websocket，
因為我們已經提前準備
了websocket，所以我們可以通過服務端的推送websocket廣播，當獲取到的直播狀態和當前狀態不同，便進行相應切換。
但是有時候可能因為暫時的網路原因或者其他原因，websocket的廣播訊息，我們並沒有獲取到。 所以可以讓websocket間隔性
的廣播直播狀態。
也可能是使用者網路斷開，造成的斷連。
一方面後端通過他們的優化來提高承載力，一方面前端和後端進行配合優化。 我們每次連線websocket服務
器的時候，前端會通過介面，拿到當前
承載量最小的伺服器位址進行連線。 websocket如果斷連了的話，是不會獲得任何訊息的，所以保證功能可以
使用，我們還會針對websocket進行
心跳檢測（檢查是否斷開連線）。
因為websocket可能會存在斷開連線的情況，而這時候是不會觸發任何事件的，所以我們不知道它是否斷開了。 那麼我們設定一種
訊息型別，
由前端傳送給服務端，服務端如果返回了資料，就說明連線正常。 如果連線斷開了，我們再次去請求後端介面，拿到當前承載量
最小的服
務器位址，
進行重連。 設定乙個間隔時間比如10秒，最後一次獲取到伺服器的訊息後，如果10秒內沒再收到訊息，就進行一次檢查，如果10秒內收到了，
便重置這個時間。
之前的部落格寫過比較詳細的心跳檢測：
《初探和實現websocket心跳重連》
關於video，總結起來我們要解決的那些問題，或者有些不能解決的問題，歸根到底是乙個問題：相容
。 相容問題又可以分為兩種：標籤事件的相容問題和瀏覽器表現的相容問題。
對，你沒看錯，目前對我來說好像就timeupdate比較靠譜，總之確實相容性很差，這樣會導致對video的可控性變得很低。
所以沒必要投入這種成本。
定製合作這個只是猜測，還不能百分百肯定，如果有誰知道，感謝告知一聲!
本來我們想實現如下圖的樣式：
所以無奈只有放到video下方去。 根據我們的業務需求不同，目前只有這樣，能勉強接受。
在文章最開始我們提到，推流會有一些不可控的情況，主播關閉攝像頭，推送斷流等，客戶端斷網。 這個時候在h5端的表現就是卡住，
var video = document.getelementbyid('video');
video.pause();
video.play();
如何檢查當前是卡住的狀態呢？這裡就用到我開始說的比較可靠的timeupdate事件。
這樣確實有點影響體驗，但是目前無解。
如果是全屏那麼就看不到提示，不過使用者這個時候可能會關閉全屏，返回到頁面上，這樣仍然可以看到提示。
以上就是我所遇到的h5直播開發裡，比較核心的地方。 開發過程中有很多地方，需要用一些比較特別的方法去處理或者妥協， 這一點對於下游的我們也是無可奈何，解決問題的過程中，還是很有樂趣的。這一點對於下游的我們也是無可奈何，過程中，還是很有樂趣的，雖然最終效果並不是很好，但從指縫中，爭取到的結果，很可貴。
**於
h5直播開發之旅總結
關於直播，有很多相關技術文章，這裡不多說。作為前端，我們比較關心我們所需要的。直播的大致流程 但實際我們需要處理一些不可控的情況，這是非常麻煩的。比如說，直播方網路不好，直播方關閉了攝像頭，這些情況都會導致推流斷掉，在文章後面，我們詳細說這一塊。目前我們先考慮直播的三種狀態 直播前，直播中，結束。針...
h5直播開發之旅總結
直播的大致流程 目前我們先考慮直播的三種狀態 直播前，直播中，結束。針對每個狀態我們肯定會有不同的顯示，這三種狀態可以是三個頁面，相互切換，或者乙個頁面，控制頁面相關隱藏和顯示。可是我們怎麼知道，當前主播已經切換成某種狀態了呢？通過輪詢嗎？當然不是，輪詢肯定是可以實現的。不過我們用websocket...
h5直播開發之旅總結
直播的大致流程 目前我們先考慮直播的三種狀態 直播前，直播中，結束。針對每個狀態我們肯定會有不同的顯示，這三種狀態可以是三個頁面，相互切換，或者乙個頁面，控制頁面相關隱藏和顯示。可是我們怎麼知道，當前主播已經切換成某種狀態了呢？通過輪詢嗎？當然不是，輪詢肯定是可以實現的。不過我們用websocket...