寫這篇文章首先是想給自己一個總結、整理，還有就是給那些 沒有特別明白直播是怎么回事的人一點 思路
最近公司想要做pc端直播，作為一個自認為很菜的前端實在是不知從何下手，所以只能用國人最愛的百度，搜索了很多資料、文章，得出的第一個結論就是 直播很燒錢，但是燒不燒錢 這個我可能管不了，我也沒有辦法管，所以只能繼續探索我的直播之路，根據我的查找有了一些結論，當然這些結論可能多事別人說過的 ，我拿來用一下，總結一下，還望各位見諒，以下有一些都是我自己的見解。
首先直播分為兩個端，主播端和看直播的一端（這是我自己的理解）
主播端肯定是錄視頻，將錄的視頻傳給后台
看直播的一端 是從后台將視頻拉取過來 播放 淡然 還有什么 評論、送禮物等等。
所以 總結一下 官方的說法就是 視頻直播可以分為 采集、前處理、編碼、傳輸、解碼、渲染 這幾個環節。
采集---一般都是移動端，IOS比較簡單，機型比較同意，Android則相對復雜，因為有很多機型，需要做適配，PC最麻煩 ，各種不一樣的攝像頭，麥克風，比較凌亂 不好處理。
前處理 ---就是美顏什么的 ，得讓主播好看，好多大牛都說美顏算法要用到GPU編程（這個還是不太了解）
編碼 --- 應該是將錄的視頻做一下處理（還不太了解，自我理解是這樣）
傳輸 --- 這個很貴 涉及到流量什么的
解碼 --- 應該是觀看直播時，將視頻拉取過來要做一些處理（還不太了解，自我理解是這樣）
渲染 --- 播放視頻時 音畫同步
直播包括 推流和拉流
目前web上主流的視頻直播方案有HLS和RTMP，移動端主要以HLS為主（HLS存在延遲性問題，也可以借助video.jscaiyong RTMP）,PC端主要用RTMP 為主 實時性較好（這段話是從別人的博客里看到的 但是忘記是誰了 作者看到 見諒）
下面說一下 推送協議
1.RTMP（Real Time Messaging Protocol）實時消息傳輸協議
該協議基於TCP
優點：
CDN支持良好，主流的CDN廠商都支持
協議簡單，在各平台上實現容易
缺點：
基於TCP，傳輸成本高，在弱網環境丟包率高的情況下問題顯著
不支持瀏覽器**
Adobe私有協議，Adobe已經不再更新
2.WebRTC 名稱源自網頁即時通信（英語：Web Real-Time Communication）的縮寫
是一個支持網頁瀏覽器進行實時語音對話或視頻對話的API。它於2011年6月1日開源並在Google、Mozilla、Opera支持下被納入萬維網聯盟的W3C推薦標准。
優點
W3C標准，主流瀏覽器支持程度高
Google在背后支撐，並在各平台有參考實現
底層基於SRTP和UDP，弱網情況優化空間大
可以實現點對點通信，通信雙方延時低
缺點
ICE，STUN，TURN傳統CDN沒有類似的服務提供
3.基於UDP的私有協議
有些直播應用會使用UDP做為底層協議開發自己的私有協議，因為UDP在弱網環境下的優勢通過一些定制化的調優可以達到比較好的弱網優化效果，但同樣因為是私有協議也勢必有現實問題：
優點
更多空間進行定制化優化
缺點
開發成本高
CDN不友好，需要自建CDN或者和CDN達成協議
獨立作戰，無法和社區一起演進
以上就是我在做直播准備時 找到資料，希望能對有些人有幫助，另外再次強調有一些是別人的話 借用一下 忘見諒