（一） 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。
五、與服務器交互發送封包數據
根據所選流媒體協議，發送相應指令連接服務器，連接服務器成功後，就可以發送packe
t數據了。
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協議或者輪詢H
TTP協議之上。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所提供的信息來提高服務質量，比如限制流量或改用壓縮比小的
編解碼器。