1. 從視頻到音頻為什么播放器的另一半才是真正的硬骨頭很多人做播放器Demo的時候習(xí)慣先把視頻畫面跑通看到窗口里能出畫面了就覺得大功告成。但真正做過完整播放器的人都知道音頻這條鏈路才是最容易翻車的地方。視頻丟幾幀你可能肉眼根本察覺不到但音頻只要緩沖區(qū)管理稍微出點偏差立刻就是刺耳的爆音、卡頓或者音畫不同步。我見過不少項目視頻渲染做得漂漂亮亮結(jié)果一播放聲音就像老式收音機搜不到臺一樣滋啦滋啦響個不停。這個項目標(biāo)題說的是“QT FFMPEG實現(xiàn)基本播放器”的第四篇聚焦在音頻播放實現(xiàn)上。前面幾篇大概率已經(jīng)把解封裝、視頻解碼、視頻渲染這些環(huán)節(jié)跑通了現(xiàn)在輪到音頻這塊。QT負(fù)責(zé)界面和事件循環(huán)FFMPEG負(fù)責(zé)解封裝和解碼這兩者的組合算是桌面端播放器開發(fā)里最經(jīng)典的搭配之一。但經(jīng)典不代表簡單音頻播放涉及的東西比視頻要多得多——采樣率、聲道布局、采樣格式、重采樣、音頻緩沖區(qū)管理、設(shè)備回調(diào)機制每一個環(huán)節(jié)都有坑。這篇文章適合誰看如果你已經(jīng)用QT和FFMPEG搭出了一個能播視頻的框架現(xiàn)在想把它補全成真正能用的播放器那這篇就是寫給你的。如果你還沒接觸過FFMPEG建議先把解封裝和解碼的基礎(chǔ)過一遍再來看音頻部分不然可能會有點吃力。我會把音頻播放的完整鏈路拆開從解碼后的原始音頻數(shù)據(jù)一直講到怎么讓它從揚聲器里出來中間涉及的重采樣、緩沖區(qū)設(shè)計、線程同步這些關(guān)鍵點都會給出可直接參考的實現(xiàn)思路。先說一個核心結(jié)論音頻播放的本質(zhì)就是把解碼出來的PCM數(shù)據(jù)按照正確的時間節(jié)奏源源不斷地喂給音頻設(shè)備。聽起來很簡單對吧但“正確的時間節(jié)奏”這六個字里面藏著大量的工程細(xì)節(jié)。喂快了緩沖區(qū)溢出聲音會斷斷續(xù)續(xù)喂慢了緩沖區(qū)餓死同樣會卡頓。而且音頻設(shè)備通常有自己的時鐘你的解碼線程有另一個時鐘這兩個時鐘如果不同步播放時間一長就會累積誤差最終導(dǎo)致音畫不同步或者聲音變調(diào)。2. 音頻播放鏈路的整體設(shè)計思路2.1 為什么不能直接拿解碼后的數(shù)據(jù)去播放FFMPEG解碼出來的音頻數(shù)據(jù)格式是不確定的。它可能是AAC解碼出來的浮點數(shù)據(jù)也可能是MP3解碼出來的16位整型數(shù)據(jù)采樣率可能是44100Hz也可能是48000Hz聲道數(shù)可能是單聲道也可能是5.1環(huán)繞聲。而音頻設(shè)備對輸入格式是有明確要求的比如大部分聲卡只接受S16LE16位有符號整型小端序格式、44100Hz或48000Hz采樣率、雙聲道的數(shù)據(jù)。這就意味著解碼后的數(shù)據(jù)幾乎不可能直接丟給音頻設(shè)備去播。中間必須經(jīng)過一個格式轉(zhuǎn)換的環(huán)節(jié)也就是重采樣。FFMPEG提供了swresample庫專門做這件事它能把任意格式的音頻數(shù)據(jù)轉(zhuǎn)換成目標(biāo)設(shè)備需要的格式。這個環(huán)節(jié)是必須的不是可選的。我剛開始做的時候想過一個偷懶的辦法能不能讓音頻設(shè)備去適配解碼器的輸出格式理論上可以但實際操作中你會發(fā)現(xiàn)不同文件的解碼輸出格式千差萬別你不可能為每種格式都去協(xié)商設(shè)備參數(shù)。而且音頻設(shè)備打開后格式就固定了中途切換格式意味著要關(guān)閉再重新打開設(shè)備這會造成明顯的播放中斷。所以統(tǒng)一轉(zhuǎn)成一種固定格式是唯一靠譜的做法。2.2 音頻緩沖區(qū)的設(shè)計哲學(xué)音頻播放和視頻渲染最大的區(qū)別在于視頻是“拉”模式音頻是“推”模式。視頻渲染是你主動去畫一幀畫完就完事什么時候畫下一幀由你的主循環(huán)決定。但音頻設(shè)備是持續(xù)運行的它需要一個穩(wěn)定的數(shù)據(jù)流你不能今天喂一口明天喂一口它需要你按照固定的節(jié)奏持續(xù)供給。所以音頻播放的核心就是一個生產(chǎn)者-消費者模型。解碼線程是生產(chǎn)者負(fù)責(zé)把解碼和重采樣后的PCM數(shù)據(jù)放進緩沖區(qū)音頻設(shè)備回調(diào)是消費者負(fù)責(zé)從緩沖區(qū)里取數(shù)據(jù)送給聲卡。這個緩沖區(qū)的大小設(shè)計非常關(guān)鍵太小了容易餓死導(dǎo)致卡頓太大了會導(dǎo)致延遲增加而且一旦出現(xiàn)音畫不同步的問題調(diào)整起來會非常遲鈍。我的經(jīng)驗是緩沖區(qū)大小控制在200ms到500ms的音頻數(shù)據(jù)量比較合適。以44100Hz、雙聲道、16位采樣為例每秒的數(shù)據(jù)量是44100 × 2 × 2 176400字節(jié)。200ms就是35280字節(jié)大約35KB。這個量級的緩沖區(qū)既能保證播放的流暢性又不會引入太明顯的延遲。當(dāng)然具體數(shù)值還要根據(jù)實際場景調(diào)整比如如果是本地文件播放緩沖區(qū)可以小一點降低延遲如果是網(wǎng)絡(luò)流播放緩沖區(qū)就要大一點來對抗網(wǎng)絡(luò)抖動。2.3 線程模型的選擇QT和FFMPEG結(jié)合做播放器線程模型的設(shè)計直接決定了整個系統(tǒng)的穩(wěn)定性和復(fù)雜度。常見的方案有三種第一種是全部放在主線程用QTimer定時去驅(qū)動解碼和播放。這種方案最簡單但問題也最大——主線程還要處理UI事件一旦UI卡頓音頻就會跟著卡。而且音頻設(shè)備回調(diào)通常在自己的線程里跨線程操作緩沖區(qū)需要加鎖在主線程里做重活容易導(dǎo)致鎖競爭。第二種是解碼在一個獨立線程音頻設(shè)備回調(diào)在它自己的線程兩者通過線程安全的環(huán)形緩沖區(qū)通信。這是最經(jīng)典的方案也是我推薦的做法。解碼線程只管往緩沖區(qū)里寫數(shù)據(jù)音頻回調(diào)只管從緩沖區(qū)里讀數(shù)據(jù)兩者通過讀寫指針來同步不需要頻繁加鎖。第三種是解碼和音頻輸出都在同一個線程用阻塞式的音頻API來播放。這種方案在某些平臺上可行但在QT里不太合適因為QT的事件循環(huán)和音頻設(shè)備的阻塞調(diào)用容易互相干擾。我最終采用的是第二種方案一個獨立的解碼線程負(fù)責(zé)解封裝、解碼、重采樣然后把PCM數(shù)據(jù)寫入環(huán)形緩沖區(qū)音頻設(shè)備通過回調(diào)函數(shù)從環(huán)形緩沖區(qū)讀取數(shù)據(jù)。環(huán)形緩沖區(qū)用原子操作來管理讀寫指針避免加鎖帶來的性能開銷。3. 核心細(xì)節(jié)拆解從AVFrame到揚聲器3.1 音頻解碼的基本流程音頻解碼的流程和視頻解碼類似但有幾個關(guān)鍵區(qū)別。視頻解碼你只需要拿到AVFrame里的像素數(shù)據(jù)音頻解碼你還需要關(guān)注采樣格式、采樣率、聲道布局這些參數(shù)。整個流程大致是這樣的首先從AVPacket里拿到壓縮的音頻數(shù)據(jù)送進解碼器得到AVFrame。這個AVFrame里的data數(shù)組存放的就是PCM數(shù)據(jù)但格式是解碼器輸出的原始格式。然后你需要把這個AVFrame送進SwrContext進行重采樣得到目標(biāo)格式的PCM數(shù)據(jù)。最后把重采樣后的數(shù)據(jù)寫入環(huán)形緩沖區(qū)等待音頻設(shè)備回調(diào)來取。這里有一個容易忽略的點音頻解碼器有時候會輸出多個AVFrame對應(yīng)一個AVPacket尤其是AAC這種格式。所以你不能假設(shè)一個packet進去就一個frame出來需要循環(huán)調(diào)用avcodec_receive_frame直到返回AVERROR(EAGAIN)為止。這個細(xì)節(jié)如果處理不好會導(dǎo)致音頻數(shù)據(jù)丟失表現(xiàn)出來就是聲音斷斷續(xù)續(xù)或者有規(guī)律的卡頓。3.2 SwrContext的初始化與參數(shù)配置SwrContext是重采樣的核心它的初始化需要明確輸入和輸出兩端的參數(shù)。輸入?yún)?shù)從解碼器的AVCodecContext里獲取包括采樣率、采樣格式、聲道布局。輸出參數(shù)根據(jù)音頻設(shè)備的能力來定通常選擇S16LE、44100Hz或48000Hz、立體聲。初始化的時候有一個關(guān)鍵點聲道布局要用AVChannelLayout而不是舊的channel_layout整數(shù)。新版本的FFMPEG已經(jīng)廢棄了舊的channel_layout字段如果你還在用舊接口編譯的時候會有一堆警告而且未來版本可能會直接移除。正確的做法是用av_channel_layout_default或者av_channel_layout_copy來設(shè)置聲道布局。重采樣參數(shù)的配置代碼大概長這樣SwrContext *swr_ctx nullptr; AVChannelLayout out_ch_layout; av_channel_layout_default(out_ch_layout, 2); // 立體聲 swr_alloc_set_opts2(swr_ctx, out_ch_layout, AV_SAMPLE_FMT_S16, 44100, // 輸出參數(shù) codec_ctx-ch_layout, codec_ctx-sample_fmt, codec_ctx-sample_rate, // 輸入?yún)?shù) 0, nullptr); swr_init(swr_ctx);這段代碼里swr_alloc_set_opts2是新的接口比舊的swr_alloc_set_opts多了聲道布局的結(jié)構(gòu)體參數(shù)。初始化完成后每次重采樣之前還需要計算輸出樣本數(shù)用av_rescale_rnd來做時間基的轉(zhuǎn)換。3.3 環(huán)形緩沖區(qū)的實現(xiàn)要點環(huán)形緩沖區(qū)是音頻播放的核心數(shù)據(jù)結(jié)構(gòu)它的設(shè)計直接影響到播放的流暢度和延遲。我采用的是單生產(chǎn)者單消費者的無鎖環(huán)形緩沖區(qū)用原子變量來管理讀寫位置。緩沖區(qū)的大小需要是2的冪次方這樣可以用位運算來代替取模運算提高效率。比如設(shè)置緩沖區(qū)大小為65536字節(jié)那么寫入位置的計算就是(write_pos len) (size - 1)。讀寫位置的更新用std::atomic來保證原子性避免加鎖。有一個細(xì)節(jié)需要注意緩沖區(qū)的“滿”和“空”的判斷。當(dāng)寫指針等于讀指針時緩沖區(qū)是空的當(dāng)寫指針加一等于讀指針時緩沖區(qū)是滿的。這意味著緩沖區(qū)實際可用的空間比總大小少一個字節(jié)。對于音頻數(shù)據(jù)來說這個字節(jié)的浪費完全可以接受。寫入數(shù)據(jù)的時候如果緩沖區(qū)剩余空間不夠可以選擇等待或者丟棄。我的做法是等待因為音頻數(shù)據(jù)丟棄會導(dǎo)致聲音斷裂而等待最多只會造成短暫的延遲。但等待不能無限等需要設(shè)置一個超時避免解碼線程被永久阻塞。3.4 音頻設(shè)備回調(diào)的實現(xiàn)QT里播放音頻通常用QAudioSinkQt6或QAudioOutputQt5。這兩個類都支持推送模式和拉取模式我推薦用拉取模式也就是設(shè)置一個QIODevice讓音頻設(shè)備主動從里面讀數(shù)據(jù)。具體做法是繼承QIODevice重寫readData和writeData方法。readData方法里從環(huán)形緩沖區(qū)讀取數(shù)據(jù)writeData方法里往環(huán)形緩沖區(qū)寫入數(shù)據(jù)。然后把QAudioSink的start方法傳入這個QIODevice的指針音頻設(shè)備就會在需要數(shù)據(jù)的時候自動調(diào)用readData。這里有一個坑readData的返回值必須是實際讀取的字節(jié)數(shù)如果緩沖區(qū)里沒有足夠的數(shù)據(jù)應(yīng)該返回0而不是阻塞等待。返回0會讓音頻設(shè)備進入空閑狀態(tài)等下次有數(shù)據(jù)的時候再繼續(xù)讀。如果你在readData里阻塞等待會導(dǎo)致音頻設(shè)備的回調(diào)線程被卡住整個播放都會出問題。4. 完整實操流程從零搭建音頻播放模塊4.1 環(huán)境準(zhǔn)備與依賴配置在開始寫代碼之前需要確保FFMPEG的開發(fā)庫已經(jīng)正確安裝。Windows下可以用vcpkg或者自己編譯Linux下用包管理器安裝libavcodec-dev、libavformat-dev、libswresample-dev這些開發(fā)包。QT這邊需要確保Multimedia模塊已經(jīng)啟用在.pro文件里加上QT multimedia。FFMPEG的版本建議用5.0以上因為新版本的聲道布局API和舊版本差異比較大用新版本可以避免很多兼容性問題。如果用的是4.x版本需要注意channel_layout相關(guān)的接口還是舊的代碼需要做相應(yīng)的適配。編譯的時候有一個常見的坑FFMPEG的庫文件順序。鏈接器對庫的順序是有要求的libavformat依賴libavcodeclibavcodec依賴libswresample所以鏈接順序應(yīng)該是-lavformat -lavcodec -lswresample。如果順序反了會出現(xiàn)undefined reference的錯誤。4.2 音頻解碼線程的實現(xiàn)解碼線程的核心邏輯是一個循環(huán)從AVFormatContext里讀取AVPacket判斷是不是音頻流送進解碼器拿到AVFrame重采樣寫入環(huán)形緩沖區(qū)。void AudioDecoder::run() { while (!m_stop) { AVPacket *pkt av_packet_alloc(); int ret av_read_frame(m_fmtCtx, pkt); if (ret 0) break; if (pkt-stream_index m_audioStreamIndex) { ret avcodec_send_packet(m_codecCtx, pkt); if (ret 0) { av_packet_free(pkt); continue; } while (true) { AVFrame *frame av_frame_alloc(); ret avcodec_receive_frame(m_codecCtx, frame); if (ret AVERROR(EAGAIN) || ret AVERROR_EOF) { av_frame_free(frame); break; } // 重采樣并寫入緩沖區(qū) resampleAndWrite(frame); av_frame_free(frame); } } av_packet_free(pkt); } }這段代碼里av_read_frame返回小于0表示文件讀完了或者出錯了需要跳出循環(huán)。avcodec_send_packet和avcodec_receive_frame的返回值需要仔細(xì)處理EAGAIN表示需要更多數(shù)據(jù)EOF表示解碼器已經(jīng)刷完了。重采樣的時候需要計算輸出樣本數(shù)int out_samples av_rescale_rnd( swr_get_delay(swr_ctx, codec_ctx-sample_rate) frame-nb_samples, 44100, codec_ctx-sample_rate, AV_ROUND_UP);這個計算考慮了重采樣器的內(nèi)部延遲確保輸出樣本數(shù)足夠容納所有輸入數(shù)據(jù)。如果計算少了會導(dǎo)致部分音頻數(shù)據(jù)丟失。4.3 環(huán)形緩沖區(qū)的代碼實現(xiàn)環(huán)形緩沖區(qū)的實現(xiàn)需要保證線程安全我用的是原子操作加內(nèi)存屏障的方式。核心代碼如下class RingBuffer { public: bool write(const uint8_t *data, size_t len) { size_t w m_write.load(std::memory_order_relaxed); size_t r m_read.load(std::memory_order_acquire); size_t available (r - w - 1 m_size) (m_size - 1); if (len available) return false; size_t first std::min(len, m_size - (w (m_size - 1))); memcpy(m_buffer (w (m_size - 1)), data, first); if (len first) { memcpy(m_buffer, data first, len - first); } m_write.store(w len, std::memory_order_release); return true; } size_t read(uint8_t *data, size_t len) { size_t r m_read.load(std::memory_order_relaxed); size_t w m_write.load(std::memory_order_acquire); size_t available (w - r m_size) (m_size - 1); len std::min(len, available); size_t first std::min(len, m_size - (r (m_size - 1))); memcpy(data, m_buffer (r (m_size - 1)), first); if (len first) { memcpy(data first, m_buffer, len - first); } m_read.store(r len, std::memory_order_release); return len; } private: std::vectoruint8_t m_buffer; size_t m_size; std::atomicsize_t m_write{0}; std::atomicsize_t m_read{0}; };這里用memory_order_acquire和memory_order_release來保證讀寫指針的可見性。寫入數(shù)據(jù)后更新寫指針用release語義讀取寫指針用acquire語義這樣可以確保數(shù)據(jù)在指針更新之前已經(jīng)寫入內(nèi)存。4.4 音頻設(shè)備回調(diào)的對接QIODevice的readData方法里從環(huán)形緩沖區(qū)讀取數(shù)據(jù)qint64 AudioDevice::readData(char *data, qint64 maxlen) { size_t bytesRead m_ringBuffer-read( reinterpret_castuint8_t*(data), static_castsize_t(maxlen)); return static_castqint64(bytesRead); }writeData方法里往環(huán)形緩沖區(qū)寫入數(shù)據(jù)但通常音頻播放不需要寫入所以可以直接返回0。然后創(chuàng)建QAudioSink并啟動QAudioFormat format; format.setSampleRate(44100); format.setChannelCount(2); format.setSampleFormat(QAudioFormat::Int16); QAudioSink *audioSink new QAudioSink(format, this); audioSink-start(m_audioDevice);這里有一個關(guān)鍵點QAudioFormat的采樣格式要和SwrContext的輸出格式一致。如果SwrContext輸出的是S16LEQAudioFormat就要設(shè)置成Int16。如果格式不匹配播放出來的聲音會是噪音。5. 常見問題與排查技巧實錄5.1 聲音卡頓、斷斷續(xù)續(xù)這是最常見的問題原因通常有三個緩沖區(qū)太小、解碼速度跟不上、或者音頻設(shè)備回調(diào)讀取數(shù)據(jù)不及時。排查的時候可以先看緩沖區(qū)的水位。如果緩沖區(qū)經(jīng)常處于接近空的狀態(tài)說明解碼速度不夠需要優(yōu)化解碼邏輯或者增大緩沖區(qū)。如果緩沖區(qū)經(jīng)常是滿的說明音頻設(shè)備讀取太慢可能是回調(diào)線程被阻塞了。我遇到過一次比較隱蔽的情況解碼線程和音頻回調(diào)線程的優(yōu)先級設(shè)置不當(dāng)導(dǎo)致解碼線程被頻繁搶占緩沖區(qū)一直處于饑餓狀態(tài)。解決辦法是把解碼線程的優(yōu)先級調(diào)高或者把音頻回調(diào)的緩沖區(qū)調(diào)大一些。5.2 聲音變調(diào)、播放速度不對這通常是采樣率不匹配導(dǎo)致的。比如解碼器輸出的是48000Hz但音頻設(shè)備設(shè)置的是44100Hz如果不做重采樣直接播放聲音就會變慢變調(diào)。檢查的方法是打印SwrContext的輸入和輸出采樣率確認(rèn)兩者是否一致。如果不一致需要檢查swr_alloc_set_opts2的參數(shù)是否正確。另外av_rescale_rnd的計算也要檢查輸出樣本數(shù)算錯了也會導(dǎo)致播放速度異常。5.3 音畫不同步音畫不同步是播放器開發(fā)中最頭疼的問題之一。音頻和視頻有各自的時間基如果兩者沒有對齊就會出現(xiàn)聲音和畫面不一致的情況。我的做法是以音頻時鐘為基準(zhǔn)視頻渲染的時候根據(jù)音頻時鐘來調(diào)整。具體來說音頻播放的時候記錄已經(jīng)播放的樣本數(shù)換算成時間戳作為主時鐘。視頻渲染的時候比較當(dāng)前幀的PTS和主時鐘的差值如果視頻超前了就等待如果落后了就丟幀或者加速渲染。這個同步策略不是唯一的也有以視頻時鐘為基準(zhǔn)的方案但音頻對時間更敏感以音頻為基準(zhǔn)通常效果更好。5.4 播放結(jié)束后有雜音播放結(jié)束的時候如果直接關(guān)閉音頻設(shè)備緩沖區(qū)里殘留的數(shù)據(jù)可能會被突然截斷產(chǎn)生一個脈沖信號聽起來就是“啪”的一聲。解決辦法是在播放結(jié)束前先停止往緩沖區(qū)寫數(shù)據(jù)等緩沖區(qū)里的數(shù)據(jù)全部播放完畢后再關(guān)閉設(shè)備?？梢栽诃h(huán)形緩沖區(qū)里加一個結(jié)束標(biāo)志當(dāng)讀到結(jié)束標(biāo)志且緩沖區(qū)為空時再調(diào)用audioSink-stop()。5.5 常見問題速查表問題現(xiàn)象可能原因排查方法解決方案聲音卡頓緩沖區(qū)太小觀察緩沖區(qū)水位增大緩沖區(qū)到200-500ms聲音變調(diào)采樣率不匹配打印輸入輸出采樣率檢查SwrContext參數(shù)音畫不同步時鐘未對齊對比音頻和視頻時間戳以音頻時鐘為基準(zhǔn)同步播放結(jié)束有雜音緩沖區(qū)數(shù)據(jù)被截斷檢查關(guān)閉流程等緩沖區(qū)播完再關(guān)閉設(shè)備完全沒聲音格式不匹配檢查QAudioFormat確保與SwrContext輸出一致聲音有回聲緩沖區(qū)數(shù)據(jù)重復(fù)檢查讀寫指針確認(rèn)讀寫指針更新正確5.6 幾個我踩過的坑第一個坑是avcodec_receive_frame的循環(huán)沒有正確處理。我一開始只調(diào)用了一次以為一個packet對應(yīng)一個frame結(jié)果AAC音頻丟了很多幀聲音斷斷續(xù)續(xù)。后來改成循環(huán)調(diào)用直到EAGAIN才解決。第二個坑是環(huán)形緩沖區(qū)的內(nèi)存屏障。我一開始用relaxed語義在單線程測試的時候沒問題但多線程跑起來偶爾會出現(xiàn)數(shù)據(jù)錯亂。后來改成acquire/release語義就穩(wěn)定了。這個問題的隱蔽性很強因為出錯的概率不高但一旦出現(xiàn)就很難排查。第三個坑是QAudioSink的緩沖區(qū)大小設(shè)置。QAudioSink默認(rèn)的緩沖區(qū)大小可能不適合所有場景可以通過setBufferSize來調(diào)整。我一開始沒設(shè)置結(jié)果在某些機器上延遲特別大后來設(shè)置成固定值就正常了。第四個坑是重采樣器的flush。播放結(jié)束的時候SwrContext內(nèi)部可能還有緩存的樣本沒有輸出需要調(diào)用swr_convert傳入nullptr來flush。如果忘了這一步最后一段音頻會丟失。6. 性能優(yōu)化與擴展思路6.1 減少內(nèi)存拷貝音頻數(shù)據(jù)從解碼到播放中間會經(jīng)過多次拷貝解碼器輸出到AVFrame是一次重采樣到輸出緩沖區(qū)是一次寫入環(huán)形緩沖區(qū)是一次音頻設(shè)備讀取是一次。每次拷貝都會消耗CPU時間對于高采樣率的音頻來說這些開銷累積起來不容忽視。優(yōu)化的思路是盡量減少中間緩沖區(qū)。比如重采樣的時候可以直接輸出到環(huán)形緩沖區(qū)的可寫區(qū)域避免一次額外的拷貝。不過這需要環(huán)形緩沖區(qū)支持“預(yù)留空間”的操作實現(xiàn)起來會復(fù)雜一些。另一個優(yōu)化點是使用內(nèi)存池來管理AVFrame和AVPacket避免頻繁的alloc和free。FFMPEG提供了av_frame_alloc和av_packet_alloc但每次調(diào)用都有開銷?？梢灶A(yù)先分配一組frame和packet循環(huán)使用減少內(nèi)存分配的次數(shù)。6.2 支持多種音頻格式目前的實現(xiàn)只支持S16LE格式如果需要支持浮點格式或者24位格式需要修改SwrContext的輸出參數(shù)和QAudioFormat的設(shè)置。QT的QAudioFormat支持UInt8、Int16、Int32、Float等格式可以根據(jù)需要選擇。如果要做音頻特效比如均衡器或者音量調(diào)節(jié)可以在重采樣之后加一個處理環(huán)節(jié)。音量調(diào)節(jié)最簡單直接把PCM樣本乘以一個系數(shù)就行。但要注意防止溢出16位整型的范圍是-32768到32767乘以系數(shù)后如果超出范圍需要做截斷處理。6.3 音頻時鐘的精確管理音頻時鐘的精度直接影響到音畫同步的效果。我的做法是記錄已經(jīng)寫入環(huán)形緩沖區(qū)的總樣本數(shù)減去緩沖區(qū)里還未播放的樣本數(shù)得到實際已經(jīng)播放的樣本數(shù)再除以采樣率就是當(dāng)前音頻時間。這個計算需要考慮到音頻設(shè)備的延遲。QAudioSink提供了processedUSecs()方法可以獲取已經(jīng)處理的微秒數(shù)用這個值來計算音頻時鐘會更準(zhǔn)確。但要注意processedUSecs()的更新頻率可能不夠高需要結(jié)合樣本數(shù)來計算。6.4 后續(xù)可以擴展的方向這個音頻播放模塊目前只做了最基本的播放功能后續(xù)可以擴展的方向很多。比如加上音量控制、靜音切換、音頻軌道切換、變速播放等功能。變速播放需要修改重采樣的輸出采樣率同時調(diào)整視頻的播放速度來保持同步。如果要做音頻可視化可以在音頻回調(diào)里獲取PCM數(shù)據(jù)做FFT變換后繪制頻譜圖。這個功能在音樂播放器里很常見實現(xiàn)起來也不復(fù)雜但要注意不能在音頻回調(diào)里做太重的計算否則會影響播放的流暢性。另外如果要做網(wǎng)絡(luò)流播放緩沖區(qū)管理需要更復(fù)雜的策略來對抗網(wǎng)絡(luò)抖動?？梢砸胱赃m應(yīng)緩沖區(qū)根據(jù)網(wǎng)絡(luò)狀況動態(tài)調(diào)整緩沖區(qū)大小。網(wǎng)絡(luò)好的時候減小緩沖區(qū)降低延遲網(wǎng)絡(luò)差的時候增大緩沖區(qū)避免卡頓。音頻播放這塊內(nèi)容表面上看就是把數(shù)據(jù)喂給聲卡但真正做好做穩(wěn)需要處理的細(xì)節(jié)非常多。我自己的體會是先把基本的播放流程跑通然后再逐步優(yōu)化緩沖區(qū)管理、時鐘同步、性能這些方面。不要一上來就追求完美先把聲音放出來再慢慢調(diào)優(yōu)。遇到問題的時候多打印日志觀察緩沖區(qū)的水位變化大部分問題都能從數(shù)據(jù)上找到線索。