音視頻匯總--視頻問(wèn)題匯總

工作中經(jīng)常碰到各種音視頻問(wèn)題，特地匯總一下，方便記錄，也希望能夠幫助大家，提供一個(gè)解決的思路。廢話少說(shuō)，直接上干貨。

1. 網(wǎng)絡(luò)問(wèn)題

該問(wèn)題大概范圍為網(wǎng)絡(luò)傳輸丟包、封包、解包等問(wèn)題，

通常的解題思路是：首先查看發(fā)包是否正常，然后排查收包是否正常，排查編碼后數(shù)據(jù)是否正常等。從而不同階段判斷不同的問(wèn)題點(diǎn)，快速定位。

1.1 發(fā)包問(wèn)題

1.1.1 問(wèn)題描述

雙方通話時(shí)候卡頓，馬賽克、殘影；但是rtsp確實(shí)正常的。

1.1.2 分析原因

（1）抓包查看P幀包非常小，如下圖

工具分析：I幀和P幀數(shù)據(jù)量差好多，導(dǎo)致部分P幀解碼異常，出現(xiàn)馬賽克和殘影

（3）中間文件保存

將編碼后的數(shù)據(jù)進(jìn)行文件儲(chǔ)存，并導(dǎo)出分析，這時(shí)視頻編碼正常，播放也是OK的。

（4）到此基本上推測(cè)出來(lái)是發(fā)包的問(wèn)題，只需要發(fā)包流程排查即可，最后發(fā)現(xiàn)是發(fā)包模式不一致導(dǎo)致的

1.1.3 解決方案

因?yàn)槟J(rèn)發(fā)送方式是 kH264SingleMode， 改用mpp編碼后包變大了， 在這個(gè)模式下相關(guān)函數(shù)有閾值判斷，導(dǎo)致部分視頻幀封包時(shí)發(fā)送異常，只需要調(diào)整對(duì)應(yīng)的值即可。

// Used for NACK and to spread out the transmission of packets.
if (_packetHistory->PutRTPPacket(buffer, rtp_header_length + payload_length,
1800, capture_time_ms, storage) != 0) {
_ return -1;
}

if (packet_length > max_packet_length_) {
WEBRTC_TRACE(kTraceError, kTraceRtpRtcp, -1,
"Failed to store RTP packet, length: %d", packet_length);
return -1;
}

1.2 發(fā)包問(wèn)題

1.2.1 問(wèn)題描述

由于iOS發(fā)包將SPS和PPS整合成stap-a方式發(fā)送，而舊的代碼中該部分處理有問(wèn)題，導(dǎo)致和iOS通話時(shí)有問(wèn)題：

stap-a解包時(shí)，分別進(jìn)行存儲(chǔ)，然后再按照單獨(dú)的nalu單元分別送jitterbuffer。

stap-a中nalu單元分開(kāi)存儲(chǔ)

1.2.2 分析原因

1.2.2.1 分析原因1—封包模式

實(shí)際場(chǎng)景中如果不開(kāi)啟NACK，直接送解碼端是正常播放的，原因是：即使序列號(hào)重新計(jì)算了，但是由于時(shí)間戳和后面的I幀是一致的，因此仍然能夠和后面的I幀拼接成一個(gè)完整的幀送解碼端，這樣可以完成解碼。

但是一旦有丟包、如果開(kāi)啟NACK，由于序列號(hào)的不一致，同時(shí)I幀不完整，這時(shí)候該方案中的I幀就無(wú)法送到解碼端進(jìn)行解碼，也就出現(xiàn)之前不開(kāi)啟NACK可以播放，但是開(kāi)啟NACK無(wú)法播放的原因。

舉例：之前方案方案數(shù)據(jù)打印如下圖，當(dāng)前SPS和PPS重新計(jì)算為44和45，但是I幀的序列號(hào)為29336。一旦由丟包，同時(shí)啟動(dòng)NACK后，SPS和PPS在jitterbuffer中就沒(méi)有辦法和I幀進(jìn)行序列號(hào)排序，這樣這些參數(shù)無(wú)法送達(dá)解碼端，也就沒(méi)有辦法解碼了。

1.2.2.2 分析原因2--NACK整改后

在整改NACK時(shí)，引入STAP-A包封轉(zhuǎn)不處理的方式，但是NALU解包流程沒(méi)有修改，同時(shí)由于NALU單元需要插入起始碼（即 0x00 00 00 01），但是舊的解包流程中這部分處理送jitterbuffer前就插入了一個(gè)起始碼，在后面單獨(dú)處理STAP-A包時(shí)，又重新插入一個(gè)起始碼，導(dǎo)致送解碼端數(shù)據(jù)異常，這時(shí)當(dāng)時(shí)bink解決思路中碰到的問(wèn)題。

1.2.3 解決辦法

1.2.3.1 解決方案1

第一輪解決時(shí)，已經(jīng)發(fā)現(xiàn)SPS和PPS重新計(jì)算序列號(hào)的問(wèn)題了，為了規(guī)避這個(gè)問(wèn)題，嘗試一個(gè)騷操作，[捂臉]

，就是將SPS和PPS單獨(dú)出來(lái)后，將SPS序列號(hào)手動(dòng)減一（借用上一個(gè)P幀中最后一個(gè)包的序列號(hào)），這樣和后面I幀的數(shù)據(jù)就保持一致了，同時(shí)將PPS設(shè)置mark標(biāo)志位，這樣將SPS和PPS單獨(dú)送解碼端，這樣處理可以規(guī)避NACK請(qǐng)求時(shí)序列號(hào)不一致的問(wèn)題。但是該方案時(shí)有風(fēng)險(xiǎn)的。

如果當(dāng)前丟包正好時(shí)SPS和PPS的stap-a包，這時(shí)請(qǐng)求就會(huì)異常了。

如果上一個(gè)P幀中最后一個(gè)序列號(hào)丟包，也會(huì)出現(xiàn)異常。

1.2.3.3 解決方案2

借鑒iOS對(duì)于stap-a的處理方式，同時(shí)沿用之前的解包方式，最終方案能夠滿足現(xiàn)在的需求。

解包時(shí)判斷如果時(shí)stap-a包，則不做處理，在jitterbuffer insertbuffer時(shí)候再做對(duì)應(yīng)的處理；

stap-a包不插入起始碼，如果時(shí)其他的封包方式，沿用之前的處理流程。

1.3 丟包問(wèn)題

1.3.1 丟包現(xiàn)象

丟包就是由于網(wǎng)絡(luò)環(huán)境問(wèn)題導(dǎo)致部分?jǐn)?shù)據(jù)包無(wú)法正常送達(dá)接收端，接收端不能正確接收到對(duì)應(yīng)數(shù)據(jù)，則認(rèn)為該視頻幀不完整，要么直接丟棄，要么送解碼器，以馬賽克或者不完整的視頻幀形式展現(xiàn)出來(lái)。造成視頻卡頓、馬賽克、半視頻幀、綠屏、黑屏等現(xiàn)象。

目前很多sdk都支持NACK、FEC等方案來(lái)對(duì)抗丟包現(xiàn)象，特別是邊緣節(jié)點(diǎn)、網(wǎng)絡(luò)切換（從wifi切換到4G，從4G切換到wifi，從5G切換到4G，或者切換到更差的網(wǎng)絡(luò)）。

這部分的具體解決方案就是采用更加豐富、更加健全的弱網(wǎng)對(duì)抗方案，以滿足接收端盡可能多的獲取到數(shù)據(jù)。

可以參考

2 編碼問(wèn)題

2.1 熵編碼

2.1.1 問(wèn)題現(xiàn)象

由于新平臺(tái)與客戶話機(jī)通話時(shí)，無(wú)法正常解碼，排查原因后發(fā)現(xiàn)是因?yàn)榫幋a參數(shù)的不一致導(dǎo)致的。

2.1.2 分析原因和解決方案

參考

H264中熵編碼主要采用兩種類型：CAVLA和CABAC。但是部分硬件廠商支持程度不一致導(dǎo)致無(wú)法兼容

2.2 新codec支持

2.2.1 問(wèn)題描述

該類問(wèn)題主要是新的codec 在現(xiàn)有的系統(tǒng)中不支持，或者支持度不夠，需要增加新的支持

2.2.2 分析原因

freeswitch不支持H263轉(zhuǎn)碼，導(dǎo)致視頻通話，選H263時(shí)視頻協(xié)商失敗

2.2.3 解決方案

該類型問(wèn)題，一般要增加對(duì)應(yīng)的支持，包括不限于SIP模塊（sip和ip）、webrtc、FFMPEG（軟解）、VPU庫(kù)（硬件庫(kù)）等。

2.3 時(shí)間戳問(wèn)題

2.3.1 問(wèn)題描述

客戶反饋之前是畫面卡頓嚴(yán)重，起初分析為分辨率太高4K，CPU帶不動(dòng)，解決的辦法為調(diào)低分辨率，或者使用硬解，現(xiàn)在采用了調(diào)低分辨率的辦法，仍然會(huì)浮現(xiàn)問(wèn)題。

客戶反饋問(wèn)題：

視頻通話中，出現(xiàn)兩次卡頓，大概都會(huì)卡2秒，本地復(fù)現(xiàn)，發(fā)現(xiàn)建立視頻后，在4秒左右，會(huì)有2秒時(shí)間的卡頓，且一直都有，搭環(huán)境處理，這邊將環(huán)境記錄。

2.3.2 分析原因

查看VLC源碼，是在解碼的時(shí)候修正pts時(shí)間戳出問(wèn)題的，

2.3.3 解決方法

由于該時(shí)間戳是客戶攝像頭發(fā)送過(guò)來(lái)已經(jīng)異常，會(huì)有一個(gè)跳變的過(guò)程，導(dǎo)致顯示異常，或者修改vlc源碼，兼容這種跳變的時(shí)間戳，但是對(duì)應(yīng)的工作量增加，為了不影響客戶使用，只能像客戶說(shuō)明原因，并修改攝像頭部分參數(shù)以滿足客戶的需求。

3 錄制相關(guān)

3.1 錄制后音畫不同步

3.1.1 問(wèn)題描述

通過(guò)app錄制通話的視頻后，發(fā)現(xiàn)錄制的內(nèi)容，比較容易出現(xiàn)音畫不同步現(xiàn)象。

3.1.2 分析原因

通過(guò)錄制后的視頻排查，以及代碼分析，該問(wèn)題是由于寫文件時(shí)音頻文件盒視頻文件分別啟用兩個(gè)線程，按照AVI的文件格式單獨(dú)寫數(shù)據(jù)。每寫一幀視頻幀的時(shí)間大概是33ms，每寫一陣音頻幀時(shí)間大概是10ms，由于數(shù)據(jù)匹配過(guò)程中寫時(shí)間戳的過(guò)程出現(xiàn)偏差，導(dǎo)致寫入的音視頻數(shù)據(jù)并沒(méi)有按照具體時(shí)間間隔進(jìn)行寫入，因此出現(xiàn)音畫不同步現(xiàn)象。

3.1.3 解決方案

在分別開(kāi)啟音頻線程和視頻線程時(shí)，一定要計(jì)算好相關(guān)的時(shí)間間隔，并嚴(yán)格按照時(shí)間間隔進(jìn)行寫入音視頻文件，在播放端就不會(huì)出現(xiàn)異常了。

持續(xù)更新中。。。