iOS 直播類APP開發流程解析

1 . 音視頻處理的一般流程：

數據採集→數據編碼→數據傳輸(流媒體伺服器) →解碼數據→播放顯示
1、數據採集：
攝像機及拾音器收集視頻及音頻數據，此時得到的為原始數據
涉及技術或協議：
攝像機：CCD、CMOS
拾音器：聲電轉換裝置（咪頭）、音頻放大電路
2、數據編碼：
使用相關硬體或軟體對音視頻原始數據進行編碼處理（數字化）及加工（如音視頻混合、打包封裝等），得到可用的音視頻數據
涉及技術或協議：
編碼方式：CBR、VBR
編碼格式
視頻：H.265、H.264、MPEG-4等，封裝容器有TS、MKV、AVI、MP4等
音頻：G.711μ、AAC、Opus等，封裝有MP3、OGG、AAC等
3、數據傳輸：
將編碼完成後的音視頻數據進行傳輸，早期的音視頻通過同軸電纜之類的線纜進行傳輸，IP網路發展後，使用IP網路優傳輸
涉及技術或協議：
傳輸協議：RTP與RTCP、RTSP、RTMP、HTTP、HLS（HTTP Live Streaming）等
控制信令：SIP和SDP、SNMP等
4、解碼數據：
使用相關硬體或軟體對接收到的編碼後的音視頻數據進行解碼，得到可以直接顯示的圖像/聲音
涉及技術或協議：
一般對應的編碼器都會帶有相應的解碼器，也有一些第三方解碼插件等
5、播放顯示：
在顯示器（電視、監視屏等）或揚聲器（耳機、喇叭等）里，顯示相應的圖像畫面或聲音
涉及技術或協議：
顯示器、揚聲器、3D眼鏡等

（二） 視頻推流與視頻拉流的工作過程解析：

1.視頻推流端

推流，就是將採集到的音頻，視頻數據通過流媒體協議發送到流媒體伺服器。

一、選擇流媒體協議

現在直播應用，採用RTMP協議居多，也有部分使用HLS協議。

採用RTMP協議，就要看下它與流媒體伺服器交互的過程，RTMP協議的預設埠是1935，採用TCP協議。並且需要瞭解FLV的封裝格式。

採用HLS協議，因為涉及到切片，延時會比較大，需要瞭解TS流。

二、採集音視頻數據

做直播，數據的來源不可缺少，就是採集攝像頭，麥克風的數據。

iOS平臺上採集音視頻數據，需要使用AVFoundation.Framework框架，從captureSession會話的回調中獲取音頻，視頻數據。

三、硬編碼，軟編碼音視頻數據

軟編碼就是利用CPU資源來壓縮音視頻數據，硬編碼與之相反。

軟編碼的話，現在廣泛採用FFmpeg庫結合編碼庫來實現，FFmpeg+X624來編碼視頻數據YUV/RGB輸出H264數據，
FFmpeg+fdk_aac來編碼音頻數據PCM輸出AAC數據。

四、根據所選流媒體協議封包音視頻數據

將音頻，視頻打包成packet。

五、與伺服器交互發送封包數據

根據所選流媒體協議，發送相應指令連接伺服器，連接伺服器成功後，就可以發送packet數據了。

Part 2. 拉流端

拉流，就是從流媒體伺服器獲取音頻，視頻數據。

一、解析協議

播放器端根據URL解析所用的流媒體協議（RTMP，HLS）。

二、解封裝

解封裝，就是demux的過程，從容器格式（FLV，TS）中，分離出音視頻數據。

三、解碼

解碼，就是把獲取到的數據解壓縮，恢覆成原始數據。解碼就是將H264變成YUV，AAC變成PCM。

解碼可以使用軟解碼，硬解碼。

軟解碼就是利用CPU資源去解壓縮數據，採用的方式是FFmpeg解碼。

硬解碼，對於iOS平臺來說，可以使用VideoToolbox.Framework（該框架只能在iOS 8.0及以上系統使用）
硬解碼視頻數據。Android平臺上，可以使用MediaCodec來硬解碼視頻數據。

四、渲染數據

採用OpenGL渲染YUV數據，呈現視頻畫面。將PCM送入設備的硬體資源播放，產生聲音。

iOS播放流式音頻，使用Audio Queue 的方式，即，利用AudioToolbox.Framework 框架。

三： iOS開發之iOS直播平臺有用的第三方資源共用：

   4. 直播相關SDK

   5. 直播相關開源庫

       1. BeautifyFaceDemo 基於GPUImage的圖片處理，做美顏方面可以參考一下

       2.   lf.swift 開源RTMP Swift版的，可以學習一下！好像作者是日本的，或者是在日本工作的，寫了不少日文！

       3.  PLPlayerKit 一個不依賴FFmpeg的播放器，支持RTMP

       4.  HLS-Demo   https://github.com/yangchao0033/HLS-Demo  HLS播放demo

       5. SmarterStreaming  https://github.com/daniulive/SmarterStreaming  直播SDK（支持私有協議和RTMP推流，如windows推流/android推流/iOS推流/windows播放器/android播放器/iOS播放器）

四： iOS開發之 iOS 直播平臺 常見的視頻直播相關協議詳解

1、    RTMP(Real Time Messaging Protocol，實時消息傳送協議)

RTMP是Adobe Systems公司為Flash播放器和伺服器之間音頻、視頻和數據傳輸開發的開放協議。它有三種變種：

1）、工作在TCP之上的明文協議，使用埠1935；

2）、RTMPT封裝在HTTP請求之中，可穿越防火牆；

3）、RTMPS類似RTMPT，但使用的是HTTPS連接；

RTMP協議是被Flash用於對象、視頻、音頻的傳輸。這個協議建立在TCP協議或者輪詢HTTP協議之上。RTMP協議就像一個用來裝數據包的容器，這些數據既可以是AMF格式的數據，也可以是FLV中的視音頻數據。一個單一的連接可以通過不同的通道傳輸多路網路流，這些通道中的包都是按照固定大小的包傳輸的。

2、RTSP(Real Time Streaming Protocol，實時流傳輸協議)

RTSP定義了一對多應用程式如何有效地通過IP網路傳送多媒體數據。RTSP提供了一個可擴展框架，數據源可以包括實時數據與已有的存儲的數據。該協議目的在於控制多個數據發送連接，為選擇發送通道如UDP、組播UDP與TCP提供途徑，併為選擇基於RTP上發送機制提供方法。

RTSP語法和運作跟HTTP/1.1類似，但並不特別強調時間同步，所以比較能容忍網路延遲。代理伺服器的緩存功能也同樣適用於RTSP，並且因為RTSP具有重新導向功能，可根據實際負載情況來切換提供服務的伺服器，以避免過大的負載集中於同一伺服器而造成延遲。

3、RTP(Real-time Transport Protocol，實時傳輸協議)

RTP是針對多媒體數據流的一種傳輸層協議，詳細說明瞭在互聯網上傳遞音頻和視頻的標準數據包格式。RTP協議常用於流媒體系統（配合RTCP協議），視頻會議和一鍵通系統（配合H.323或SIP），使它成為IP電話產業的技術基礎。

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

RTP 並不保證傳送或防止無序傳送，也不確定底層網路的可靠性，只管發送，不管傳輸是否丟包，也不管接收方是否有收到包。RTP 實行有序傳送，RTP中的序列號允許接收方重組發送方的包序列，同時序列號也能用於決定適當的包位置，如在視頻解碼中，就不需要順序解碼。

4、RTCP(Real-time Transport Control Protocol，實時傳輸控制協議）

RTCP是RTP的配套協議，為RTP媒體流提供通道外的控制。RTCP和RTP一起協作將多媒體數據打包和發送，定期在多媒體流會話參與者之間傳輸控制數據。

RTCP的主要功能是為RTP所提供的服務質量（QoS）提供反饋，收集相關媒體連接的統計信息，例如傳輸位元組數，傳輸分組數，丟失分組數，單向和雙向網路延遲等等。網路應用程式可以利用RTCP所提供的信息來提高服務質量，比如限制流量或改用壓縮比小的編解碼器。