直播中視頻編解碼、推拉流等流程解析

前言：以下是有關(guān)直播中視頻編解碼、推拉流等流程解析，僅用于個(gè)人記錄和學(xué)習(xí)

一、視頻編碼

1、為什么編碼?

編碼就是對(duì)視頻進(jìn)行壓縮，由于網(wǎng)絡(luò)帶寬和硬盤存儲(chǔ)空間都是非常有限的，因此，需要先使用視頻編碼技術(shù)（比如H.264編碼）對(duì)原始視頻進(jìn)行壓縮，然后再進(jìn)行存儲(chǔ)和分發(fā)。H.264編碼的壓縮比可以達(dá)到至少是100:1。

2、什么是編碼?

編碼就是按照一定的格式記錄采樣和量化后的數(shù)據(jù)。

3、編碼中軟編碼和硬編碼的區(qū)別？

  • 硬編碼: 使用非CPU進(jìn)行編碼,例如使用GPU芯片處理。
  • 軟編碼: 使用CPU來進(jìn)行編碼計(jì)算。

4、軟編碼與硬編碼的區(qū)分？

  • 軟編碼: 實(shí)現(xiàn)直接、簡(jiǎn)單，參數(shù)調(diào)整方便，升級(jí)易，但CPU負(fù)載重，性能較硬編碼低，低碼率下質(zhì)量通常比硬編碼要好一點(diǎn)。
  • 硬編碼：性能高，低碼率下通常質(zhì)量低于硬編碼器，但部分產(chǎn)品在GPU硬件平臺(tái)移植了優(yōu)秀的軟編碼算法（如X264）的，質(zhì)量基本等同于軟編碼。
可以這樣理解:
  • 硬編碼就是使用GPU計(jì)算，獲取數(shù)據(jù)結(jié)果，優(yōu)點(diǎn)速度快，效率高。
  • 軟編碼就是通過CPU來計(jì)算，獲取數(shù)據(jù)結(jié)果。

5、壓縮算法

壓縮算法分為2種，有損壓縮與無損壓縮。

  • 無損壓縮：解壓后的數(shù)據(jù)可以完全復(fù)原，在常用的壓縮格式中，無損壓縮使用頻次較低。
  • 有損壓縮：解壓后數(shù)據(jù)不能完全復(fù)原，會(huì)丟失一部分信息。壓縮比越小，丟失的信息就會(huì)越多。信號(hào)還原的失真就會(huì)越大。

需要根據(jù)不同的場(chǎng)景(考慮因素包括存儲(chǔ)設(shè)備，傳輸網(wǎng)絡(luò)環(huán)境，播放設(shè)備等)選用不同的壓縮編碼算法。

二、視頻解碼

1、什么是解碼?

解碼，就是把獲取到的數(shù)據(jù)解壓縮，恢復(fù)成原始數(shù)據(jù)。解碼就是將H264變成YUV，AAC變成PCM。

2、解碼方式

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

  • 軟解碼就是利用CPU資源去解壓縮數(shù)據(jù)，采用的方式是FFmpeg解碼。
  • 硬解碼，對(duì)于iOS平臺(tái)來說，可以使用VideoToolbox.Framework（該框架只能在iOS 8.0及以上系統(tǒng)使用）硬解碼視頻數(shù)據(jù)。Android平臺(tái)上，可以使用MediaCodec來硬解碼視頻數(shù)據(jù)。

三、直播

1、直播項(xiàng)目流程8個(gè)步驟

  • 音視頻采集
  • 視頻濾鏡
  • 音視頻編碼
  • 推流
  • 流媒體服務(wù)器處理
  • 拉流
  • 音視頻解碼
  • 音視頻播放

2、采集視頻,音頻

  • 使用iOS原生框架 AVFoundation.framework

3、視頻濾鏡處理

  • 使用iOS原生框架 CoreImage.framework
  • 使用第三方框架 GPUImage.framework

3.1、CoreImage 與 GPUImage 框架比較:

  • 在實(shí)際項(xiàng)目開發(fā)中,開發(fā)者更加傾向使用于GPUImage框架。
  • 首先它在使用性能上與iOS提供的原生框架,并沒有差別;其次它的使用便利性高于iOS原生框架。
  • 最后也是最重要的GPUImage框架是開源的.而大家如果想要學(xué)習(xí)GPUImage框架,建議學(xué)習(xí)OpenGL ES,其實(shí)GPUImage的封裝和思維都是基于OpenGL ES。

4、視頻\音頻編碼壓縮

4.1、硬編碼

  • 視頻: VideoToolBox框架
  • 音頻: AudioToolBox 框架

4.2、軟編碼

  • 視頻: 使用FFmpeg，X264算法把視頻原數(shù)據(jù)YUV/RGB編碼成H264
  • 音頻: 使用fdk_aac 將音頻數(shù)據(jù)PCM轉(zhuǎn)換成AAC

5、推流

5.1、什么是推流？

推流就是將采集的音頻、視頻數(shù)據(jù)通過流媒體協(xié)議發(fā)送到流媒體服務(wù)器。

5.2、推流技術(shù)

  • 流媒體協(xié)議: RTMP\RTSP\HLS\FLV
  • 視頻封裝格式: TS\FLV
  • 音頻封裝格式: Mp3\AAC

6、流媒體服務(wù)器

  • 數(shù)據(jù)分發(fā)
  • 截屏
  • 實(shí)時(shí)轉(zhuǎn)碼
  • 內(nèi)容檢測(cè)

7、拉流

7.1、什么是拉流？

拉流就是從流媒體服務(wù)器中獲取音頻\視頻數(shù)據(jù)。

7.2、流媒體協(xié)議

流媒體協(xié)議: RTMP\RTSP\HLS\FLV

8、音視頻解碼

8.1、硬解碼

  • 視頻: VideoToolBox框架
  • 音頻: AudioToolBox 框架

8.2、軟解碼

  • 視頻: 使用FFmpeg,X264算法解碼
  • 音頻: 使用fdk_aac 解碼

9、播放

  • ijkplayer 播放框架
  • kxmovie 播放框架

備注：ijkplayer、kxmovie 都是基于FFmpeg框架封裝的

四、音視頻處理的一般流程：

數(shù)據(jù)采集→數(shù)據(jù)編碼→數(shù)據(jù)傳輸(流媒體服務(wù)器) →解碼數(shù)據(jù)→播放顯示。

1、數(shù)據(jù)采集：

攝像機(jī)及拾音器收集視頻及音頻數(shù)據(jù)，此時(shí)得到的為原始數(shù)據(jù)。

1.1、涉及技術(shù)或協(xié)議：

攝像機(jī)：CCD、CMOS。

拾音器：聲電轉(zhuǎn)換裝置（咪頭）、音頻放大電路。

2、數(shù)據(jù)編碼：

使用相關(guān)硬件或軟件對(duì)音視頻原始數(shù)據(jù)進(jìn)行編碼處理（數(shù)字化）及加工（如音視頻混合、打包封裝等），得到可用的音視頻數(shù)據(jù)。

2.1、編碼方式：

編碼方式：CBR、VBR

2.2、編碼格式

視頻：H.265、H.264、MPEG-4等，封裝容器有TS、MKV、AVI、MP4等
音頻：G.711μ、AAC、Opus等，封裝有MP3、OGG、AAC等。

3、數(shù)據(jù)傳輸：

將編碼完成后的音視頻數(shù)據(jù)進(jìn)行傳輸，早期的音視頻通過同軸電纜之類的線纜進(jìn)行傳輸，IP網(wǎng)絡(luò)發(fā)展后，使用IP網(wǎng)絡(luò)優(yōu)傳輸。

3.1、涉及技術(shù)或協(xié)議：

傳輸協(xié)議：RTP與RTCP、RTSP、RTMP、HTTP、HLS（HTTP Live Streaming）等。
控制信令：SIP和SDP、SNMP等。

4、解碼數(shù)據(jù)：

使用相關(guān)硬件或軟件對(duì)接收到的編碼后的音視頻數(shù)據(jù)進(jìn)行解碼，得到可以直接顯示的圖像/聲音

4.1、涉及技術(shù)或協(xié)議：

一般對(duì)應(yīng)的編碼器都會(huì)帶有相應(yīng)的解碼器，也有一些第三方解碼插件等

5、播放顯示：

在顯示器（電視、監(jiān)視屏等）或揚(yáng)聲器（耳機(jī)、喇叭等）里，顯示相應(yīng)的圖像畫面或聲音

5.1、涉及技術(shù)或協(xié)議：

顯示器、揚(yáng)聲器、3D眼鏡等

四、視頻推流與視頻拉流的工作過程解析：

1、視頻推流端

推流，就是將采集到的音頻，視頻數(shù)據(jù)通過流媒體協(xié)議發(fā)送到流媒體服務(wù)器。

1.1、選擇流媒體協(xié)議

現(xiàn)在直播應(yīng)用，采用RTMP協(xié)議居多，也有部分使用HLS協(xié)議。

采用RTMP協(xié)議，就要看下它與流媒體服務(wù)器交互的過程，RTMP協(xié)議的默認(rèn)端口是1935，采用TCP協(xié)議。并且需要了解FLV的封裝格式。

采用HLS協(xié)議，因?yàn)樯婕暗角衅?，延時(shí)會(huì)比較大，需要了解TS流。

1.2、采集音視頻數(shù)據(jù)

做直播，數(shù)據(jù)的來源不可缺少，就是采集攝像頭，麥克風(fēng)的數(shù)據(jù)。

iOS平臺(tái)上采集音視頻數(shù)據(jù)，需要使用AVFoundation.Framework框架，從captureSession會(huì)話的回調(diào)中獲取音頻，視頻數(shù)據(jù)。

1.3、硬編碼，軟編碼音視頻數(shù)據(jù)

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

軟編碼的話，現(xiàn)在廣泛采用FFmpeg庫(kù)結(jié)合編碼庫(kù)來實(shí)現(xiàn)，F(xiàn)Fmpeg+X624來編碼視頻數(shù)據(jù)YUV/RGB輸出H264數(shù)據(jù)，

FFmpeg+fdk_aac來編碼音頻數(shù)據(jù)PCM輸出AAC數(shù)據(jù)。

1.4、根據(jù)所選流媒體協(xié)議封包音視頻數(shù)據(jù)

將音頻，視頻打包成packet。

1.5、與服務(wù)器交互發(fā)送封包數(shù)據(jù)

根據(jù)所選流媒體協(xié)議，發(fā)送相應(yīng)指令連接服務(wù)器，連接服務(wù)器成功后，就可以發(fā)送packet數(shù)據(jù)了。

2、拉流端

拉流，就是從流媒體服務(wù)器獲取音頻，視頻數(shù)據(jù)。

2.1、解析協(xié)議

播放器端根據(jù)URL解析所用的流媒體協(xié)議（RTMP，HLS）。

2.2、解封裝

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

2.3、解碼

解碼，就是把獲取到的數(shù)據(jù)解壓縮，恢復(fù)成原始數(shù)據(jù)。解碼就是將H264變成YUV，AAC變成PCM。

2.3.1、解碼可以使用軟解碼，硬解碼。
  • 軟解碼就是利用CPU資源去解壓縮數(shù)據(jù)，采用的方式是FFmpeg解碼。
  • 硬解碼，對(duì)于iOS平臺(tái)來說，可以使用VideoToolbox.Framework（該框架只能在iOS 8.0及以上系統(tǒng)使用）硬解碼視頻數(shù)據(jù)。Android平臺(tái)上，可以使用MediaCodec來硬解碼視頻數(shù)據(jù)。

2.4、渲染數(shù)據(jù)

采用OpenGL渲染YUV數(shù)據(jù)，呈現(xiàn)視頻畫面。將PCM送入設(shè)備的硬件資源播放，產(chǎn)生聲音。

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

五、iOS開發(fā)之 iOS 直播平臺(tái) 常見的視頻直播相關(guān)協(xié)議詳解

5.1、 RTMP(Real Time Messaging Protocol，實(shí)時(shí)消息傳送協(xié)議)

RTMP是Adobe Systems公司為Flash播放器和服務(wù)器之間音頻、視頻和數(shù)據(jù)傳輸開發(fā)的開放協(xié)議。它有三種變種：

  • 工作在TCP之上的明文協(xié)議，使用端口1935；

  • RTMPT封裝在HTTP請(qǐng)求之中，可穿越防火墻；

  • RTMPS類似RTMPT，但使用的是HTTPS連接；

RTMP協(xié)議是被Flash用于對(duì)象、視頻、音頻的傳輸。這個(gè)協(xié)議建立在TCP協(xié)議或者輪詢HTTP協(xié)議之上。RTMP協(xié)議就像一個(gè)用來裝數(shù)據(jù)包的容器，這些數(shù)據(jù)既可以是AMF格式的數(shù)據(jù)，也可以是FLV中的視音頻數(shù)據(jù)。一個(gè)單一的連接可以通過不同的通道傳輸多路網(wǎng)絡(luò)流，這些通道中的包都是按照固定大小的包傳輸?shù)摹?/p>

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

RTSP定義了一對(duì)多應(yīng)用程序如何有效地通過IP網(wǎng)絡(luò)傳送多媒體數(shù)據(jù)。RTSP提供了一個(gè)可擴(kuò)展框架，數(shù)據(jù)源可以包括實(shí)時(shí)數(shù)據(jù)與已有的存儲(chǔ)的數(shù)據(jù)。該協(xié)議目的在于控制多個(gè)數(shù)據(jù)發(fā)送連接，為選擇發(fā)送通道如UDP、組播UDP與TCP提供途徑，并為選擇基于RTP上發(fā)送機(jī)制提供方法。

RTSP語法和運(yùn)作跟HTTP/1.1類似，但并不特別強(qiáng)調(diào)時(shí)間同步，所以比較能容忍網(wǎng)絡(luò)延遲。代理服務(wù)器的緩存功能也同樣適用于RTSP，并且因?yàn)镽TSP具有重新導(dǎo)向功能，可根據(jù)實(shí)際負(fù)載情況來切換提供服務(wù)的服務(wù)器，以避免過大的負(fù)載集中于同一服務(wù)器而造成延遲。

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

RTP是針對(duì)多媒體數(shù)據(jù)流的一種傳輸層協(xié)議，詳細(xì)說明了在互聯(lián)網(wǎng)上傳遞音頻和視頻的標(biāo)準(zhǔn)數(shù)據(jù)包格式。RTP協(xié)議常用于流媒體系統(tǒng)（配合RTCP協(xié)議），視頻會(huì)議和一鍵通系統(tǒng)（配合H.323或SIP），使它成為IP電話產(chǎn)業(yè)的技術(shù)基礎(chǔ)。

RTP是建立在UDP協(xié)議上的，常與RTCP一起使用，其本身并沒有提供按時(shí)發(fā)送機(jī)制或其它服務(wù)質(zhì)量（QoS）保證，它依賴于低層服務(wù)去實(shí)現(xiàn)這一過程。

參考：http://m.itdecent.cn/p/3bf57b5b3637
參考：http://m.itdecent.cn/p/a7c1408a89e3

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡(jiǎn)書系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容