5步告訴你QQ音樂的完美音質是怎麼來的，播放器的祕密都在這裏

歡迎你們前往騰訊雲+社區，獲取更多騰訊海量技術實踐乾貨哦~

本文由QQ音樂技術團隊發表於雲+社區專欄

1、問題背景與分析

不久前，團隊發現其Android平臺App在播放MV視頻《鳳凰花開的路口》時，會帶有如電流聲通常的雜音，這影響了用戶體驗。 研發同窗在初步定位時，發現有以下特徵：

• Android平臺雜音問題必現；
• iOS、PC平臺能正常播放，沒有噪音。

然而，各平臺都是統一用HLS格式播放，即源頭都是同樣的。對於該問題，咱們的定位思路以下：

1. 梳理視頻播放流程；
2. 找到切入點排查。

2、播放流程概覽

分析播放流程如上圖（圖中內容從左往右），歸納其關鍵步驟以下：

1. 播放器初始化：
   • 建立讀數據線程：read_thread；
   • 建立存放audio解碼前數據的隊列：audioq；
   • 建立存放audio解碼後數據的隊列：sampq。
2. 數據讀取：
   • ①建立context；
   • ②探測協議類型：avformat_open_input；
   • ③探測媒體類型：avformat_find_stream_info；
   • ④獲取音視頻流：av_find_best_stream；
   • ⑤打開媒體解碼器：stream_component_open；
   • ⑥讀取媒體數據，得到AVPacket：av_read_frame(ic, pkt)；
   • ⑦音視頻數據分別送入audioq中；
   • 重複⑥、⑦步驟到數據完畢。
3. 音頻解碼：
   • 在audio_thread中對audioq中的數據進行decoder_decode_frame解碼；
   • 解碼後的幀AVFrame存放到sampq中；
4. 音頻播放：
   • aout_thread_n中，經過調用回調接口sdl_audio_callback，對sampq中的音頻幀數據進行解碼成PCM數據；
   • 寫入PCM數據到buffer數組，並由AudioTrack播放。

3、問題分解與切入

在梳理出播放流程後，標記出找到有可能出錯的環節，方便進行「分層定位」（圖中黃色標記）

• 播放下載文件是否有問題；
• 數據讀取是否有問題；
• 音頻解碼邏輯是否有問題；
• AudioTrack的設置是否有問題；

接下來，根據難易程度，對上述環節逐個驗證。

一、播放下載文件是否正常

把Android平臺播放的ts文件與各平臺的進行比對，發現二者同樣，該環節正常。

二、AudioTrack設置是否正常

經過日誌檢查AudioTrack如下配置參數：

• 採樣率
• 位深
• 頻道

以上參數設置的值與音頻流的相符合，該環節正常。

三、音頻解碼邏輯是否有問題

驗證解碼邏輯是否有問題，能夠經過對PCM數據進行分析來確認。 對aout_thread_n進行修改，將PCM數據額外輸出到本地，並與正常的PCM數據進行對比。

正常PCM數據頻譜圖：

異常PCM數據頻譜圖：

正常PCM數據波形圖：

異常PCM數據波形圖：

對比分析可得出：

• 從頻譜圖中看出，異常的PCM在人耳十分敏感的頻響（1000～8000Hz ）區域內的音頻數據嚴重缺失，致使「雜音問題」
• 從波形圖中看出，異常的與正常的無聲區和有聲區都吻合，若解封裝、解碼邏輯出現異常，極大概率是呈現無波動（一條直線的形式）狀況。所以能夠先大膽假設解碼、解封裝邏輯是符合預期的

若解碼邏輯正常，再結合以前已經驗證文件下載正常。能夠推測是數據讀取環節出現異常。

四、數據讀取是否有問題

經過對數據讀取的各步驟增長日誌後，發如今av_find_best_stream音頻流選擇時出現異常： ffmpeg -i 發現，該視頻ts分片有2個音頻流

經過強制分別讀取兩條音頻流數據播放，發現：

• 第一條正常播放（PCM數據正常）
• 第二條播放雜音（PCM數據異常）
• Android平臺選擇了第二條進行播放

基於此，也就驗證了在第3步中的假設是正確的。

由上分析，能夠得出結論：Android平臺選擇了第二條數據有問題的流進行播放。

4、問題根源：音頻流選擇

一、選擇方式

分析代碼，大體以下所列，av_find_best_stream函數選擇音頻流，該函數會根據2個主要參數進行選擇：

1. 各音頻流的在探測媒體類型（avformat_find_stream_info）時，額外解碼出來的幀數（選擇多的）
2. 各音頻流的比特率（選擇高的）

int av_find_best_stream(AVFormatContext *ic, enum AVMediaType type,
                        int wanted_stream_nb, int related_stream,
                        AVCodec **decoder_ret, int flags)
{
    for (i = 0; i < nb_streams; i++) {
        count = st->codec_info_nb_frames; //音頻流探測中解碼的幀數
        bitrate = avctx->bit_rate;//音頻流的比特率
        multiframe = FFMIN(5, count);
        //先比較解碼幀數，再比較音頻流比特率，誰大誰選
        if ((best_multiframe >  multiframe) ||
            (best_multiframe == multiframe && best_bitrate >  bitrate) ||
            (best_multiframe == multiframe && best_bitrate == bitrate && best_count >= count))
            continue;
        best_count   = count;
        best_bitrate = bitrate;
        best_multiframe = multiframe;
        ret          = real_stream_index;//最後選擇的流index
        best_decoder = decoder;
    }   
    return ret;
}
複製代碼

在該視頻中，咱們能夠看到：

	codec_info_nb_frames	bit_rate
audio_stream 1	38	122625
audio_stream 2	39	126375

第二條流的解碼幀數和比特率要比第一條高，所以選擇了第二條流播放

二、對比同類方案

分析了以上選擇規則後，咱們對各平臺、框架進行了選擇規則的對比：

備註：

• ExoPlayer對多音頻流的ts分片支持不完善（issue），所以測試時須要調整相關接口。但選擇規則依然以上述所示（DefaultTrackSelector）
• iOS和PC平臺採用閉源組件，所以測試時使用了**「互換兩條音頻流順序」**的方法進行測試。互換後，兩平臺都播放了雜音音頻流 ffmpeg -i INPUT_FILE -map 0:0 -map 0:2 -map 0:1 -c copy -y OUTPUT_FILE
• QuickTime一樣是閉源，互換音頻流後沒法明顯差異，經過合成第三條音頻流，來驗證是它是對全部音頻流全播放 ffmpeg -i INPUT_FILE_1 -i INPUT_FILE_2 -map 0:0 -map 0:1 -map 0:2 -map 1:0 -c copy OUTPUT_FILE

三、總結

從以上數據看到，iOS和PC平臺會默認選擇第一條流，而在Android平臺的FFmpeg和ExoPlayer會根據音頻流屬性來選擇數值更好的一條。

• 「默認選擇第一條」方案能更容易地把音源問題暴露。
• 「比較音頻流屬性」方案能更大概率地選擇質量更好的流來提高用戶體驗。

但以上2個選擇方案都沒法識別「內容異常」的音頻流。

5、問題解決方案

所以，處理該問題，須要從音源上進行修復和規避，咱們的建議是從源頭杜絕，從終端規避：

1. 編輯從新上架正常音源；
2. 短時間內增長雙音頻流的檢測上報，幫助後臺、編輯進行復查；
3. 長遠看由後臺開發工具，分別對存量視頻進行雙音頻流檢測和對增量視頻保證只轉碼單音頻流；

參考資料

• ffmpeg.org/doxygen/2.8…
• github.com/google/ExoP…
• www.jianshu.com/p/daf0a61cc…
• www.jianshu.com/p/a6a4bf59c…
• km.oa.com/articles/sh…
• codeday.me/bug/2017071…

相關閱讀

wamp2.0配置Zend Optimizer

藏匿在郵件裏的「壞小子」

打造一個我的閱讀追蹤系統

【每日課程推薦】機器學習實戰！快速入門在線廣告業務及CTR相應知識

此文已由做者受權騰訊雲+社區發佈，更多原文請點擊

搜索關注公衆號「雲加社區」，第一時間獲取技術乾貨，關注後回覆1024 送你一份技術課程大禮包！

海量技術實踐經驗，盡在雲加社區！