一、封裝格式
1椭员、因為來源的不同，視頻會有不同的格式津辩，分別用不同的后綴表示拆撼，avi/rmvb/mp4等，這些格式代表的就是封裝格式
2喘沿、封裝格式就是把已經(jīng)壓縮編碼視頻數(shù)據(jù)和音頻數(shù)據(jù)按照一定的格式放到一起闸度，不同的封裝格式之間差距不大，各有優(yōu)劣
3蚜印、封裝格式支持音視頻編碼標(biāo)準(zhǔn)莺禁，有些封裝格式支持的音視頻編碼標(biāo)準(zhǔn)十分廣泛，比如MKV窄赋，而有些封裝格式支持的視音頻編碼標(biāo)準(zhǔn)很少哟冬，屬于落后的封裝格式，比如RMVB忆绰，所以單從封裝格式無法看出某視頻具體使用了什么音視頻編碼標(biāo)準(zhǔn)
二浩峡、視頻播放器播放一個互聯(lián)網(wǎng)上的視頻文件，需要經(jīng)過以下幾個步驟
1错敢、解協(xié)議
1）就是將流媒體協(xié)議的數(shù)據(jù)翰灾，解析為標(biāo)準(zhǔn)的相應(yīng)的封裝格式的數(shù)據(jù)
2）音視頻在網(wǎng)絡(luò)上傳播的時候，常常采用各種流媒體協(xié)議,例如HTTP/RTMP/MMS等等，這些協(xié)議在傳輸數(shù)據(jù)的同時纸淮，也會傳輸一些信令數(shù)據(jù)平斩，這些信令數(shù)據(jù)包括對播放的控制（播放，暫停咽块，停止）绘面，或者對網(wǎng)絡(luò)狀態(tài)的描述等
3）解協(xié)議的過程中會去掉信令數(shù)據(jù)而只保留音頻數(shù)據(jù)，例如侈沪，采用RTMP協(xié)議傳輸?shù)臄?shù)據(jù)揭璃，經(jīng)過解協(xié)議操作后，輸出FLV格式的數(shù)據(jù)
2峭竣、解封裝的作用
將輸入的封裝格式的數(shù)據(jù)塘辅，分離成為音頻流壓縮編碼數(shù)據(jù)和視頻流壓縮編碼數(shù)據(jù)晃虫，例如皆撩，F(xiàn)LV格式的數(shù)據(jù)，經(jīng)過解封裝操作后哲银，輸出H.264編碼的視頻碼流和AAC編碼的音頻碼流
3扛吞、解碼
解碼是整個系統(tǒng)中最重要也是最復(fù)雜的一個環(huán)節(jié)，通過解碼荆责，
壓縮編碼的視頻數(shù)據(jù)輸出成非壓縮的顏色數(shù)據(jù)滥比，例如YUV420P，RGB等等做院，
壓縮編碼的音頻數(shù)據(jù)輸出稱為非壓縮的音頻抽樣數(shù)據(jù)盲泛，例如PCM數(shù)據(jù)
4、音視頻同步
根據(jù)解封裝模塊處理過程中獲取到的參數(shù)信息键耕，同步解碼出來的視頻和音頻數(shù)據(jù)寺滚，并將音頻視頻數(shù)據(jù)送至系統(tǒng)的顯卡和聲卡播放出來
2.直播相關(guān)知識
一、在客戶端上要完成直播視頻的采集及RTMP上推屈雄，主要需要以下幾個步驟：
1村视、音視頻的采集
在音頻的采集上，直接使用AVFoundation.framework的AVCaptureSession即可獲得原始的CMSampleBufferRef格式的音視頻數(shù)據(jù)
2酒奶、對視頻進行H264編碼蚁孔，對音頻進行AAC編碼
使用FFmpeg進行編碼
3、對編碼后的音視頻進行FLV封包
4惋嚎、建立RTMP連接并上推到服務(wù)端
二杠氢、在傳輸直播流媒體過程中的內(nèi)容緩存與傳輸策略優(yōu)化細(xì)節(jié)原理
1、基礎(chǔ)知識：I幀另伍、P幀鼻百、B幀
1）I幀表示關(guān)鍵幀
包含完整畫面，解碼時只需要本幀數(shù)據(jù)就可以完成
2）P幀表示這一幀跟之前的一個關(guān)鍵幀的差別
解碼時需要用之前緩存的畫面疊加上本幀定義的差別，生成最終畫面愕宋，因此也叫作差別幀
3）B幀是雙向差別幀
B幀記錄的是本幀與前后幀的差別玻靡，換言之，要解碼B幀中贝，不僅要取得之前的緩存畫面囤捻，還要解碼之后的畫面，通過前后畫面與本幀數(shù)據(jù)的疊加取得最終的畫面
B幀壓縮率高邻寿，但是編解碼時會比較耗費CPU,而且在直播中可能會增加直播延時蝎土，因此在移動端上一般不適用B幀
2、關(guān)鍵幀緩存策略
1）一個典型的視頻幀序列為IBBPBBPBBP....
2) 對于直播而言绣否，為了減少直播的延時誊涯，通常在編碼時不使用B幀，P幀B幀對于I幀都有直接或者間接的依賴關(guān)系蒜撮，所以播放器要解碼一個視頻幀序列暴构，必須首先解碼出I幀，其后續(xù)的B幀和P幀才能進行解碼
3）服務(wù)端如何進行關(guān)鍵幀的緩存段磨，對直播的延時有非常大的影響取逾，比較好的策略是服務(wù)器端自動判斷關(guān)鍵幀的間隔，按業(yè)務(wù)需求緩存幀序列苹支，保證在緩存中存儲至少兩個或以上的關(guān)鍵幀砾隅，以應(yīng)對低延時、放卡頓债蜜、只能丟包等問題
3晴埂、延遲與卡頓的折中
1、直播的延時與卡頓是分析直播業(yè)務(wù)質(zhì)量的兩個重要指標(biāo)寻定，互動直播的場景對延遲非常敏感儒洛，新聞類體育類直播則更加關(guān)注播放的流暢度
2、延時與卡頓從理論上來說特姐，是一對矛盾的關(guān)系
- 需要更低的延時晶丘，則表明服務(wù)器端和播放段的緩存區(qū)都必須更短，來自網(wǎng)絡(luò)的異常抖動容易引起卡頓
- 需要更流暢的直播體驗唐含，則表明服務(wù)端和播放段都可以有較長的緩沖區(qū)浅浮，以應(yīng)對網(wǎng)絡(luò)的抖動，提供更流暢的直播體驗
3捷枯、對于網(wǎng)絡(luò)條件非常好的用戶滚秩，這兩項是可以同時保證的，這里主要針對網(wǎng)絡(luò)條件不是那么好的用戶淮捆，如何解決延時與卡頓的問題
4郁油、兩種技術(shù)來平衡和優(yōu)化這兩個指標(biāo)
1）服務(wù)端提供靈活的配置策略本股，服務(wù)端對所有連接的網(wǎng)絡(luò)情況進行智能檢測，
當(dāng)網(wǎng)絡(luò)狀況良好時桐腌，在服務(wù)端保證關(guān)鍵幀的情況下拄显，服務(wù)端會縮小該鏈接的緩沖隊列的大小，降低延遲
當(dāng)網(wǎng)絡(luò)環(huán)境差時案站，特別是檢測到抖動較為明顯時躬审，服務(wù)端對該鏈接增加緩沖隊列長度，優(yōu)先保證播放的流暢性
2）丟包策略
對于一個網(wǎng)絡(luò)鏈接很好蟆盐，延時也比較小的連接承边，丟包策略永遠(yuǎn)沒有用武之地.
一般的丟幀策略，就是直接丟棄一個完整的視頻幀序列石挂，這種策略看似簡單博助，但對用戶播放的影響體驗非常大。而應(yīng)該是后臺采用逐步丟幀的策略痹愚，每個視頻幀序列富岳，丟最后的一到兩幀，使得用戶的感知最小里伯，平滑的逐步縮小延時的效果城瞎。
3.RTAM協(xié)議
一渤闷、基本概念
1疾瓮、了解RTMP協(xié)議之前，首先需要了解一下TCP/IP協(xié)議飒箭，尤其了解一下應(yīng)用層的信息
http://www.reibang.com/p/38c86ea9db46
2狼电、RTMP協(xié)議是Adobe公司為Flash播放器和服務(wù)器之間音、視頻及數(shù)據(jù)傳輸開發(fā)的實時消息傳送協(xié)議弦蹂。協(xié)議中肩碟，視頻必須是H264編碼，音頻必須是AAC或MP3編碼凸椿，且多以flv格式封包削祈。
4、RTMP傳輸數(shù)據(jù)原理
1）發(fā)送端首先把媒體數(shù)據(jù)封裝成消息脑漫，然后把消息分割成消息塊髓抑，最后將分割后的消息塊，通過TCP協(xié)議發(fā)送出去
2）接收端在通過TCP協(xié)議收到數(shù)據(jù)后优幸，首先把消息塊重新組合成消息吨拍，然后通過將消息解封裝就可以恢復(fù)出媒體數(shù)據(jù)
二、RTMP協(xié)議中的相關(guān)概念
RTMP協(xié)議是TCP/IP五層體系結(jié)構(gòu)中應(yīng)用層的協(xié)議网杆，RTMP協(xié)議中基本的數(shù)據(jù)單元稱為消息羹饰，當(dāng)使用RTMP協(xié)議傳輸消息時伊滋，消息會被拆分成更小的單元，稱為消息塊
1队秩、消息
1）是RTMP協(xié)議中基本的數(shù)據(jù)單元
2）消息分為兩大部分
消息首部(Message Header)
標(biāo)志消息類型的Message Type ID
標(biāo)志消息長度的Payload Length
標(biāo)識時間戳的Timestamp
標(biāo)識消息所屬媒體流的Stream ID
消息負(fù)載(Message Body)
傳輸?shù)男畔?
3）不同種類的消息包含不同的Message Type ID笑旺，RTMP協(xié)議中一共規(guī)定了十多種消息類型，分別發(fā)揮著不同的作用
1-7
用于協(xié)議控制馍资，這些消息一般是RTMP協(xié)議自身管理要使用的消息燥撞，用戶一般情況下無需操作其中的數(shù)據(jù)
8-9
分別用于傳輸音頻視頻數(shù)據(jù)
15-20
用于發(fā)送AMF編碼的命令，負(fù)責(zé)用戶與服務(wù)器之間的交互迷帜，比如播放物舒，暫停等等
2、消息塊
1戏锹、在網(wǎng)絡(luò)上傳輸數(shù)據(jù)時冠胯，消息需要拆分成較小的數(shù)據(jù)塊，才適合在相應(yīng)的網(wǎng)絡(luò)環(huán)境上傳輸
2锦针、在消息被分割成幾個消息塊的過程中荠察，消息負(fù)載部分（Message Body）被分割成大小固定的數(shù)據(jù)塊（默認(rèn)是128字節(jié)，最后一個數(shù)據(jù)塊可以小于該固定長度）奈搜，并在其首部加上消息塊首部（Chunk Header）悉盆，就組成了相應(yīng)的消息塊。
三馋吗、RTMP流媒體播放過程
RTMP協(xié)議規(guī)定焕盟，播放一個流媒體有兩個前提步驟，
1宏粤、第一步脚翘，建立一個網(wǎng)絡(luò)連接
服務(wù)端應(yīng)用程序和客戶端之間基礎(chǔ)的連通關(guān)系
2、第二步绍哎，建立一個網(wǎng)絡(luò)流
網(wǎng)絡(luò)流代表了發(fā)送多媒體數(shù)據(jù)的通道来农，服務(wù)端和客戶端之間只能建立一個網(wǎng)絡(luò)連接，但是基于該連接可以創(chuàng)建很多網(wǎng)絡(luò)流
