視頻直播流程
視頻直播的流程可以分為如下幾步： 采集 —>處理—>編碼和封裝—>推流到服務(wù)器—>服務(wù)器流分發(fā)—>播放器流播放
1.采集
采集是整個視頻推流過程中的第一個環(huán)節(jié)，它從系統(tǒng)的采集設(shè)備中獲取原始視頻數(shù)據(jù)，將其輸出到下一個環(huán)節(jié)。視頻的采集涉及兩方面數(shù)據(jù)的采集：音頻采集和圖像采集，它們分別對應(yīng)兩種完全不同的輸入源和數(shù)據(jù)格式荆隘。
音頻采集 音頻數(shù)據(jù)既能與圖像結(jié)合組合成視頻數(shù)據(jù)，也能以純音頻的方式采集播放，后者在很多成熟的應(yīng)用場景如在線電臺和語音電臺等起著非常重要的作用徘钥。音頻的采集過程主要通過設(shè)備將環(huán)境中的模擬信號采集成 PCM 編碼的原始數(shù)據(jù)，然后編碼壓縮成 MP3 等格式的數(shù)據(jù)分發(fā)出去肢娘。常見的音頻壓縮格式有：MP3呈础，AAC，HE-AAC橱健，Opus而钞，F(xiàn)LAC，Vorbis (Ogg)拘荡，Speex 和 AMR等臼节。 音頻采集和編碼主要面臨的挑戰(zhàn)在于：延時(shí)敏感、卡頓敏感珊皿、噪聲消除（Denoise）网缝、回聲消除（AEC）、靜音檢測（VAD）和各種混音算法等蟋定。
圖像采集 將圖像采集的圖片結(jié)果組合成一組連續(xù)播放的動畫粉臊，即構(gòu)成視頻中可肉眼觀看的內(nèi)容。圖像的采集過程主要由攝像頭等設(shè)備拍攝成 YUV 編碼的原始數(shù)據(jù)驶兜，然后經(jīng)過編碼壓縮成 H.264 等格式的數(shù)據(jù)分發(fā)出去扼仲。常見的視頻封裝格式有：MP4远寸、3GP、AVI屠凶、MKV驰后、WMV、MPG矗愧、VOB灶芝、FLV、SWF唉韭、MOV监署、RMVB 和 WebM 等。 圖像由于其直觀感受最強(qiáng)并且體積也比較大纽哥，構(gòu)成了一個視頻內(nèi)容的主要部分钠乏。圖像采集和編碼面臨的主要挑戰(zhàn)在于：設(shè)備兼容性差、延時(shí)敏感春塌、卡頓敏感以及各種對圖像的處理操作如美顏和水印等晓避。
視頻采集的采集源主要有 攝像頭采集、屏幕錄制和從視頻文件推流只壳。
2.處理
視頻或者音頻完成采集之后得到原始數(shù)據(jù)俏拱，為了增強(qiáng)一些現(xiàn)場效果或者加上一些額外的效果，我們一般會在將其編碼壓縮前進(jìn)行處理吼句，比如打上時(shí)間戳或者公司 Logo 的水印锅必，祛斑美顏和聲音混淆等處理。在主播和觀眾連麥場景中惕艳，主播需要和某個或者多個觀眾進(jìn)行對話搞隐，并將對話結(jié)果實(shí)時(shí)分享給其他所有觀眾，連麥的處理也有部分工作在推流端完成远搪。
如上圖所示劣纲，處理環(huán)節(jié)中分為音頻和視頻處理，音頻處理中具體包含混音谁鳍、降噪和聲音特效等處理癞季，視頻處理中包含美顏、水印倘潜、以及各種自定義濾鏡等處理绷柒。
3.編碼和封裝
（1）編碼
如果把整個流媒體比喻成一個物流系統(tǒng)，那么編解碼就是其中配貨和裝貨的過程涮因，這個過程非常重要废睦，它的速度和壓縮比對物流系統(tǒng)的意義非常大，影響物流系統(tǒng)的整體速度和成本蕊退。同樣郊楣，對流媒體傳輸來說，編碼也非常重要瓤荔，它的編碼性能净蚤、編碼速度和編碼壓縮比會直接影響整個流媒體傳輸?shù)挠脩趔w驗(yàn)和傳輸成本。
視頻編碼的意義 原始視頻數(shù)據(jù)存儲空間大输硝，一個 1080P 的 7 s 視頻需要 817 MB 原始視頻數(shù)據(jù)傳輸占用帶寬大今瀑，10 Mbps 的帶寬傳輸上述 7 s 視頻需要 11 分鐘 而經(jīng)過 H.264 編碼壓縮之后，視頻大小只有 708 k 点把，10 Mbps 的帶寬僅僅需要 500 ms ，可以滿足實(shí)時(shí)傳輸?shù)男枨罄商樱詮囊曨l采集傳感器采集來的原始視頻勢必要經(jīng)過視頻編碼。
基本原理 為什么巨大的原始視頻可以編碼成很小的視頻呢?這其中的技術(shù)是什么呢?核心思想就是去除冗余信息： 1）空間冗余：圖像相鄰像素之間有較強(qiáng)的相關(guān)性 2）時(shí)間冗余：視頻序列的相鄰圖像之間內(nèi)容相似 3）編碼冗余：不同像素值出現(xiàn)的概率不同 4）視覺冗余：人的視覺系統(tǒng)對某些細(xì)節(jié)不敏感 5）知識冗余：規(guī)律性的結(jié)構(gòu)可由先驗(yàn)知識和背景知識得到
編碼器的選擇 視頻編碼器經(jīng)歷了數(shù)十年的發(fā)展褒翰，已經(jīng)從開始的只支持幀內(nèi)編碼演進(jìn)到現(xiàn)如今的 H.265 和 VP9 為代表的新一代編碼器贮懈，下面是一些常見的視頻編碼器： 1）H.264/AVC 2）HEVC/H.265 3）VP8 4）VP9 5）FFmpeg 注：音頻編碼器有Mp3, AAC等优训。
（2）封裝 沿用前面的比喻朵你，封裝可以理解為采用哪種貨車去運(yùn)輸，也就是媒體的容器揣非。 所謂容器抡医，就是把編碼器生成的多媒體內(nèi)容(視頻，音頻早敬，字幕，章節(jié)信息等)混合封裝在一起的標(biāo)準(zhǔn)搞监。容器使得不同多媒體內(nèi)容同步播放變得很簡單，而容器的另一個作用就是為多媒體內(nèi)容提供索引腺逛，也就是說如果沒有容器存在的話一部影片你只能從一開始看到最后荷愕，不能拖動進(jìn)度條，而且如果你不自己去手動另外載入音頻就沒有聲音棍矛。下面是幾種常見的封裝格式： 1）AVI 格式(后綴為 .avi) 2）DV-AVI 格式(后綴為 .avi) 3）QuickTime File Format 格式(后綴為 .mov) 4）MPEG 格式(文件后綴可以是 .mpg .mpeg .mpe .dat .vob .asf .3gp .mp4等) 5）WMV 格式(后綴為.wmv .asf) 6）Real Video 格式(后綴為 .rm .rmvb) 7）Flash Video 格式(后綴為 .flv) 8）Matroska 格式(后綴為 .mkv) 9）MPEG2-TS 格式 (后綴為 .ts) 目前安疗，我們在流媒體傳輸，尤其是直播中主要采用的就是 FLV 和 MPEG2-TS 格式够委，分別用于 RTMP/HTTP-FLV 和 HLS 協(xié)議荐类。
4.推流到服務(wù)器
推流是直播的第一公里，直播的推流對這個直播鏈路影響非常大玉罐，如果推流的網(wǎng)絡(luò)不穩(wěn)定屈嗤，無論我們?nèi)绾巫鰞?yōu)化吊输，觀眾的體驗(yàn)都會很糟糕饶号。所以也是我們排查問題的第一步季蚂，如何系統(tǒng)地解決這類問題需要我們對相關(guān)理論有基礎(chǔ)的認(rèn)識茫船。 推送協(xié)議主要有三種：
RTSP（Real Time Streaming Protocol）：實(shí)時(shí)流傳送協(xié)議扭屁，是用來控制聲音或影像的多媒體串流協(xié)議, 由Real Networks和Netscape共同提出的； RTMP(Real Time Messaging Protocol)：實(shí)時(shí)消息傳送協(xié)議料滥，是Adobe公司為Flash播放器和服務(wù)器之間音頻然眼、視頻和數(shù)據(jù)傳輸 開發(fā)的開放協(xié)議葵腹； HLS(HTTP Live Streaming)：是蘋果公司(Apple Inc.)實(shí)現(xiàn)的基于HTTP的流媒體傳輸協(xié)議罪治； RTMP協(xié)議基于 TCP礁蔗，是一種設(shè)計(jì)用來進(jìn)行實(shí)時(shí)數(shù)據(jù)通信的網(wǎng)絡(luò)協(xié)議，主要用來在 flash/AIR 平臺和支持 RTMP 協(xié)議的流媒體/交互服務(wù)器之間進(jìn)行音視頻和數(shù)據(jù)通信浴井。支持該協(xié)議的軟件包括 Adobe Media Server/Ultrant Media Server/red5 等晒骇。 它有三種變種：
RTMP工作在TCP之上的明文協(xié)議磺浙，使用端口1935； RTMPT封裝在HTTP請求之中撕氧，可穿越防火墻瘤缩； RTMPS類似RTMPT，但使用的是HTTPS連接伦泥； RTMP 是目前主流的流媒體傳輸協(xié)議，廣泛用于直播領(lǐng)域不脯，可以說市面上絕大多數(shù)的直播產(chǎn)品都采用了這個協(xié)議。 RTMP協(xié)議就像一個用來裝數(shù)據(jù)包的容器防楷，這些數(shù)據(jù)可以是AMF格式的數(shù)據(jù),也可以是FLV中的視/音頻數(shù)據(jù)。一個單一的連接可以通過不同的通道傳輸多路網(wǎng)絡(luò)流复局。這些通道中的包都是按照固定大小的包傳輸?shù)摹?
以上就是主播功能的基本流程：
采集視頻粟判、音頻數(shù)據(jù) ---- 將視頻數(shù)據(jù)通過h264/aac進(jìn)行編碼 ---- 將編碼好的音頻視頻數(shù)據(jù)混合封裝成flv的格式 ---- 把flv數(shù)據(jù)推送到支持rtmp的服務(wù)器峦剔。
下面提供人家已經(jīng)集成好的rtmp服務(wù)器工具方便測試：?https://github.com/illuspas/nginx-rtmp-win32
