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