流媒體開發(fā)中，流媒體系統(tǒng)的實(shí)現(xiàn)從數(shù)據(jù)采集、編碼封裝、傳輸分發(fā)、接收解碼播放都有哪些技術(shù)和實(shí)現(xiàn)，流媒體和本地音視頻又有哪些差異？

影像系統(tǒng)開發(fā)，流媒體方向和普通的多媒體影像系統(tǒng)開發(fā)有一定差異。

相同點(diǎn)在于圖像多媒體處理以及編程系統(tǒng)等通用方面；本文重點(diǎn)梳理出差異的部分，差異主要在于影像系統(tǒng)在流媒體需要掌握流媒體協(xié)議rtsp以及流媒體框架GStreamer，在鏈路流程上增加了傳輸分發(fā)部分，在軟件系統(tǒng)設(shè)計上注重負(fù)載均以及高并發(fā)低延遲。

流媒體技術(shù)通過實(shí)時傳輸音視頻數(shù)據(jù)應(yīng)用廣泛，主要涉及直播/短視頻平臺、視頻會議、智能安防等幾大類。最近幾年的觀察，具體來說在直播攝像頭、會議攝像頭、智能家具攝像頭都有很多產(chǎn)品推出。

一、流媒體綜述

流媒體開發(fā)除了編程及嵌入式技術(shù)外還需要掌握影像技術(shù)。嵌入式系統(tǒng)開發(fā)技術(shù)涵蓋了硬件設(shè)計、軟件編程、系統(tǒng)調(diào)試等多個方面。

在整理流媒體的數(shù)據(jù)鏈路上，把流媒體技術(shù)根據(jù)是否通用分為兩大類，流媒體的特點(diǎn)主要在于網(wǎng)絡(luò)傳輸，所以如果你要面試流媒體相關(guān)崗位除了影像的通用知識，最好溫習(xí)一些網(wǎng)絡(luò)協(xié)議、流媒體協(xié)議和框架的知識。

1.1音視頻通用

（1）采集

流媒體的采集模塊負(fù)責(zé)從攝像頭、麥克風(fēng)等輸入設(shè)備采集原始的音視頻數(shù)據(jù)。

流媒體和多媒體的音視頻采集和處理的基礎(chǔ)邏輯是相通的，比如圖像的3A、降噪增強(qiáng)以及音頻的回聲消除AEC、噪聲抑制NS、自動增益控制AGC。

流媒體在采集模塊會重點(diǎn)考慮支持不同分辨率幀率的多攝像頭設(shè)備適配。

（2）編碼

流媒體編碼模塊將采集到的原始音視頻數(shù)據(jù)進(jìn)行編碼處理，壓縮成適合網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)流。

音視頻編碼是將原始的音視頻數(shù)據(jù)壓縮為較小的數(shù)據(jù)流，以便于傳輸和存儲。這一技術(shù)對于減少帶寬占用、提高傳輸效率很重要。

常用的音視頻編碼標(biāo)準(zhǔn)包括H.264、H.265HEVC等視頻編碼標(biāo)準(zhǔn)和AAC、MP3等音頻編碼標(biāo)準(zhǔn)。同時會借用平臺的能力來降低CPU負(fù)載，如NVIDIA NVENC、MediaTek APU等等。

（3）封裝

封裝模塊將編碼后的音視頻數(shù)據(jù)按照特定的格式進(jìn)行封裝，如FLV、MP4等容器格式，可以用來本地存儲播放，也可以用于網(wǎng)絡(luò)傳輸和播放。

（4）解碼

解碼播放模塊在接收端，流媒體接收就用用戶端，不同于本地芯片內(nèi)完成編碼解碼，流媒體的編碼解碼在不同設(shè)備完成。接收端析接收到的音視頻數(shù)據(jù)，進(jìn)行解碼處理，并將解碼后的音視頻數(shù)據(jù)傳遞給播放器進(jìn)行播放。

1.2流媒體關(guān)鍵技術(shù)

（1）傳輸

流媒體傳輸模塊利用流媒體傳輸協(xié)議將封裝好的音視頻數(shù)據(jù)發(fā)送到服務(wù)器或接收端。處理網(wǎng)絡(luò)傳輸中的各種問題，如丟包延遲等。

流媒體傳輸協(xié)議負(fù)責(zé)將編碼后的音視頻數(shù)據(jù)從發(fā)送端傳輸?shù)浇邮斩?，同時兼顧了實(shí)時數(shù)據(jù)流的傳輸控制、錯誤恢復(fù)和同步等功能。

常見的流媒體傳輸協(xié)議包括RTSP實(shí)時流協(xié)議、RTP實(shí)時傳輸協(xié)議、HTTP Live Streaming等等，傳輸協(xié)議的基礎(chǔ)則是網(wǎng)絡(luò)通信技術(shù)包括TCP/IP、Wi-Fi、藍(lán)牙等。

（2）轉(zhuǎn)發(fā)

流媒體服務(wù)端使用支持RTMP/HLS/WebRTC協(xié)議的流媒體服務(wù)器SRS或者Nginx-RTMP，通過分布式框架利用CDN智能調(diào)用，兼顧負(fù)載均衡Nginx/HAProxy，實(shí)現(xiàn)高并發(fā)低時延。

（3）接收

流媒體客戶端接收到媒體數(shù)據(jù)后，軟件使用Android MediaCodec的API實(shí)現(xiàn)解碼，以及利用PTS/DTS時間戳實(shí)現(xiàn)音視頻同步。

（4）多媒體框架

多媒體框架是嵌入式系統(tǒng)中實(shí)現(xiàn)音視頻播放和錄制的軟件架構(gòu)，比如GStreamer架構(gòu)提供了豐富的音視頻處理功能，包括解碼、編碼、轉(zhuǎn)碼、流媒體處理等。

而我們常說的推流則只是框架中的一環(huán)，可以使用GStreamer實(shí)現(xiàn)，也可以通過專用推流框架OBS Studio/WebRTC實(shí)現(xiàn)更加快速。

二、流媒體框架GStreamer

在不同的應(yīng)用場景下，音視頻嵌入式系統(tǒng)所使用的新媒體播放和流媒體框架會有所不同。

流媒體框架主要用于實(shí)時傳輸和處理音視頻數(shù)據(jù)，比如視頻監(jiān)控、網(wǎng)絡(luò)直播等領(lǐng)域。

GStreamer 是一個開源的多媒體框架，基于管道設(shè)計，采用C語言開發(fā)，支持跨平臺，提供了處理流媒體的管道架構(gòu)和音視頻處理能力。它的特點(diǎn)是利用插件架構(gòu)，可以方便地擴(kuò)展功能，包括編碼方式、封裝格式等。

GStreamer的管道架構(gòu)是通過鏈接多個elements構(gòu)成pipeline來處理多媒體內(nèi)容，用于音頻錄制、轉(zhuǎn)碼、播放以及視頻流傳輸?shù)榷喾N場景。

針對顯示和渲染，GStreamer也是通過其插件系統(tǒng)來實(shí)現(xiàn)的。比如有專門的視頻 sink 插件xvimagesink進(jìn)行視頻渲染，負(fù)責(zé)將視頻幀輸出到屏幕上。

GStreamer插件機(jī)制可以實(shí)現(xiàn)非常多的格式支持和處理能力，不僅用于流媒體服務(wù)器、多媒體播放器等，在整個圖像軟件的處理過程中都廣泛的使用。

2.1框架代碼

（1）配置環(huán)境，從官網(wǎng)站下載GStreamer的Android開發(fā)包，并按照官方文檔進(jìn)行配置，一般都是集成好的。

（2）集成，在項(xiàng)目的build.gradle文件中添加相應(yīng)的依賴，或者更多將GStreamer的庫直接集成到項(xiàng)目中。

（3）編寫處理代碼，使用GStreamer提供的API和插件來實(shí)現(xiàn)具體的音視頻處理功能。

使用gst_parse_launch()函數(shù)來創(chuàng)建和配置GStreamer的pipeline，通過添加不同的elements（如source、sink、filter等）來實(shí)現(xiàn)音視頻數(shù)據(jù)的捕獲、處理、傳輸?shù)裙δ埽?strong>軟件使用它的核心就是掌握這些elements，這和我們掌握ISP的pipeline同理。

（4）編譯和運(yùn)行，將編寫的代碼保存并編譯，并連接了硬件設(shè)備麥克風(fēng)和攝像頭。使用調(diào)試工具測試音視頻處理功能是否正常工作。

2.2框架的使用

（1）音視頻錄制，在插件體系中，配置不同的音頻源和音頻格式，配置不同的視頻格式，滿足不同的錄制需求。

（2）視頻流傳輸，GStreamer RTSP服務(wù)器是一種基于GStreamer框架的實(shí)時流傳輸協(xié)議RTSP的服務(wù)器，可用于在Android平臺上進(jìn)行音視頻流的傳輸和處理。

（3）音視頻轉(zhuǎn)碼，利用插件實(shí)現(xiàn)音視頻數(shù)據(jù)的轉(zhuǎn)碼功能，根據(jù)需要將音視頻數(shù)據(jù)轉(zhuǎn)換為不同的格式或編碼，以滿足不同的播放或存儲需求。

（4）視頻播放，支持MP4、AVI等多種視頻格式的解碼和播放，集成到安卓應(yīng)用中，實(shí)現(xiàn)視頻文件的本地播放或網(wǎng)絡(luò)流媒體播放。

（5）音視頻剪輯與編輯，底層可以通過GStreamer的插件和API，還可以實(shí)現(xiàn)音視頻數(shù)據(jù)的剪輯、合并、添加濾鏡等編輯功能。

三、流媒體協(xié)議RTSP

在嵌入式系統(tǒng)中，常使用實(shí)時流協(xié)議RTSP和RTMP實(shí)時消息傳輸協(xié)議協(xié)議來實(shí)現(xiàn)流媒體傳輸。這些協(xié)議允許客戶端從服務(wù)器接收音視頻流，并實(shí)時播放。

RTSP（Real Time Streaming Protocol）其實(shí)是TCP/IP協(xié)議體系中的一個應(yīng)用層協(xié)議，不同于我們學(xué)習(xí)時考究的傳輸層，該協(xié)議主要用于控制聲音或影像的多媒體串流，允許同時多個串流需求控制，從而支持實(shí)時流媒體應(yīng)用。

3.1RTSP特點(diǎn)

（1）雙向：與HTTP的單向不同，RTSP協(xié)議是雙向的。RTSP在交互過程中，客戶機(jī)和服務(wù)器都可以發(fā)出請求。

（2）實(shí)時：RTSP設(shè)計用于實(shí)時流媒體傳輸，具有較低的延遲，滿足實(shí)時交互的應(yīng)用場景。

（3）獨(dú)立：在傳輸層上，RTSP獨(dú)立于RTP和RTCP又相互配合。RTSP控制媒體流的傳輸，RTP和RTCP則負(fù)責(zé)實(shí)際的數(shù)據(jù)傳輸和質(zhì)量控制。

（4）功能：RTSP不僅用于傳輸數(shù)據(jù)，它還允許客戶端控制媒體流的播放，如播放、暫停、快進(jìn)、快退等。

3.2RTSP工作流

RTSP的核心工作流總結(jié)下來就以下幾點(diǎn)，

（1）OPTIONS：客戶端發(fā)送OPTIONS請求，get以了解服務(wù)器支持哪些方法；

（2）DESCRIBE：客戶端發(fā)送DESCRIBE請求，get媒體資源的描述信息，比如編碼分辨率等，服務(wù)器則返回媒體資源的SDP格式的描述信息。

（3）SETUP：客戶端發(fā)送SETUP請求，用于建立媒體會話，指定傳輸通道協(xié)議UDP并請求分配端口，服務(wù)器則指定媒體流的傳輸通道和端口。

（4）PLAY：客戶端發(fā)送PLAY請求，以開始媒體流的播放。服務(wù)器確認(rèn)PLAY請求，并啟動媒體流的傳輸。

（5）TEARDOWN：當(dāng)媒體會話結(jié)束時，客戶端發(fā)送TEARDOWN請求以終止會話，服務(wù)器確認(rèn)并釋放相關(guān)資源。

四、流媒體應(yīng)用

RTSP廣泛應(yīng)用于需要實(shí)時流媒體傳輸?shù)膱鼍?，如視頻監(jiān)控、視頻會議、直播和點(diǎn)播服務(wù)、流媒體服務(wù)器、媒體播放器等。

4.1安防監(jiān)控

安防監(jiān)控攝像頭可以將實(shí)時視頻流傳輸?shù)奖O(jiān)控中心或客戶端，實(shí)現(xiàn)遠(yuǎn)程監(jiān)控和實(shí)時查看。

安防監(jiān)控框架需要具有高實(shí)時性、高穩(wěn)定性和高可靠性，以確保監(jiān)控視頻能夠?qū)崟r、準(zhǔn)確地傳輸和存儲。需要支持多種視頻編碼格式和網(wǎng)絡(luò)協(xié)議，以適應(yīng)不同的監(jiān)控需求和網(wǎng)絡(luò)環(huán)境。

這些系統(tǒng)通常由攝像頭、視頻錄像設(shè)備和嵌入式處理器組成，通過與傳感器相結(jié)合，實(shí)現(xiàn)圖像傳輸、分析和存儲等功能。

除了使用自研專有框架，開源框架GStreamer也可用于安防監(jiān)控系統(tǒng)，以實(shí)現(xiàn)跨平臺的視頻流處理和傳輸。

4.2視頻會議

視頻會議框架需要具有低延遲、高清晰度和良好的同步性能，以確保音視頻數(shù)據(jù)的實(shí)時傳輸和播放。

視頻會議系統(tǒng)需要實(shí)現(xiàn)音視頻數(shù)據(jù)的實(shí)時傳輸和同步播放，以確保參會人員能夠清晰地看到和聽到對方的發(fā)言。

除了使用自研專有框架，開源框架WebRTC支持網(wǎng)頁瀏覽器進(jìn)行實(shí)時音視頻通信的項(xiàng)目也可以用于視頻會議，提供了完整的流媒體功能。

4.3直播和服務(wù)器

直播觀眾可以同步實(shí)時觀看，需要保證低時延和高可靠性，內(nèi)容生成和播放同時進(jìn)行，自動調(diào)整碼率，以確保觀眾能夠?qū)崟r流暢的觀看直播內(nèi)容。

直播系統(tǒng)完整流程：主播用OBS推流RTMP協(xié)議→ 流媒體服務(wù)器SRS接收并轉(zhuǎn)封裝為HLS → CDN分發(fā) → 觀眾通過播放器Video.js拉流觀看。

直播主播端實(shí)現(xiàn)RTMP推流協(xié)議將數(shù)據(jù)從主播端推送到服務(wù)器；

流媒體服務(wù)器負(fù)責(zé)接收、處理、分發(fā)音視頻數(shù)據(jù)的服務(wù)，把將推流協(xié)議RTMP轉(zhuǎn)換為拉流協(xié)議HLS，適配不同的終端和網(wǎng)絡(luò)，通過CDN進(jìn)行內(nèi)容分發(fā)。用戶端通過網(wǎng)絡(luò)接收到直播的媒體數(shù)據(jù)。

視頻流媒體的分發(fā)也常用P2P技術(shù)，對等網(wǎng)絡(luò)P2P（Peer-to-Peer）不依賴中心服務(wù)器，通過分散的節(jié)點(diǎn)分發(fā)從而優(yōu)化視頻流傳輸，即用戶觀看視頻時，其設(shè)備可以同時成為其他用戶的源。

除了專有框架，直播系統(tǒng)中常用的流媒體框架包括RTMP（實(shí)時消息傳輸協(xié)議）框架、HLS（HTTP Live Streaming）框架等。RTMP框架主要用于實(shí)現(xiàn)音視頻數(shù)據(jù)的實(shí)時傳輸和控制，而HLS框架則主要用于實(shí)現(xiàn)音視頻數(shù)據(jù)的分片傳輸和自適應(yīng)碼率播放。

4.4 點(diǎn)播和播放器

區(qū)別于直播，點(diǎn)播是用戶按需觀看預(yù)先錄制好的內(nèi)容，比如電影、短視頻等，數(shù)據(jù)被預(yù)先存儲在了服務(wù)器中。

點(diǎn)播框架需要具有高兼容性、高穩(wěn)定性，需要支持多種音視頻格式和編碼標(biāo)準(zhǔn)，以確保用戶能夠播放各種音視頻內(nèi)容。

點(diǎn)播系統(tǒng)完整流程：上傳MP4文件 → 服務(wù)器轉(zhuǎn)碼為多碼率HLS → 存儲至云端 → 用戶點(diǎn)播時播放器根據(jù)網(wǎng)速自動選擇最佳碼率。

點(diǎn)播系統(tǒng)的核心在于播放段，點(diǎn)播系統(tǒng)允許用戶根據(jù)自己的需求選擇、快進(jìn)、播放內(nèi)容。在服務(wù)器中進(jìn)行根據(jù)不同的網(wǎng)路環(huán)境進(jìn)行轉(zhuǎn)碼生成不同碼率版本，通過漸進(jìn)式下載或自適應(yīng)流傳輸。

RTSP服務(wù)器可以從實(shí)時視頻源獲取音視頻流，并通過RTSP將其傳輸?shù)娇蛻舳诉M(jìn)行播放，同時支持點(diǎn)播服務(wù)。

除了專有框架，點(diǎn)播系統(tǒng)中常用的新媒體播放框架包括各種播放器軟件所使用的框架，如VLC、MPlayer等。這些框架通常支持多種音視頻格式和編碼標(biāo)準(zhǔn)，能夠解碼并播放用戶選擇的音視頻內(nèi)容。

4.5音視頻編輯

在音視頻編輯領(lǐng)域，根據(jù)編輯平臺的不同，每家公司形成了自己的框架，比如桌面端Adobe Premiere Pro，提供豐富的編輯工具和特效庫；移動端KineMaster，具有輕便、易用和高效的特點(diǎn)；云端WeVideo，備在線協(xié)作、實(shí)時預(yù)覽和分享等功能。

但底層通常依賴于少數(shù)開源多媒體處理框架如GStreamer、FFmpeg等，GStreamer的插件化架構(gòu)適合靈活擴(kuò)展，但性能優(yōu)化不如FFmpeg，在此基礎(chǔ)上每家企業(yè)常用的模式都是開源+自研的組合方案實(shí)現(xiàn)最終的項(xiàng)目方案。

總結(jié)

流媒體系統(tǒng)的開發(fā)的典型特點(diǎn)一個是最終低延遲和高并發(fā)，另一個就是注重傳輸協(xié)議設(shè)計以及編解碼優(yōu)化。

當(dāng)前擁抱AI的發(fā)展，主要發(fā)展還是AI實(shí)時美顏，AI語音降噪，邊緣計算等。

軟件在流媒體的主要的優(yōu)化方向，在服務(wù)器側(cè)主要是降低延遲和高并發(fā)，比如減少協(xié)議棧層級，容器化部署等；在客戶端主要是內(nèi)存優(yōu)化，降低功耗。

總結(jié)來說，關(guān)注流媒體的差異，通信協(xié)議和流媒體框架，同時還是要多回歸到影像上。流媒體的應(yīng)用，比如監(jiān)控已經(jīng)發(fā)展很完備了，從zf監(jiān)控到如今的家用監(jiān)控；直播攝像頭發(fā)展還是蠻快的，實(shí)際看過好幾家的產(chǎn)品都在迭代中。