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