簡介一款基于Qt5與FFmpeg開發(fā)的視頻播放器完整源碼面向具備C基礎(chǔ)、希望快速掌握音視頻播放器實(shí)現(xiàn)思路的開發(fā)者。壓縮包共43個(gè)文件包含cpp/h源碼、ui界面設(shè)計(jì)、qrc資源文件、pro與sln工程配置以及flv格式樣例視頻還附帶了編譯生成的obj、tlog、log等過程文件整體大小20.08MB。目前已有2450人學(xué)習(xí)下載源碼經(jīng)過驗(yàn)證可直接編譯運(yùn)行免去依賴搭建與工程配置的煩惱。工程結(jié)構(gòu)清晰界面與FFmpeg解碼邏輯分層便于對(duì)照學(xué)習(xí)Qt事件循環(huán)與音視頻解碼流程通過.ui文件可研究界面布局.qrc文件展示了資源打包方式FFmpeg調(diào)用邏輯則揭示了音視頻解碼的關(guān)鍵步驟。既適合直接復(fù)用播放器模塊也可作為課程設(shè)計(jì)或畢業(yè)設(shè)計(jì)的參照是一份完整可落地的FFmpeg與Qt實(shí)踐資料下載后即可對(duì)照源碼動(dòng)手驗(yàn)證。1. 為什么用QtFFmpeg做播放器而不是直接拿現(xiàn)成框架先把這個(gè)項(xiàng)目的定位說清楚。網(wǎng)上能直接用的播放器一大堆VLC、MPV、PotPlayer隨便挑一個(gè)都比自己寫的體驗(yàn)好那我為什么還要用Qt和FFmpeg從零搭一個(gè)播放器源碼出來答案很簡單工作中需要的是“能嵌入到自己業(yè)務(wù)系統(tǒng)里的播放內(nèi)核”而不是一個(gè)獨(dú)立的播放器成品。比如你在做一個(gè)工業(yè)巡檢軟件視頻窗口只是界面里的一個(gè)模塊要跟檢測算法聯(lián)動(dòng)、要控制播放節(jié)奏、要把特定幀抽出來做圖像處理——這些需求拿現(xiàn)成的播放器是做不到的。自己基于FFmpeg解碼、基于Qt渲染等于把播放鏈路的核心環(huán)節(jié)全部握在自己手里。1.1 視頻播放器的底層鏈路拆解不管是什么播放器底層干的活其實(shí)就四件事解封裝Demux把MP4、MKV、FLV這類容器格式拆開提取出視頻流、音頻流、字幕流等數(shù)據(jù)包。FFmpeg的avformat_open_input和av_read_frame干的就是這事。解碼Decode把H.264、HEVC等編碼格式的壓縮數(shù)據(jù)解碼成原始的一幀一幀圖像YUV和PCM音頻數(shù)據(jù)。對(duì)應(yīng)的API是avcodec_send_packet和avcodec_receive_frame。渲染Render把解碼后的視頻幀顯示到屏幕上。Qt這邊有兩條路一是把YUV轉(zhuǎn)成QImage直接畫二是用OpenGL把YUV數(shù)據(jù)作為紋理上傳到GPU渲染后者性能好很多。播放控制Control播放、暫停、拖動(dòng)進(jìn)度條、倍速播放本質(zhì)上都是在對(duì)解碼循環(huán)和渲染循環(huán)做狀態(tài)控制。這個(gè)鏈路搞清楚之后寫播放器源碼就變成了一個(gè)模塊對(duì)接的問題用FFmpeg解決前兩步用Qt解決第三步自己寫代碼串起第四步。1.2 方案選型背后的取舍你可能要問Qt本身不是有QMediaPlayer嗎為什么還要自己調(diào)FFmpeg我用過QMediaPlayer它在Windows下底層走的是系統(tǒng)自帶的DirectShow或WMF框架最大的問題是解碼能力取決于系統(tǒng)裝了什么解碼器。碰到H.265、4K高碼率、或者一些特殊封裝格式系統(tǒng)解碼器不支持就直接黑屏沒聲音。FFmpeg就不一樣它內(nèi)置了幾乎全套開源解碼器不依賴系統(tǒng)環(huán)境你編譯進(jìn)去什么樣的解碼能力就是什么樣?？煽匦赃@是我選FFmpeg而不是QMediaPlayer的核心原因。渲染方面也有取舍。剛開始做的時(shí)候用CPU轉(zhuǎn)QImage渲染一個(gè)1080p的視頻在普通筆記本上CPU占用率能飆到40%以上解碼線程稍微慢一點(diǎn)畫面就卡成PPT。后來改成OpenGL紋理渲染把YUV轉(zhuǎn)RGB這件事交給了GPU性能立刻上了一個(gè)臺(tái)階。后面我會(huì)詳細(xì)講這一步怎么做。2. 播放器源碼的整體架構(gòu)設(shè)計(jì)這一節(jié)是重點(diǎn)。我把源碼的模塊設(shè)計(jì)思路拆開講順序是從整體到局部你先有個(gè)大局觀后面看代碼才知道每一段是干什么的。2.1 模塊劃分解碼、渲染、音頻、同步四大塊整個(gè)工程我分成下面幾個(gè)核心類和模塊每個(gè)類職責(zé)單一方便擴(kuò)展模塊核心類職責(zé)解碼模塊VideoDecoder打開文件、讀取數(shù)據(jù)包、解碼音視頻幀視頻渲染VideoWidget基于QOpenGLWidget顯示視頻幀音頻輸出AudioPlayer通過QAudioOutput播放PCM數(shù)據(jù)同步控制PlaybackController音視頻時(shí)鐘同步、播放/暫停/seekUI層MainWindow播放器界面、控制條、事件交互一個(gè)核心的設(shè)計(jì)原則解碼渲染不能阻塞UI線程。QML或者Widgets的界面事件循環(huán)一旦被阻塞整個(gè)窗口就會(huì)無響應(yīng)所以解碼操作必須跑在獨(dú)立的線程里。我這邊開了兩個(gè)線程主解碼線程負(fù)責(zé)視頻幀的解碼和渲染回調(diào)音頻播放用的是QAudioOutput的push模式在音頻設(shè)備的回調(diào)驅(qū)動(dòng)下往緩沖區(qū)里喂數(shù)據(jù)。解碼線程和UI線程之間通過信號(hào)槽通信比如解碼線程發(fā)frameReady(QImage)給渲染窗口發(fā)positionChanged(qint64)給進(jìn)度條更新。2.2 FFmpeg API版本兼容性處理很多人第一次編譯FFmpeg相關(guān)的代碼最頭疼的就是API變了。FFmpeg 4.x、5.x、6.x之間的接口差異不小網(wǎng)上的老教程很多已經(jīng)跑不起來了。比如最典型的幾個(gè)avcodec_decode_video2這個(gè)老接口在FFmpeg 4.0之后被刪了現(xiàn)在統(tǒng)一改成avcodec_send_packetavcodec_receive_frame這種異步模型。解碼器初始化的時(shí)候需要手動(dòng)avcodec_alloc_context3然后設(shè)置pCodecContext-codec_id等參數(shù)而不是直接avcodec_alloc_context。解碼得到的AVFrame里YUV數(shù)據(jù)存儲(chǔ)格式是分平面的data[0]存Ydata[1]存Udata[2]存V每行還有對(duì)齊的linesize不是連續(xù)的字節(jié)流。這點(diǎn)不搞清楚渲染出來就是花的。我的做法是統(tǒng)一按FFmpeg 6.0這套新版API來寫代碼里只依賴最新的接口。如果你用的版本比較老遇到編譯報(bào)錯(cuò)先檢查是不是API差異導(dǎo)致的再去查對(duì)應(yīng)版本的遷移文檔。2.3 線程模型解碼線程與UI線程怎么配合再展開說一下線程模型音頻輸出的時(shí)序控制也要在這里交代。解碼線程跑一個(gè)while循環(huán)不斷讀包、解碼、按PTS時(shí)間戳決定是否推送。UI線程只負(fù)責(zé)接收視頻幀信號(hào)來更新畫面以及接收音頻模塊的播放進(jìn)度來驅(qū)動(dòng)進(jìn)度條。音頻播放則是獨(dú)立的在QAudioOutput::start之后系統(tǒng)會(huì)主動(dòng)調(diào)用你注冊(cè)的回調(diào)接口來取數(shù)據(jù)你在回調(diào)里從音頻緩沖隊(duì)列里取PCM數(shù)據(jù)返回給系統(tǒng)。這樣寫的好處是音頻時(shí)間線由系統(tǒng)聲卡時(shí)鐘驅(qū)動(dòng)解碼線程反而不需要精確sleep來掐時(shí)間只需要持續(xù)往緩沖區(qū)里補(bǔ)充數(shù)據(jù)就行。3. 核心實(shí)現(xiàn)細(xì)節(jié)與關(guān)鍵代碼現(xiàn)在我挑代碼的關(guān)鍵路徑來講你拿到源碼對(duì)著看會(huì)清楚得多。完整代碼量比較大這里不全部貼出來我把最容易寫錯(cuò)、也是最核心的幾段說清楚。3.1 解碼循環(huán)打開視頻、讀取幀、解碼幀第一步初始化FFmpeg上下文。注意新版API里av_register_all已經(jīng)被移除不需要調(diào)用了。打開文件的代碼如下// 打開文件并探測流信息 AVFormatContext* fmtCtx nullptr; int ret avformat_open_input(fmtCtx, filePath.toStdString().c_str(), nullptr, nullptr); if (ret 0) { qDebug() 打開文件失敗錯(cuò)誤碼: ret; return false; } ret avformat_find_stream_info(fmtCtx, nullptr); if (ret 0) { qDebug() 無法獲取流信息; return false; }接著需要遍歷所有流找到視頻流和音頻流的索引然后分別打開對(duì)應(yīng)的解碼器for (unsigned int i 0; i fmtCtx-nb_streams; i) { AVCodecParameters* codecParams fmtCtx-streams[i]-codecpar; const AVCodec* codec avcodec_find_decoder(codecParams-codec_id); if (!codec) continue; if (codecParams-codec_type AVMEDIA_TYPE_VIDEO videoStreamIndex -1) { videoStreamIndex i; videoCodecCtx avcodec_alloc_context3(codec); avcodec_parameters_to_context(videoCodecCtx, codecParams); avcodec_open2(videoCodecCtx, codec, nullptr); } else if (codecParams-codec_type AVMEDIA_TYPE_AUDIO audioStreamIndex -1) { audioStreamIndex i; audioCodecCtx avcodec_alloc_context3(codec); avcodec_parameters_to_context(audioCodecCtx, codecParams); avcodec_open2(audioCodecCtx, codec, nullptr); } }解碼一幀視頻的循環(huán)新版API的核心邏輯是這樣while (av_read_frame(fmtCtx, packet) 0) { if (packet-stream_index videoStreamIndex) { int ret avcodec_send_packet(videoCodecCtx, packet); if (ret 0) continue; while (avcodec_receive_frame(videoCodecCtx, frame) 0) { // 這里拿到一個(gè)完整的視頻幀可轉(zhuǎn)成QImage或紋理上傳 handleVideoFrame(frame); } } else if (packet-stream_index audioStreamIndex) { // 音頻包也走類似流程解碼后送到音頻緩沖隊(duì)列 handleAudioPacket(packet); } av_packet_unref(packet); }提示avcodec_receive_frame返回AVERROR(EAGAIN)表示需要繼續(xù)喂包返回AVERROR_EOF表示解碼結(jié)束。這是新版異步API的正常流程很多初寫者在這里把邏輯寫成了死循環(huán)。AVPacket需要每次用av_packet_alloc分配解完包記得av_packet_unref釋放引用不然內(nèi)存漲得飛快。3.2 視頻渲染QImage格式轉(zhuǎn)換與紋理上傳視頻幀最常見的是YUV420P也叫I420格式Qt的QImage不直接支持所以要么轉(zhuǎn)成RGB888再畫要么用OpenGL做GPU轉(zhuǎn)換。第二種方式性能損失小很多。先說用OpenGL的思路在QOpenGLWidget的paintGL里用glTexImage2D把Y、U、V三個(gè)平面分別上傳為三個(gè)紋理然后通過一個(gè)簡單的著色器程序把YUV轉(zhuǎn)成RGB輸出。這一步把最容易消耗CPU的YUV轉(zhuǎn)RGB操作交給了GPU1080p視頻在普通核顯上跑也能保持很低負(fù)載。下面是用QOpenGLTexture管理的紋理創(chuàng)建關(guān)鍵代碼GLuint texY, texU, texV; glGenTextures(1, texY); glBindTexture(GL_TEXTURE_2D, texY); glTexImage2D(GL_TEXTURE_2D, 0, GL_RED, width, height, 0, GL_RED, GL_UNSIGNED_BYTE, frame-data[0]); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR); // U、V平面類似尺寸分別是width/2、height/2著色器部分用經(jīng)典的YUV轉(zhuǎn)RGB公式要注意BT.601和BT.709色域的區(qū)別網(wǎng)絡(luò)視頻多數(shù)用BT.601// 片段著色器核心邏輯 vec3 yuv vec3(texture(texY, v_texCoord).r, texture(texU, v_texCoord).r - 0.5, texture(texV, v_texCoord).r - 0.5); vec3 rgb mat3(1.0, 1.0, 1.0, 0.0, -0.344, 1.772, 1.402, -0.714, 0.0) * yuv;如果你不想引入OpenGL也有一個(gè)簡化方案用FFmpeg的sws_scale把YUV轉(zhuǎn)成RGB888然后封裝成QImage再update()到QLabel或QWidget上。這個(gè)方案代碼少但性能差適合練手或處理低分辨率視頻我這里也給你貼一下轉(zhuǎn)換的核心部分SwsContext* swsCtx sws_getContext(width, height, AV_PIX_FMT_YUV420P, width, height, AV_PIX_FMT_RGB24, SWS_BILINEAR, nullptr, nullptr, nullptr); uint8_t* rgbData new uint8_t[width * height * 3]; uint8_t* dstSlice[1] { rgbData }; int dstStride[1] { width * 3 }; sws_scale(swsCtx, frame-data, frame-linesize, 0, height, dstSlice, dstStride); QImage image(rgbData, width, height, width * 3, QImage::Format_RGB888);3.3 音頻輸出QAudioOutput播放PCM數(shù)據(jù)的兩種方式音頻解碼后得到的是PCM裸數(shù)據(jù)Qt這邊可以用QAudioOutput來播放。有兩種模式Pull模式系統(tǒng)按固定頻率主動(dòng)調(diào)用你的readData回調(diào)你返回音頻字節(jié)數(shù)據(jù)。這種方式節(jié)奏由聲卡驅(qū)動(dòng)不容易卡頓推薦用于播放。Push模式你主動(dòng)往QIODevice里寫數(shù)據(jù)適合一次性寫入小段數(shù)據(jù)的場景但播放長音頻時(shí)容易因?yàn)閷懱鞂?dǎo)致內(nèi)存積壓。我推薦用Pull模式初始化QAudioOutput的時(shí)候傳入音頻格式采樣率、聲道數(shù)、位深然后自定義一個(gè)QIODevice子類在readData回調(diào)里從音頻緩沖隊(duì)列取出PCM數(shù)據(jù)返回給系統(tǒng)。偽代碼如下class AudioIODevice : public QIODevice { public: qint64 readData(char* data, qint64 maxLen) override { return audioPlayer-pullData(data, maxLen); } qint64 writeData(const char* data, qint64 len) override { return len; } };這樣音頻播放的實(shí)際節(jié)奏完全由聲卡的播放時(shí)鐘決定而播放器主線程只需要按視頻幀的PTS跟音頻時(shí)鐘比較即可達(dá)到音視頻同步。3.4 音視頻同步基于pts的主時(shí)鐘方案說到音視頻同步這是播放器里最容易翻車的地方。最常見的方案是以音頻時(shí)鐘為主時(shí)鐘視頻幀根據(jù)它的PTS時(shí)間戳跟音頻當(dāng)前的播放時(shí)間做比較如果視頻幀的時(shí)間比音頻早就等一等晚了就立即顯示并丟棄遲到的幀。具體實(shí)現(xiàn)解碼線程每次拿到視頻幀的時(shí)候取幀里的pts用av_rescale_q把它從視頻流的時(shí)間基轉(zhuǎn)換成毫秒然后跟當(dāng)前音頻播放的位置比較qint64 videoPtsMs av_rescale_q(frame-pts, videoStream-time_base, AVRational{1, 1000}); qint64 audioClockMs audioPlayer-getCurrentPositionMs(); qint64 diff videoPtsMs - audioClockMs; if (diff 30) { // 視頻比音頻晚等一小會(huì)但要控制sleep粒度建議5ms一輪地等 QThread::msleep(5); } else if (diff -30) { // 視頻落后太多跳過這幀不顯示 return; }這里有個(gè)細(xì)節(jié)幀率一般24fps或30fps即每幀間隔33~41ms所以30毫秒的容差比較合理。如果容差太小網(wǎng)絡(luò)視頻會(huì)因?yàn)榉庋b時(shí)間戳抖動(dòng)而不?？D容差太大音畫不同步就會(huì)變得很嚴(yán)重。這個(gè)值需要根據(jù)你目標(biāo)播放的視頻源特點(diǎn)做調(diào)整。3.5 Seek定位與播放狀態(tài)切換Seek功能的核心API是av_seek_frame但它有個(gè)坑seek之后需要清空解碼器的內(nèi)部緩沖否則會(huì)解出seek前殘留的幀畫面花掉或者時(shí)間軸錯(cuò)亂。正確流程是這樣void VideoPlayer::seekTo(qint64 targetMs) { // 1. 把目標(biāo)時(shí)間從毫秒轉(zhuǎn)成流時(shí)間基 int64_t targetPts av_rescale_q(targetMs * 1000, AVRational{1, 1000000}, videoStream-time_base); // 2. 執(zhí)行seekAVSEEK_FLAG_BACKWARD表示向前找關(guān)鍵幀避免花屏 av_seek_frame(fmtCtx, videoStreamIndex, targetPts, AVSEEK_FLAG_BACKWARD); // 3. 清空解碼器緩沖關(guān)鍵 avcodec_flush_buffers(videoCodecCtx); avcodec_flush_buffers(audioCodecCtx); // 4. 重置音頻緩沖隊(duì)列和時(shí)鐘 audioPlayer-clearBuffer(); audioPlayer-resetClock(); }AVSEEK_FLAG_BACKWARD這個(gè)標(biāo)志位一定要帶上它的作用是seek到目標(biāo)時(shí)間點(diǎn)之前最近的一個(gè)關(guān)鍵幀然后從關(guān)鍵幀解碼到目標(biāo)位置。如果不帶這個(gè)標(biāo)志解碼器可能定位在目標(biāo)時(shí)間之后的幀等真正顯示到那一幀的時(shí)候時(shí)間已經(jīng)過了畫面會(huì)卡頓或者跳跳的。4. 環(huán)境搭建與編譯配置這部分如果不提前準(zhǔn)備好后面會(huì)一直出幺蛾子。我把Windows和Linux兩條路的配置都寫了你按自己的環(huán)境選。4.1 Windows下FFmpeg與Qt的安裝配置第一步裝QtQt 6.2以上開源版可以從官網(wǎng)下載安裝時(shí)勾選MinGW 64-bit套件或者M(jìn)SVC也行看你后面用哪種編譯器。國內(nèi)用戶下載慢的話用中科大鏡像站下載離線安裝包會(huì)快很多。第二步裝FFmpeg這里有個(gè)常見的坑——不要自己從源碼編譯FFmpeg耗時(shí)耗力還容易缺依賴。直接下載編譯好的FFmpeg開發(fā)庫shared版本解壓后會(huì)看到bin、include、lib三個(gè)目錄。然后在Qt工程的.pro文件里配置庫路徑# 注意路徑改成你實(shí)際解壓的位置 INCLUDEPATH D:/ffmpeg/include LIBS -LD:/ffmpeg/lib \ -lavformat \ -lavcodec \ -lavutil \ -lswscale \ -lswresample運(yùn)行程序的時(shí)候記得把D:/ffmpeg/bin下的avcodec-*.dll、avformat-*.dll拷貝到exe同目錄或者加到系統(tǒng)PATH里否則啟動(dòng)會(huì)提示找不到動(dòng)態(tài)庫。4.2 CMakeLists.txt關(guān)鍵配置如果你用的是CMake工程配置邏輯差不多但需要注意鏈接順序。FFmpeg各庫之間存在依賴關(guān)系鏈接的時(shí)候要把依賴別人的庫放在前面否則某些Linux發(fā)行版會(huì)報(bào)未定義引用find_package(Qt6 COMPONENTS Widgets OpenGL Multimedia REQUIRED) find_path(FFMPEG_INCLUDE_DIR avformat.h) find_library(AVFORMAT_LIB avformat) find_library(AVCODEC_LIB avcodec) find_library(AVUTIL_LIB avutil) find_library(SWSCALE_LIB swscale) find_library(SWRESAMPLE_LIB swresample) add_executable(VideoPlayer ${SOURCES}) target_include_directories(VideoPlayer PRIVATE ${FFMPEG_INCLUDE_DIR}) target_link_libraries(VideoPlayer PRIVATE Qt6::Widgets Qt6::OpenGL Qt6::Multimedia ${AVFORMAT_LIB} ${AVCODEC_LIB} ${SWSCALE_LIB} ${AVUTIL_LIB} ${SWRESAMPLE_LIB} )有一點(diǎn)要提醒的Windows下MinGW編譯器和MSVC編譯器對(duì)FFmpeg庫的兼容性不同如果你下載的是MinGW版FFmpeg工程必須用MinGW套件編譯否則符號(hào)對(duì)不上。5. 踩坑記錄與常見問題速查這個(gè)部分是我實(shí)際調(diào)試過程中遇到的問題匯總每條都是花了時(shí)間才定位出來的建議收藏對(duì)照。5.1 常見報(bào)錯(cuò)與解法報(bào)錯(cuò)信息原因分析解決方法error: av_register_all was not declared使用了舊版API新版FFmpeg已移除該函數(shù)直接刪掉這行代碼播放只有聲音沒有畫面視頻幀格式轉(zhuǎn)換錯(cuò)誤或渲染時(shí)序不對(duì)檢查視頻流實(shí)際像素格式用frame-format確認(rèn)YUVJ420P等格式要單獨(dú)處理畫面拉伸變形QImage的bytesPerLine沒處理對(duì)不能直接用width*3作為每行字節(jié)數(shù)要用image.bytesPerLine()拖動(dòng)進(jìn)度條后花屏seek后沒有沖刷解碼器緩沖調(diào)用seek后立刻執(zhí)行avcodec_flush_buffers程序退出時(shí)崩潰解碼線程還在跑UI資源已經(jīng)被釋放退出時(shí)先停止解碼線程并join再釋放FFmpeg上下文和Qt資源打開某些視頻延遲高達(dá)好幾秒avformat_find_stream_info在解析時(shí)長不影響功能但可以提示loading狀態(tài)或用超時(shí)參數(shù)限制注意第一條提到的av_register_all是網(wǎng)上老教程最典型的過時(shí)代碼如果你看過5年前的播放器源碼基本都會(huì)遇到這個(gè)問題。新版FFmpeg初始化解碼器不需要注冊(cè)步驟直接用avcodec_find_decoder就行。5.2 播放流暢度與內(nèi)存泄漏排查播放卡頓的排查思路我一般按這個(gè)順序來先看CPU占用率。如果CPU滿了大概率是YUV轉(zhuǎn)RGB在CPU上跑優(yōu)先換OpenGL渲染。如果CPU正常但畫面依然卡看日志里解碼線程是否丟幀嚴(yán)重——可以打印每幀的PTS和當(dāng)前系統(tǒng)時(shí)間對(duì)比看看是不是解碼速度跟不上。檢查視頻幀是否按PTS做了延時(shí)控制。有些新手直接把所有解碼幀一股腦推給UI顯示根本不看時(shí)間戳結(jié)果就是畫面飛速播放然后卡死。必須按PTS等時(shí)間。內(nèi)存泄漏排查我用valgrind或者Qt自帶的QObject父子機(jī)制檢查。常見的泄漏點(diǎn)是AVPacket沒有unref、AVFrame沒有av_frame_free、SwsContext沒有sws_freeContext。每次解碼循環(huán)結(jié)束前檢查有沒有把這幾個(gè)資源釋放掉。另外QImage轉(zhuǎn)發(fā)的內(nèi)存分配也是個(gè)隱藏的泄漏源。每次發(fā)一個(gè)QImage信號(hào)底層會(huì)拷貝一份圖像數(shù)據(jù)頻率很高的話內(nèi)存占用會(huì)快速增長。優(yōu)化的辦法是用QSharedPointerQImage作為信號(hào)參數(shù)避免深層拷貝。6. 性能優(yōu)化與功能擴(kuò)展思路如果你已經(jīng)能正常播放視頻了那說明基礎(chǔ)鏈路已經(jīng)全部打通。接下來這段是進(jìn)階方向也是一個(gè)合格播放器源碼該有的樣子。6.1 性能優(yōu)化四步走換硬解FFmpeg的h264_mediacodec、h264_qsv、hevc_cuvid等硬解解碼器能把解碼負(fù)載從CPU轉(zhuǎn)移到GPU。在avcodec_find_decoder的時(shí)候優(yōu)先查找硬解解碼器找不到再回退軟解。幀緩沖隊(duì)列解碼線程和渲染線程之間用一個(gè)定長隊(duì)列解耦隊(duì)列滿則解碼線程休眠隊(duì)列空則渲染線程等待。避免解碼一幀、渲染一幀這樣串行阻塞。多線程解碼新版FFmpeg支持AV_CODEC_FLAG_LOW_DELAY和thread_count配置對(duì)高分辨率視頻設(shè)置codecCtx-thread_count 0讓其自動(dòng)選擇最優(yōu)線程數(shù)。減少顏色空間轉(zhuǎn)換如果你的目標(biāo)平臺(tái)屏幕色彩格式支持YUV直接呈現(xiàn)例如通過DRM/KMS可以跳過RGB轉(zhuǎn)換這一步直接渲染YUV平面性能能進(jìn)一步提升但通用性會(huì)下降。6.2 功能擴(kuò)展這些方向都能玩截圖功能拿到視頻幀之后用image.save()一行就能存成PNG。如果想截取原始YUV數(shù)據(jù)做算法分析也可以直接從AVFrame里導(dǎo)數(shù)據(jù)。倍速播放調(diào)整播放速度的核心是調(diào)整音視頻的PTS縮放因子。視頻方面可以讓解碼循環(huán)按倍數(shù)縮短等待時(shí)間音頻方面可以用swr_scale重采樣改變采樣率來改變播放速度音調(diào)會(huì)變或者用FFmpeg的atempo音頻濾鏡音調(diào)不變。本地文件拖拽播放重寫dragEnterEvent和dropEvent把拖入的路徑傳給解碼模塊即可體驗(yàn)感會(huì)提升很多。字幕支持FFmpeg能解出字幕流數(shù)據(jù)但顯示需要自己畫到視頻幀上涉及字幕格式解析和字體渲染是個(gè)獨(dú)立的大活想魔改的可以挑戰(zhàn)一下。我在實(shí)際使用中的一個(gè)體會(huì)是播放器源碼的調(diào)試難點(diǎn)不在寫代碼而在定位音視頻不同步和渲染異常這類時(shí)序問題這類問題不像語法錯(cuò)誤一樣直接報(bào)錯(cuò)而是讓你看到滿屏的花屏或刺啦刺啦的聲音只能靠不斷加日志、對(duì)比時(shí)間戳來排查。最后再分享一個(gè)小技巧寫播放器時(shí)把調(diào)試信息統(tǒng)一封裝成一個(gè)宏比如#define DEBUG_TIME(qmsg) qDebug() QTime::currentTime().toString(hh:mm:ss.zzz) qmsg時(shí)間戳精確到毫秒級(jí)別排查“音頻快了幾十毫秒”這類問題時(shí)能少走很多彎路。本文還有配套的精品資源點(diǎn)擊獲取