1. 程式人生 > >如何快速的開發一個完整的iOS直播app(原理篇)

如何快速的開發一個完整的iOS直播app(原理篇)

原文連結http://www.cocoachina.com/design/20160831/17444.html

前言

大半年沒寫部落格了,但我一直關注著網際網路的動向,最近會研究很多東西,並分享,今年移動直播行業的興起,誕生了一大批網紅,甚至明星也開始直播了,因此不得不跟上時代的步伐,由於第一次接觸的原因,因此花了很多時間瞭解直播,整理了直播的原理,當前只是原理篇,後續會持續釋出實戰篇,教你從零開始搭建一個完整的iOS直播app,希望能幫助到更多的人更快的瞭解直播。
如果喜歡我的文章,可以關注我微博:吖了個崢,也可以來小碼哥,瞭解下我們的iOS培訓課程。後續還會更新更多內容,有任何問題,歡迎簡書留言

崢吖。。。

一、個人見解(直播難與易)

直播難:個人認為要想把直播從零開始做出來,絕對是牛逼中的牛逼,大牛中的大牛,因為直播中運用到的技術難點非常之多,視訊/音訊處理,圖形處理,視訊/音訊壓縮,CDN分發,即時通訊等技術,每一個技術都夠你學幾年的。

直播易:已經有各個領域的大牛,封裝好了許多牛逼的框架,我們只需要用別人寫好的框架,就能快速的搭建一個直播app,也就是傳說中的站在大牛肩膀上程式設計。

二、瞭解直播

熱門直播產品

映客,鬥魚,熊貓,虎牙,花椒等等

直播效果圖

1.jpeg

1.一個完整直播app功能(來自落影loyinglin分享)

  • 1、聊天

    • 私聊、聊天室、點亮、推送、黑名單等;

  • 2、禮物

    • 普通禮物、豪華禮物、紅包、排行榜、第三方充值、內購、禮物動態更新、提現等;

  • 3、直播列表

    • 關注、熱門、最新、分類直播使用者列表等;

  • 4、自己直播

    • 錄製、推流、解碼、播放、美顏、心跳、後臺切換、主播對管理員操作、管理員對使用者等;

  • 5、房間邏輯

    • 建立房間、進入房間、退出房間、關閉房間、切換房間、房間管理員設定、房間使用者列表等;

  • 6、使用者邏輯

    • 普通登陸、第三方登陸、註冊、搜尋、修改個人資訊、關注列表、粉絲列表、忘記密碼、檢視個人資訊、收入榜、關注和取關、檢索等;

  • 7、觀看直播

    • 聊天資訊、滾屏彈幕、禮物顯示、載入介面等;

  • 8、統計

    • APP業務統計、第三方統計等;

  • 9、超管

    • 禁播、隱藏、稽核等;

2.一個完整直播app原理

直播原理:把主播錄製的視訊,推送到伺服器,在由伺服器分發給觀眾觀看。

直播環節:推流端(採集、美顏處理、編碼、推流)、服務端處理(轉碼、錄製、截圖、鑑黃)、播放器(拉流、解碼、渲染)、互動系統(聊天室、禮物系統、贊)

3.一個完整直播app實現流程

1.採集、2.濾鏡處理、3.編碼、4.推流、5.CDN分發、6.拉流、7.解碼、8.播放、9.聊天互動

2.png

4.一個完整直播app架構

http://cc.cocimg.com/api/uploads/20160830/1472556797148804.png

3.png

5.一個完整直播app技術點

http://cc.cocimg.com/api/uploads/20160830/1472556806743014.jpeg

4.jpeg

三、瞭解流媒體(直播需要用到流媒體)

  • 流媒體開發:網路層(socket或st)負責傳輸,協議層(rtmp或hls)負責網路打包,封裝層(flv、ts)負責編解碼資料的封裝,編碼層(h.264和aac)負責影象,音訊壓縮。

  • 幀:每幀代表一幅靜止的影象

  • GOP:(Group of Pictures)畫面組,一個GOP就是一組連續的畫面,每個畫面都是一幀,一個GOP就是很多幀的集合

    • 直播的資料,其實是一組圖片,包括I幀、P幀、B幀,當用戶第一次觀看的時候,會尋找I幀,而播放器會到伺服器尋找到最近的I幀反饋給使用者。因此,GOP Cache增加了端到端延遲,因為它必須要拿到最近的I幀

    • GOP Cache的長度越長,畫面質量越好

  • 位元速率:圖片進行壓縮後每秒顯示的資料量。

  • 幀率:每秒顯示的圖片數。影響畫面流暢度,與畫面流暢度成正比:幀率越大,畫面越流暢;幀率越小,畫面越有跳動感。

    • 由於人類眼睛的特殊生理結構,如果所看畫面之幀率高於16的時候,就會認為是連貫的,此現象稱之為視覺暫留。並且當幀速達到一定數值後,再增長的話,人眼也不容易察覺到有明顯的流暢度提升了。

  • 解析度:(矩形)圖片的長度和寬度,即圖片的尺寸

  • 壓縮前的每秒資料量:幀率X解析度(單位應該是若干個位元組)

  • 壓縮比:壓縮前的每秒資料量/位元速率 (對於同一個視訊源並採用同一種視訊編碼演算法,則:壓縮比越高,畫面質量越差。) 

  • 視訊檔案格式:檔案的字尾,比如.wmv,.mov,.mp4,.mp3,.avi,

    • 主要用處,根據檔案格式,系統會自動判斷用什麼軟體開啟,
      注意: 隨意修改檔案格式,對檔案的本身不會造成太大的影響,比如把avi改成mp4,檔案還是avi.

  • 視訊封裝格式:一種儲存視訊資訊的容器,流式封裝可以有TS、FLV等,索引式的封裝有MP4,MOV,AVI等,

    • 主要作用:一個視訊檔案往往會包含影象和音訊,還有一些配置資訊(如影象和音訊的關聯,如何解碼它們等):這些內容需要按照一定的規則組織、封裝起來.

    • 注意:會發現封裝格式跟檔案格式一樣,因為一般視訊檔案格式的字尾名即採用相應的視訊封裝格式的名稱,所以視訊檔案格式就是視訊封裝格式。

  • 視訊封裝格式和視訊壓縮編碼標準:就好像專案工程和程式語言,封裝格式就是一個專案的工程,視訊編碼方式就是程式語言,一個專案工程可以用不同語言開發。

四、直播基礎知識介紹:

1.採集視訊、音訊

*    1.1 採集視訊、音訊編碼框架 *

  • AVFoundation:AVFoundation是用來播放和建立實時的視聽媒體資料的框架,同時提供Objective-C介面來操作這些視聽資料,比如編輯,旋轉,重編碼

*    1.2 視訊、音訊硬體裝置 *

  • CCD:影象感測器: 用於影象採集和處理的過程,把影象轉換成電訊號。

  • 拾音器:聲音感測器: 用於聲音採集和處理的過程,把聲音轉換成電訊號。

  • 音訊取樣資料:一般都是PCM格式

  • 視訊取樣資料: 一般都是YUV,或RGB格式,採集到的原始音視訊的體積是非常大的,需要經過壓縮技術處理來提高傳輸效率

2.視訊處理(美顏,水印)

  • 視訊處理原理:因為視訊最終也是通過GPU,一幀一幀渲染到螢幕上的,所以我們可以利用OpenGL ES,對視訊幀進行各種加工,從而視訊各種不同的效果,就好像一個水龍頭流出的水,經過若干節管道,然後流向不同的目標

    • 現在的各種美顏和視訊新增特效的app都是利用GPUImage這個框架實現的,.

* 視訊處理框架 *

  • GPUImage : GPUImage是一個基於OpenGL ES的一個強大的影象/視訊處理框架,封裝好了各種濾鏡同時也可以編寫自定義的濾鏡,其本身內建了多達120多種常見的濾鏡效果。

  • OpenGL:OpenGL(全寫Open Graphics Library)是個定義了一個跨程式語言、跨平臺的程式設計介面的規格,它用於三維圖象(二維的亦可)。OpenGL是個專業的圖形程式介面,是一個功能強大,呼叫方便的底層圖形庫。

  • OpenGL ES:OpenGL ES (OpenGL for Embedded Systems) 是 OpenGL三維圖形 API 的子集,針對手機、PDA和遊戲主機等嵌入式裝置而設計。

3.視訊編碼解碼

*    3.1 視訊編碼框架 *

  • FFmpeg:是一個跨平臺的開源視訊框架,能實現如視訊編碼,解碼,轉碼,串流,播放等豐富的功能。其支援的視訊格式以及播放協議非常豐富,幾乎包含了所有音視訊編解碼、封裝格式以及播放協議。

    • -Libswresample:可以對音訊進行重取樣,rematrixing 以及轉換取樣格式等操 作。

    • -Libavcodec:提供了一個通用的編解碼框架,包含了許多視訊,音訊,字幕流 等編碼/解碼器。

    • -Libavformat:用於對視訊進行封裝/解封裝。

    • -Libavutil:包含一些共用的函式,如隨機數生成,資料結構,數學運算等。

    • -Libpostproc:用於進行視訊的一些後期處理。

    • -Libswscale:用於視訊影象縮放,顏色空間轉換等。

    • -Libavfilter:提供濾鏡功能。

  • X264:把視訊原資料YUV編碼壓縮成H.264格式

  • VideoToolbox:蘋果自帶的視訊硬解碼和硬編碼API,但是在iOS8之後才開放。

  • AudioToolbox:蘋果自帶的音訊硬解碼和硬編碼API

*    3.2 視訊編碼技術 *

  • 視訊壓縮編碼標準:對視訊進行壓縮(視訊編碼)或者解壓縮(視訊解碼)的編碼技術,比如MPEG,H.264,這些視訊編碼技術是壓縮編碼視訊的

    • 主要作用:是將視訊畫素資料壓縮成為視訊碼流,從而降低視訊的資料量。如果視訊不經過壓縮編碼的話,體積通常是非常大的,一部電影可能就要上百G的空間。

    • 注意:最影響視訊質量的是其視訊編碼資料和音訊編碼資料,跟封裝格式沒有多大關係

  • MPEG:一種視訊壓縮方式,它採用了幀間壓縮,僅儲存連續幀之間有差別的地方 ,從而達到較大的壓縮比

  • H.264/AVC:一種視訊壓縮方式,採用事先預測和與MPEG中的P-B幀一樣的幀預測方法壓縮,它可以根據需要產生適合網路情況傳輸的視訊流,還有更高的壓縮比,有更好的圖象質量

    • 注意1:如果是從單個畫面清晰度比較,MPEG4有優勢;從動作連貫性上的清晰度,H.264有優勢

    • 注意2:由於264的演算法更加複雜,程式實現煩瑣,執行它需要更多的處理器和記憶體資源。因此,執行264對系統要求是比較高的。

    • 注意3:由於264的實現更加靈活,它把一些實現留給了廠商自己去實現,雖然這樣給實現帶來了很多好處,但是不同產品之間互通成了很大的問題,造成了通過A公司的編碼器編出的資料,必須通過A公司的解碼器去解這樣尷尬的事情

  • H.265/HEVC:一種視訊壓縮方式,基於H.264,保留原來的某些技術,同時對一些相關的技術加以改進,以改善碼流、編碼質量、延時和演算法複雜度之間的關係,達到最優化設定。

    • H.265 是一種更為高效的編碼標準,能夠在同等畫質效果下將內容的體積壓縮得更小,傳輸時更快更省頻寬

    • I幀:(關鍵幀)保留一副完整的畫面,解碼時只需要本幀資料就可以完成(因為包含完整畫面)

  • P幀:(差別幀)保留這一幀跟之前幀的差別,解碼時需要用之前快取的畫面疊加上本幀定義的差別,生成最終畫面。(P幀沒有完整畫面資料,只有與前一幀的畫面差別的資料)

  • B幀:(雙向差別幀)保留的是本幀與前後幀的差別,解碼B幀,不僅要取得之前的快取畫面,還要解碼之後的畫面,通過前後畫面的與本幀資料的疊加取得最終的畫面。B幀壓縮率高,但是解碼時CPU會比較累

  • 幀內(Intraframe)壓縮:當壓縮一幀影象時,僅考慮本幀的資料而不考慮相鄰幀之間的冗餘資訊,幀內一般採用有失真壓縮演算法

  • 幀間(Interframe)壓縮:時間壓縮(Temporal compression),它通過比較時間軸上不同幀之間的資料進行壓縮。幀間壓縮一般是無損的

  • muxing(合成):將視訊流、音訊流甚至是字幕流封裝到一個檔案中(容器格式(FLV,TS)),作為一個訊號進行傳輸。

*    3.3 音訊編碼技術 *

  • AAC,mp3:這些屬於音訊編碼技術,壓縮音訊用

*    3.4位元速率控制 *

  • 多位元速率:觀眾所處的網路情況是非常複雜的,有可能是WiFi,有可能4G、3G、甚至2G,那麼怎麼滿足多方需求呢?多搞幾條線路,根據當前網路環境自定義位元速率。

    • 列如:常常看見視訊播放軟體中的1024,720,高清,標清,流暢等,指的就是各種位元速率。

*    3.5 視訊封裝格式 *

  • TS : 一種流媒體封裝格式,流媒體封裝有一個好處,就是不需要載入索引再播放,大大減少了首次載入的延遲,如果片子比較長,mp4檔案的索引相當大,影響使用者體驗

    • 為什麼要用TS:這是因為兩個TS片段可以無縫拼接,播放器能連續播放

  • FLV: 一種流媒體封裝格式,由於它形成的檔案極小、載入速度極快,使得網路觀看視訊檔案成為可能,因此FLV格式成為了當今主流視訊格式

4.推流

*    4.1 資料傳輸框架 *

librtmp:用來傳輸RTMP協議格式的資料

*    4.2 流媒體資料傳輸協議 *

  • RTMP:實時訊息傳輸協議,Adobe Systems公司為Flash播放器和伺服器之間音訊、視訊和資料傳輸開發的開放協議,因為是開放協議所以都可以使用了。

    • RTMP協議用於物件、視訊、音訊的傳輸。

    • 這個協議建立在TCP協議或者輪詢HTTP協議之上。

    • RTMP協議就像一個用來裝資料包的容器,這些資料可以是FLV中的視音訊資料。一個單一的連線可以通過不同的通道傳輸多路網路流,這些通道中的包都是按照固定大小的包傳輸的

    chunk:訊息包

5.流媒體伺服器

*    5.1常用伺服器 *

  • SRS:一款國人開發的優秀開源流媒體伺服器系統

  • BMS:也是一款流媒體伺服器系統,但不開源,是SRS的商業版,比SRS功能更多

  • nginx:免費開源web伺服器,常用來配置流媒體伺服器。

*    5.2資料分發 *

  • CDN:(Content Delivery Network),即內容分發網路,將網站的內容釋出到最接近使用者的網路”邊緣”,使使用者可以就近取得所需的內容,解決 Internet網路擁擠的狀況,提高使用者訪問網站的響應速度.

    • CDN:代理伺服器,相當於一箇中介。

    • CDN工作原理:比如請求流媒體資料

      • 1.上傳流媒體資料到伺服器(源站)

      • 2.源站儲存流媒體資料

      • 3.客戶端播放流媒體,向CDN請求編碼後的流媒體資料

      • 4.CDN的伺服器響應請求,若節點上沒有該流媒體資料存在,則向源站繼續請求流媒體資料;若節點上已經快取了該視訊檔案,則跳到第6步。

      • 5.源站響應CDN的請求,將流媒體分發到相應的CDN節點上

      • 6.CDN將流媒體資料傳送到客戶端

  • 回源:當有使用者訪問某一個URL的時候,如果被解析到的那個CDN節點沒有快取響應的內容,或者是快取已經到期,就會回源站去獲取搜尋。如果沒有人訪問,那麼CDN節點不會主動去源站拿.

  • 頻寬:在固定的時間可傳輸的資料總量,

    • 比如64位、800MHz的前端匯流排,它的資料傳輸率就等於64bit×800MHz÷8(Byte)=6.4GB/s

  • 負載均衡: 由多臺伺服器以對稱的方式組成一個伺服器集合,每臺伺服器都具有等價的地位,都可以單獨對外提供服務而無須其他伺服器的輔助.

    • 通過某種負載分擔技術,將外部發送來的請求均勻分配到對稱結構中的某一臺伺服器上,而接收到請求的伺服器獨立地迴應客戶的請求。

    • 均衡負載能夠平均分配客戶請求到伺服器列陣,籍此提供快速獲取重要資料,解決大量併發訪問服務問題。

    • 這種群集技術可以用最少的投資獲得接近於大型主機的效能。

  • QoS(頻寬管理):限制每一個組群的頻寬,讓有限的頻寬發揮最大的效用

6.拉流

  • 直播協議選擇:

    • 即時性要求較高或有互動需求的可以採用RTMP,RTSP

    • 對於有回放或跨平臺需求的,推薦使用HLS

  • 直播協議對比    :

5.png

  • HLS:由Apple公司定義的用於實時流傳輸的協議,HLS基於HTTP協議實現,傳輸內容包括兩部分,一是M3U8描述檔案,二是TS媒體檔案。可實現流媒體的直播和點播,主要應用在iOS系統

    • HLS是以點播的技術方式來實現直播

    • HLS是自適應位元速率流播,客戶端會根據網路狀況自動選擇不同位元速率的視訊流,條件允許的情況下使用高位元速率,網路繁忙的時候使用低位元速率,並且自動在二者間隨意切
      換。這對移動裝置網路狀況不穩定的情況下保障流暢播放非常有幫助。

    • 實現方法是伺服器端提供多位元速率視訊流,並且在列表檔案中註明,播放器根據播放進度和下載速度自動調整。

  • HLS與RTMP對比:HLS主要是延時比較大,RTMP主要優勢在於延時低

    • HLS協議的小切片方式會生成大量的檔案,儲存或處理這些檔案會造成大量資源浪費

    • 相比使用RTSP協議的好處在於,一旦切分完成,之後的分發過程完全不需要額外使用任何專門軟體,普通的網路伺服器即可,大大降低了CDN邊緣伺服器的配置要求,可以使用任何現成的CDN,而一般伺服器很少支援RTSP。

  • HTTP-FLV:基於HTTP協議流式的傳輸媒體內容。

    • 相對於RTMP,HTTP更簡單和廣為人知,內容延遲同樣可以做到1~3秒,開啟速度更快,因為HTTP本身沒有複雜的狀態互動。所以從延遲角度來看,HTTP-FLV要優於RTMP。

  • RTSP:實時流傳輸協議,定義了一對多應用程式如何有效地通過IP網路傳送多媒體資料.

  • RTP:實時傳輸協議,RTP是建立在UDP協議上的,常與RTCP一起使用,其本身並沒有提供按時傳送機制或其它服務質量(QoS)保證,它依賴於低層服務去實現這一過程。

  • RTCP:RTP的配套協議,主要功能是為RTP所提供的服務質量(QoS)提供反饋,收集相關媒體連線的統計資訊,例如傳輸位元組數,傳輸分組數,丟失分組數,單向和雙向網路延遲等等。

7.解碼

*    7.1 解封裝 *

  • demuxing(分離):從視訊流、音訊流,字幕流合成的檔案(容器格式(FLV,TS))中, 分解出視訊、音訊或字幕,各自進行解碼。

*    7.2 音訊編碼框架 *

  • fdk_aac:音訊編碼解碼框架,PCM音訊資料和AAC音訊資料互轉

*    7.3 解碼介紹 *

  • 硬解碼:用GPU來解碼,減少CPU運算

    •  優點:播放流暢、低功耗,解碼速度快,
            *    缺點:相容不好

  • 軟解碼:用CPU來解碼

    • 優點:相容好
            *    缺點:加大CPU負擔,耗電增加、沒有硬解碼流暢,解碼速度相對慢

8.播放

  • ijkplayer:一個基於FFmpeg的開源Android/iOS視訊播放器

    • API易於整合;

    • 編譯配置可裁剪,方便控制安裝包大小;

    • 支援硬體加速解碼,更加省電

    • 簡單易用,指定拉流URL,自動解碼播放.

9.聊天互動

  • IM:(InstantMessaging)即時通訊:是一個實時通訊系統,允許兩人或多人使用網路實時的傳遞文字訊息、檔案、語音與視訊交流.

    • IM在直播系統中的主要作用是實現觀眾與主播、觀眾與觀眾之間的文字互動.
      *    第三方SDK *

  • 騰訊雲:騰訊提供的即時通訊SDK,可作為直播的聊天室

  • 融雲:一個比較常用的即時通訊SDK,可作為直播的聊天室

五、如何快速的開發一個完整的iOS直播app

1、利用第三方直播SDK快速的開發

七牛雲:七牛直播雲是專為直播平臺打造的全球化直播流服務和一站式實現SDK端到端直播場景的企業級直播雲服務平臺.

*    熊貓TV,龍珠TV等直播平臺都是用的七牛雲

網易視訊雲:基於專業的跨平臺視訊編解碼技術和大規模視訊內容分發網路,提供穩定流暢、低延時、高併發的實時音視訊服務,可將視訊直播無縫對接到自身App.

2、第三方SDK公司為什麼要提供SDK給我們?

  • 希望把我們的產品和它綁在一條船上,更加的依賴它。

  • 技術生錢,幫養一大批牛B的程式設計師

3、直播功能:自研還是使用第三方直播SDK開發?

第三方SDK開發: 對於一個初創團隊來講,自研直播不管在技術門檻、CDN、頻寬上都是有很大的門檻的,而且需要耗費大量的時間才能做出成品,不利於拉投資。

自研:公司直播平臺大,從長遠看,自研可以節省成本,技術成面比直接用SDK可控多了。

4.第三方SDK好處

  • 降低成本

    • 使用好的第三方企業服務,將不用再花高價請獵頭去挖昂貴的大牛,也不用去安撫大牛們個性化的脾氣

  • 提升效率

    • 第三方服務的專注與程式碼整合所帶來的方便,所花費的時間可能僅僅是1-2個小時,節約近99%的時間,足夠換取更多的時間去和競爭對手鬥智鬥勇,增加更大的成功可能性

  • 降低風險

    • 藉助專業的第三方服務,由於它的快速、專業、穩定等特點,能夠極大地加強產品的競爭能力(優質服務、研發速度等),縮短試錯時間,必將是創業中保命的手段之一

  • 專業的事,找專業的人來做

    • 第三方服務最少是10-20人的團隊專注地解決同一個問題,做同一件事情。第三方服務所帶來的支援效果,絕不是通過1-2個人處理所能對比的,難道不是嗎