1 線上授課直播平臺(tái)播放質(zhì)量問(wèn)題

因?yàn)橐咔橛绊?，?020 年2 月下旬全國(guó)院校開始啟用線上授課模式。線上授課模式主要包括2類平臺(tái)，一類是線上課程視頻點(diǎn)播(VOD)平臺(tái)，比如各種MOOC 課程視頻平臺(tái)；另一類是線上授課直播(Live stream)平臺(tái)，比如騰訊課堂(ke.qq.com)，課堂派(ketangpai.com)等各種偏重線上授課直播平臺(tái)。單純線上課程視頻點(diǎn)播平臺(tái)無(wú)法滿足線上授課師生實(shí)時(shí)互動(dòng)要求，所以線上授課模式通常以線上授課直播平臺(tái)為主要教學(xué)平臺(tái)以線上課程視頻點(diǎn)播平臺(tái)為輔助教學(xué)平臺(tái)。線上授課直播過(guò)程中，學(xué)生經(jīng)常會(huì)抱怨線上直播音視頻卡頓，播放視頻分辨率低，直播時(shí)延大，直播音視頻不同步等幾類線上直播播放質(zhì)量問(wèn)題，這些線上直播播放質(zhì)量問(wèn)題直接影響線上授課質(zhì)量。本文通過(guò)分析網(wǎng)絡(luò)直播工作原理與線上直播平臺(tái)架構(gòu)分析決定網(wǎng)絡(luò)直播音視頻穩(wěn)定性及播放視頻分辨率等播放質(zhì)量指標(biāo)的關(guān)鍵因素及改善方法。

2 網(wǎng)絡(luò)直播工作原理與線上直播平臺(tái)架構(gòu)

網(wǎng)絡(luò)音視頻直播流程可以分為如下幾個(gè)步驟：音視頻采集→處理→編碼和封裝→推流到邊緣流媒體服務(wù)器→流媒體分發(fā)(CDN)→播放器流播放。

2.1 音視頻采集

音視頻采集是整個(gè)網(wǎng)絡(luò)音視頻直播過(guò)程的第一個(gè)環(huán)節(jié)，它從網(wǎng)絡(luò)直播源獲取原始音視頻數(shù)據(jù)，將其輸出到網(wǎng)絡(luò)直播過(guò)程的下一個(gè)環(huán)節(jié)。音視頻的采集涉及兩類數(shù)據(jù)的采集：音頻采集和圖像采集，它們分別對(duì)應(yīng)兩種完全不同的輸入源和數(shù)據(jù)格式。

音頻數(shù)據(jù)采集過(guò)程主要是通過(guò)音頻采集設(shè)備將環(huán)境中的模擬信號(hào)采集成 PCM 編碼的原始數(shù)據(jù)。音頻采集的采集源主要有microphone 陣列，系統(tǒng)音頻，以及其他設(shè)備音頻源。圖像的采集過(guò)程主要由攝像頭等設(shè)備拍攝成YUV 編碼的原始數(shù)據(jù)。視頻采集的采集源主要有攝像頭采集，屏幕視頻，及其他設(shè)備視頻源。

2.2 處理

音視頻完成采集之后得到原始數(shù)據(jù)。根據(jù)用戶設(shè)置，在處理階段對(duì)原始音視頻數(shù)據(jù)做相應(yīng)處理，比如，音頻增加混音，降噪，聲音特效等處理；視頻增加時(shí)間戳，水印，濾鏡等處理。

2.3 編碼和封裝

經(jīng)過(guò)處理的音視頻原始數(shù)據(jù)，數(shù)據(jù)量非常大，一個(gè)時(shí)長(zhǎng)10 秒鐘的1080p 視頻，可達(dá)到1.1Gigabyte。受網(wǎng)絡(luò)帶寬限制，一般網(wǎng)絡(luò)直播平臺(tái)難以滿足音視頻原始數(shù)據(jù)直播傳輸?shù)募磿r(shí)性要求。因此，音視頻數(shù)據(jù)必須要進(jìn)行編碼處理。對(duì)流媒體傳輸來(lái)說(shuō)，編碼環(huán)節(jié)非常重要，它的編碼性能、編碼速度和編碼壓縮比會(huì)直接影響整個(gè)流媒體傳輸?shù)馁|(zhì)量和傳輸成本。

常見的音頻壓縮格式有，MP3，AAC，HE-AAC，Opus，F(xiàn)LAC，Vorbis(Ogg)，Speex 和AMR 等。音頻采集和編碼面臨的主要技術(shù)挑戰(zhàn)在于：時(shí)延敏感、卡頓敏感、噪聲消除（Denoise）、回聲消除（AEC）、靜音檢測(cè)（VAD）和各種混音算法等。

目前常用的視頻編碼標(biāo)準(zhǔn)有ITU-T 和ISO 發(fā)布的H.264 視頻壓縮標(biāo)準(zhǔn)。經(jīng)過(guò)H.264 編碼后的數(shù)據(jù)量可減少到原始數(shù)據(jù)量的百分之一。Google 和Cisco 開發(fā)的VP9 等編碼標(biāo)準(zhǔn)可以達(dá)到比H.264 更高的編碼壓縮比。

常見的視頻封裝格式有，MP4，3GP，AVI，MKV，WMV，MPG，VOB，F(xiàn)LV，SWF，MOV，RMVB 和WebM 等。圖像由于其直觀感受最強(qiáng)并且數(shù)據(jù)量較大，構(gòu)成了一個(gè)視頻內(nèi)容的主要部分。圖像采集和編碼面臨的主要挑戰(zhàn)在于：設(shè)備兼容性差、時(shí)延敏感、卡頓敏感等。

2.4 推流到流媒體服務(wù)器

從直播端推流到流媒體服務(wù)器，目前推送協(xié)議主要有三種：Real Networks 和Netscape 公司提出的RTSP(Real Time Streaming Protocol)，Adobe 公司提出的RTMP(Real Time Messaging Protocol)，Apple 公司提出的HLS(HTTP Live Streaming)。目前主流的流媒體傳輸協(xié)議是RTMP及其變種RTMPT/RTMPS/RTMPE 等協(xié)議。推流到邊緣流媒體服務(wù)器后，流媒體再被復(fù)制分發(fā)到內(nèi)容分發(fā)服務(wù)器系統(tǒng)(CDN)以及存儲(chǔ)服務(wù)器。

2.5 內(nèi)容分發(fā)服務(wù)器(CDN)

內(nèi)容分發(fā)服務(wù)器(CDN)的作用是負(fù)責(zé)直播流的發(fā)布和轉(zhuǎn)播分發(fā)功能。

2.6 播放器流播放

實(shí)現(xiàn)PC 端或移動(dòng)端的RTMP 或HLS 流媒體拉流，解碼，在播放器展現(xiàn)。

目前市面上集視頻采集、編碼、封裝和推流于一體的SDK 很多，有商業(yè)版SDK，也有開源的SDK，比如著名的OBS (Open Broadcaster Software)軟件。使用OBS 配置好一個(gè)支持RTMP 或HLS 的邊緣流媒體服務(wù)器URL 就可以搭建一個(gè)簡(jiǎn)單的網(wǎng)絡(luò)直播系統(tǒng)。基于前述網(wǎng)絡(luò)直播工作原理的視頻網(wǎng)絡(luò)直播平臺(tái)架構(gòu)如圖1 所示。

圖1 視頻網(wǎng)絡(luò)直播平臺(tái)架構(gòu)

線上授課直播平臺(tái)因?yàn)橛兄辈ザ伺c播放端的實(shí)時(shí)互動(dòng)要求一般設(shè)計(jì)成雙向網(wǎng)絡(luò)直播系統(tǒng)，輔以文字消息通道等功能增加實(shí)時(shí)互動(dòng)效果，整體平臺(tái)架構(gòu)仍然如圖1 所示。

3 決定線上授課直播平臺(tái)播放質(zhì)量的主要因素分析

通過(guò)分析前述網(wǎng)絡(luò)直播工作原理，我們可以看到網(wǎng)絡(luò)直播是一個(gè)環(huán)節(jié)較多的過(guò)程。決定線上授課直播平臺(tái)播放質(zhì)量的主要因素包括，直播端的受硬件限制的流媒體處理性能和網(wǎng)絡(luò)帶寬，邊緣流媒體服務(wù)器的性能和網(wǎng)絡(luò)帶寬，CDN 性能，播放端的網(wǎng)絡(luò)帶寬和受硬件限制的流媒體處理性能。

3.1 直播音視頻卡頓

1）推流端。推流端的網(wǎng)絡(luò)帶寬及穩(wěn)定性，上行帶寬不足或網(wǎng)絡(luò)抖動(dòng)導(dǎo)致的數(shù)據(jù)發(fā)送速率下降，無(wú)法達(dá)到流暢播放的幀率要求。推流端的計(jì)算性能，編碼端設(shè)置碼率幀率以及編碼檔位過(guò)高，由于硬件條件限制導(dǎo)致編碼速度變慢，無(wú)法達(dá)到流暢播放的幀率要求。

2）CDN。對(duì)于RTMP/FLV 協(xié)議，服務(wù)端默認(rèn)緩存4s 左右的數(shù)據(jù)，根據(jù)GOP（Group Of Pictures)即關(guān)鍵幀間隔大小不同會(huì)有波動(dòng)，可以通過(guò)設(shè)置該緩存時(shí)間來(lái)減少卡頓影響。對(duì)于HLS協(xié)議，HLS（m3u8）是基于小文件的TS 分片的流媒體協(xié)議，每個(gè)分片都有5s 以上的時(shí)長(zhǎng)（標(biāo)準(zhǔn)默認(rèn)是10s），分片數(shù)量一般為3-4 個(gè)，可以通過(guò)增大m3u8 分片數(shù)量來(lái)減少卡頓影響。

3）播放端。大部分播放器都有接收緩存的，緩存收滿后，才進(jìn)行解碼顯示，這部分接收緩存的大小也會(huì)影響播放的卡頓情況，可以通過(guò)增大接收緩存減少卡頓影響。

3.2 直播時(shí)延

1）推流端。編碼緩存過(guò)大，推流SDK 采用增大編碼緩存來(lái)解決上行帶寬不足導(dǎo)致的卡頓問(wèn)題。編碼端設(shè)置碼率幀率以及編碼檔位過(guò)高，由于硬件條件限制導(dǎo)致編碼延遲。減小編碼緩存，降低碼率幀率，可以降低直播時(shí)延。對(duì)于移動(dòng)端推流，iOS建議使用硬編碼，因?yàn)橛簿幋a效率高而且省電；而Android 建議您用軟編碼。

2）CDN。RTMP/FLV 協(xié)議的GOP 設(shè)置較大。HLS(m3u8)的m3u8 設(shè)置較大。減小GOP,m3u8,可以降低直播時(shí)延。

3）播放端。播放SDK 不支持快進(jìn)策略，大部分播放器都是在接收緩存收滿后，才進(jìn)行解碼顯示，這部分接收緩存的大小也會(huì)導(dǎo)致延遲。設(shè)置播放SDK 支持快進(jìn)策略，收到大于接收緩存的數(shù)據(jù)進(jìn)行丟幀快進(jìn)，可降低直播時(shí)延。

4）直播視頻分辨率低。直播視頻分辨率是由推流SDK 決定的。直播視頻分辨率并不能隨意設(shè)置，推流SDK 一般有一個(gè)適中的默認(rèn)直播分辨率。過(guò)高的直播分辨率，不僅使推流端的受硬件限制的編碼速度，網(wǎng)絡(luò)帶寬無(wú)法支持，會(huì)使CDN 分發(fā)傳輸成本高，也會(huì)使播放端的受硬件限制的解碼速率，網(wǎng)絡(luò)帶寬難以支持。

通過(guò)以上分析可以看到，直播音視頻卡頓與直播時(shí)延有逆相關(guān)關(guān)系，需要在直播播放質(zhì)量與控制直播時(shí)延之間找到平衡點(diǎn)。

3.3 直播音視頻不同步

直播的流程是用戶將視頻主動(dòng)推流到邊緣流媒體服務(wù)器進(jìn)行直播，出現(xiàn)直播音視頻不同步的情況，是因?yàn)樵谕屏?，CDN 分發(fā)，拉流播放過(guò)程中某些環(huán)節(jié)出現(xiàn)音頻的時(shí)間戳和視頻的時(shí)間戳不一致的情況?？梢酝ㄟ^(guò)重新啟動(dòng)推流或重新啟動(dòng)播放器解決。

4 結(jié)語(yǔ)

增大緩存可以改善線上直播音視頻播放質(zhì)量，但增大緩存也同時(shí)增大了傳輸時(shí)延，影響了線上授課要求的實(shí)時(shí)互動(dòng)效果，需要在線上直播音視頻播放質(zhì)量與控制時(shí)延之間找到平衡點(diǎn)。參加線上直播授課的師生了解了網(wǎng)絡(luò)直播工作原理與線上授課直播平臺(tái)架構(gòu)，了解了決定線上授課直播平臺(tái)播放質(zhì)量的關(guān)鍵因素，教師可以更好地利用現(xiàn)有線上授課直播平臺(tái)提高線上直播授課效果；學(xué)生可以以更好的心態(tài)接受互聯(lián)網(wǎng)數(shù)據(jù)傳輸質(zhì)量的固有的不穩(wěn)定性，以及音視頻直播播放質(zhì)量受推流端硬件性能，網(wǎng)絡(luò)帶寬，CDN 分發(fā)，播放端網(wǎng)絡(luò)帶寬，硬件性能等客觀因素制約的事實(shí)，可以減少學(xué)生的焦慮和抱怨，使學(xué)生更專注于授課內(nèi)容本身提高學(xué)習(xí)效果與效率。