怎麼創建直播平台

現在直播應用非常火爆，它以生動直觀的方式向用戶傳達最真實的現場信息，受到廣大用戶的普遍歡迎。小編作為一名技術人員，經常開發各種直播平台，（娛樂直播、遊戲直播、教育直播、財經直播等）下面我把自己積累的一些經驗分享給大家，希望和大家一起交流學習，共同進步。

第一步，移動端視音頻採集

首先，對於手機端的視音頻採集編碼技術，我們有過類似的經驗。考慮到手機的處理能力，我們的技術路線是利用手機自身核心處理器的視頻編碼能力來完成。在Android端調用Mediacodec開發介面來實現，iOS端調用蘋果提供的Core Video框架來實現，編碼格式上我們採用H.264視頻編碼和AAC音頻編碼，通過硬體編碼方式極大地降低了移動終端的CPU負荷與功耗，。在協議的選擇上，我們採用當前主流的RTMP協議由客戶端向伺服器端推送數據。RTMP是Adobe公司制定的一款流傳輸一些，結構比較簡單，自己研究就能搞定，而且這款協議在行業內應用非常廣泛，便於不同產品的集成。

第二步，內容的發布和轉碼

前端設備將直播的視音頻內容採集處理後，首先推送給平台的源站伺服器，我們將源伺服器部署在了北京本地的運營商骨幹節點機房（近距離便於維護）。源伺服器採用多機集群熱備份機制，防止一台源站伺服器宕機後影響整個平台的穩定運行。

源站伺服器連接有專業的磁碟陣列存儲設備，當源站伺服器接收到數據後，首先複製N份轉發給下面的N個二級CDN節點，同時複製一份給轉碼伺服器。轉碼伺服器將接收到的每一個流進行實時的轉碼，主要是將高清碼流轉換一份標清碼流給小屏移動終端，移動終端接收標清小碼流不僅符合自身的小屏解析度需要，同時可以降低對移動端的解碼能力要求，還能有效節省帶寬成本。

第三步，流媒體發布

流媒體發布這個環節對於整個平台來說也是至關重要，因為最終面向終端用戶提供服務的是分布在全網的流媒體伺服器，流媒體伺服器的穩定性以及性能優劣決定著終端用戶的體驗效果和平台的運營成本。根據之前做IPTV的經驗，我們在這個項目中選擇的技術路線還是自行開發，當然還是基於之前做IPTV流媒體伺服器的基礎來做，核心技術點又有如下的改進：

1. 流媒體伺服器還是採用C語言實現，保障運行效率最高；

2. 將之前的多進程模型改成非同步IO模型，提高伺服器的並發處理性能；

3. 在協議層上增加對RTMP、HLS協議的支持；

4.引入hadoop這一分散式架構，便於大規模分散式部署、調度和容錯；

通過這些改進，流媒體伺服器的整體性能又會有一個質的飛躍。

第四步，CDN內容分發

這方面是我的業務特長所在，與我之前做IPTV平台的技術路線相同，主要是對流媒體數據在全網範圍內的多個節點之間進行快速的分發，從而提高終端用戶的體驗效果。

在協議的選擇上，我們根據直播和點播應用的特點，支持RTMP協議、HTTP協議、UDP協議這三個類型。

節點伺服器的建設方面，我們根據國內互聯網的整體布局，採用中心節點->各省級節點->地市級節點 三級架構模式，把主要的用戶流量首先引導到第三級節點，然後是第二級節點，之所以這樣設計，主要因為越到中小城市，帶寬價格越低，這樣可以極大地節省後期的運營成本。

第五步，終端播放器開發

在終端的解碼回放部分，我們考慮自行開發PC、Android和iOS三個終端的播放器，由於三種終端採用不同的操作系統平台，因此我們成立了三個開發小組來分別完成，下面講一下技術路線：

PC端：

採用行業內主流的技術路線，基於Adobe的Flash Player做應用層開發，這也是當前最成熟時的技術路線。為了縮短開發周期，我們基於Adobe的OSMF播放器框架來做，開發周期控制在2個月以內比較可行。

Android端：

Android端的播放器開發我們首先考慮到的是終端的解碼性能，因為解碼框架有多個可選，比如FFMPEG、VLC、MediaPlayer API、Exoplayer等，從我們自身的熟悉程度和項目的可控性上考慮，最終決定採用google的Exoplayer做二次開發，開發周期可以控制在2個月以內。

iOS端：

iOS端的播放器也是基於同樣的考慮，我們選擇了蘋果提供的VideoToolbox開發介面，通過它可以直接調用蘋果處理器自帶的硬體解碼功能，這樣可以大大降低設備的功耗，延長電池的續航時間。

以上就是小編怎麼創建播平台的一段經歷和收穫的一點點經驗，記錄下來既是對自己的總結，同時也想與各位創業者和同行一起分享，希望對大家有所幫助。如果您有不同的見解，歡迎諮詢交流!