音视频开发这个方向很多人第一次接触时都会被一堆名词砸晕封装、编码、码率、采样率、像素格式、时间戳……每个字都认识连在一起就不知道在说什么。我当初从纯业务后端转过来做播放器的时候也是对着FFmpeg的API文档发懵一个av_read_frame调下去返回的packet到底是个啥为什么要送去解码解码完的frame又为什么不能直接扔给显卡这些问题卡了我差不多两周。后来啃完了雷神的博客、翻了几遍FFmpeg源码里几个核心结构体的定义才算把这条链路理顺。这篇东西就是把我踩过的坑和理清楚的逻辑写下来面向的是有一定C基础、想用FFmpeg加QT做一个能跑的播放器、但被音视频基础概念卡住的朋友。我会从播放器的整体架构讲起把封装格式、编解码、像素与采样、时间戳与同步这几块基础打牢再落到FFmpeg核心数据结构和QT渲染的对接上最后给一份可以直接抄的实操流程和排查清单。看完你至少能明白一个MP4文件从磁盘读出来到屏幕上出现画面、喇叭里出声音中间到底经历了什么以及每一步在代码里对应哪个函数调用。1. 播放器整体架构与核心思路拆解1.1 为什么播放器要拆成这几层先想清楚一件事播放器本质上是一个翻译机。磁盘上躺着的MP4文件里面的数据是压缩过的、按特定规则打包的而显卡和声卡只认原始的像素和PCM采样。播放器要做的就是把压缩数据翻译成原始数据并且按照正确的时间节奏送出去。这个翻译过程天然分成几段每一段职责不同所以架构上也就分成了对应的层。我习惯把播放器拆成五层来看解协议层、解封装层、解码层、同步控制层、渲染输出层。解协议层处理的是数据从哪来本地文件、网络流、摄像头读取方式不一样解封装层负责把容器拆开分离出一路路音视频流同时拿到每路流的编码参数解码层把压缩的packet还原成原始frame同步控制层决定这一帧什么时候该显示、什么时候该丢弃渲染输出层把frame交给QT的绘制系统和音频输出设备。这么拆的好处是每一层可以独立替换和调试。比如你发现画面花屏问题可能在解码层也可能在渲染层的像素格式转换分层之后你可以单独把解码出来的frame存成一张图看看对不对快速定位。如果所有逻辑揉在一个函数里排查起来就是灾难。1.2 用FFmpeg还是自己撸解码器这个问题几乎每个新手都会问。我的答案很明确除非你的目标是学习编解码算法本身否则一律用FFmpeg。原因有三点。第一FFmpeg支持的封装格式和编码格式数量是工业级的H.264、H.265、VP9、AV1、AAC、MP3、FLAC这些主流格式全都覆盖你自己实现一个H.264解码器光是帧内预测的九种模式就够写一个月。第二FFmpeg的性能经过大量优化有汇编级别的SIMD加速你手写的C代码在速度上很难追上。第三FFmpeg的API虽然学习曲线陡但一旦理解了那几个核心结构体的关系用起来其实很顺。那QT负责什么QT在这个项目里主要干两件事界面和渲染。界面部分用QWidget或者QML都行按钮、进度条、音量条这些渲染部分视频用QOpenGLWidget或者QLabel配合QImage音频用QAudioOutput。QT的多媒体模块本身也有播放能力但那个封装太深你学不到底层的东西而且可控性差做不了精细的同步和自定义渲染。所以这个项目的定位就是FFmpeg管解码和同步QT管界面和输出各司其职。1.3 一个最小可用播放器的模块划分落到代码结构上我建议至少分成这么几个类。一个Demuxer类封装avformat_open_input、avformat_find_stream_info、av_read_frame这些调用对外提供给我下一个packet的接口。一个Decoder类封装avcodec_find_decoder、avcodec_open2、avcodec_send_packet、avcodec_receive_frame对外提供给我下一个frame。一个VideoRenderer类继承QOpenGLWidget或者用QWidget加paintEvent负责把AVFrame转成QImage再画出来。一个AudioPlayer类用QAudioOutput把PCM数据推给声卡。最后是一个PlayerController持有上面这些对象跑两个线程或者用QT的信号槽做异步协调解封装、解码、同步、渲染的节奏。这个划分不是唯一解但它的好处是每个类的职责单一接口清晰。你调试的时候可以单独new一个Demuxer把读出来的packet信息打印出来确认封装层没问题再往下走。这种逐层验证的调试习惯是我做音视频开发这几年觉得最省时间的做法。2. 音视频基础概念逐个击破2.1 封装格式与编码格式的区别这是新手最容易混淆的一对概念我必须掰开讲。封装格式Container Format是盒子编码格式Codec是盒子里装的东西的压缩方式。一个MP4文件是封装格式它里面可能装着H.264编码的视频和AAC编码的音频一个MKV文件也是封装格式它里面可能装着H.265的视频和FLAC的音频。盒子和内容是可以自由组合的。为什么要有封装这个东西因为一个视频文件不只有画面数据还有音频数据、字幕、章节信息、封面图、元数据时长、分辨率、帧率。封装格式定义了这些数据怎么组织在一起怎么索引怎么标记每一段数据属于哪一路流、在时间轴的什么位置。MP4用的是box结构一层套一层MKV用的是EBML一种类似XML的二进制格式TS流用的是固定188字节的包适合网络传输。在FFmpeg里封装格式对应AVFormatContext编码格式对应AVCodecContext。你调用avformat_open_input打开文件FFmpeg会自动识别封装格式然后avformat_find_stream_info会去读文件头把每一路流的编码参数解析出来填充到各个AVStream的codecpar里。理解这一点你就明白为什么打开文件之后还要单独去找解码器——因为封装层只告诉你这路流是H.264具体怎么解得靠解码器。2.2 视频编码的核心原理为什么能压缩几百倍一帧1080P的原始画面按YUV420P算大小是1920×1080×1.5≈3MB。一秒30帧就是90MB一分钟5.4GB。这显然没法存也没法传。H.264能把它压到几MB一分钟靠的是两把刷子空间冗余压缩和时间冗余压缩。空间冗余压缩就是帧内压缩利用一张图内部相邻像素高度相似的特点。比如一大片蓝天相邻像素值几乎一样没必要每个都存存一个块加上这块都一样的标记就行。H.264把画面切成16×16的宏块对每个宏块做预测帧内预测有九种方向模式然后对预测残差做DCT变换、量化、熵编码。量化是损失的关键量化步长越大压缩率越高画质越差。时间冗余压缩就是帧间压缩利用相邻帧之间画面变化不大的特点。H.264把帧分成I帧、P帧、B帧。I帧是关键帧独立编码不依赖其他帧P帧是前向预测帧只记录相对于前面帧的变化B帧是双向预测帧参考前后两帧。一个GOP图像组通常以I帧开头后面跟一串P帧和B帧。这就是为什么你拖动进度条跳到某个位置时播放器要先找到那个位置之前的最近一个I帧然后从那里开始解码一直解到你跳转的位置——因为P帧和B帧自己没法独立还原。注意I帧不等于清晰帧它只是独立编码的帧。I帧的量化参数如果很大一样会糊。判断画质要看码率和量化参数不能只看是不是I帧。2.3 音频编码的核心原理从PCM到AAC音频这边逻辑类似但维度不同。原始音频是PCM采样比如44.1kHz采样率、16位深度、双声道一秒的数据量是44100×2×2176400字节约172KB。一分钟10MB也不算小。AAC能把它压到十分之一左右。音频压缩利用的是人耳的感知特性这叫心理声学模型。人耳对某些频率的声音敏感对另一些不敏感一个强音附近的小声音会被掩蔽掉听不见。AAC编码器分析频谱把被掩蔽的成分直接丢掉把不重要的频率用更少的比特表示重要的频率多给比特。这个过程叫有损压缩但听感上损失很小。音频编码里几个关键参数必须搞清楚。采样率Sample Rate是每秒采多少个点常见44100Hz和48000Hz。位深Bit Depth是每个采样点用多少比特表示16位最常见。声道数Channels是单声道、双声道还是多声道。码率Bitrate是每秒多少比特AAC常见128kbps到320kbps。这四个参数决定了音频的基本质量也是解码器初始化时必须匹配的参数。2.4 像素格式YUV为什么比RGB更适合视频视频帧在内存里的排列方式叫像素格式。最常见的是YUV420P也有NV12、YUYV、RGB24等。为什么视频用YUV而不是RGB两个原因。第一人眼对亮度Y敏感对色度U、V不敏感所以可以亮度全采样、色度降采样YUV420P就是色度在水平和垂直方向都减半数据量比RGB24少了三分之一。第二YUV和RGB的转换是线性的历史上有硬件电路直接支持现在GPU也原生支持。YUV420P的内存布局要记清楚先存所有Y分量宽×高个字节再存所有U分量宽/2×高/2个字节最后存所有V分量宽/2×高/2个字节。所以一帧1080P的YUV420P大小是1920×1080 960×540 960×540 3110400字节约3MB。这个布局和RGB的交叉排列完全不同写渲染代码时如果搞错了画面会变成绿一块紫一块。FFmpeg解码出来的AVFramedata[0]指向Y平面data[1]指向U平面data[2]指向V平面linesize[0]、linesize[1]、linesize[2]分别是每行的字节数。注意linesize不一定等于宽度因为内存对齐的原因它通常比宽度大。这个坑我踩过直接按宽度去读会错位必须用linesize。2.5 时间戳与同步播放器最烧脑的部分时间戳是播放器同步的基石。FFmpeg里有两个时间戳概念PTSPresentation Time Stamp和DTSDecoding Time Stamp。PTS是这一帧应该显示的时间DTS是这一帧应该解码的时间。对于没有B帧的视频PTS和DTS相等有B帧的时候因为B帧要参考后面的帧所以解码顺序和显示顺序不一致DTS和PTS就分开了。时间戳的单位是时间基Time Base用分数表示比如1/90000表示每个单位是1/90000秒。不同流的time_base可能不一样视频流常见1/90000或1/1000音频流常见1/44100或1/48000。要比较音视频的时间必须先把它们转换到同一个时间基通常转成秒或者毫秒。转换公式是时间秒 timestamp × time_base。同步策略有三种以音频为主时钟、以视频为主时钟、以外部时钟为主时钟。实际播放器绝大多数用音频为主时钟因为人耳对声音的断续极其敏感音频必须连续播放不能卡人眼对视频偶尔丢帧或重复帧容忍度高。所以逻辑是音频按自己的节奏往声卡送视频帧显示前先看当前音频播到哪了如果视频帧的PTS比音频时钟快就等一等如果慢了就赶紧显示或者直接丢掉。这个等一等和丢一丢的阈值调优是播放器流畅度的关键。3. FFmpeg核心数据结构与QT对接实操3.1 必须吃透的几个结构体FFmpeg的API是围绕几个核心结构体转的理解了它们的关系代码就顺了。AVFormatContext是整个文件的上下文持有所有流的信息。AVStream是单路流的描述里面有codecpar编码参数和time_base。AVCodecContext是解码器的上下文由codecpar初始化而来。AVPacket是压缩数据包从av_read_frame拿到送给解码器。AVFrame是解码后的原始数据从avcodec_receive_frame拿到送去渲染。它们的数据流是这样的av_read_frame(AVFormatContext, AVPacket)→avcodec_send_packet(AVCodecContext, AVPacket)→avcodec_receive_frame(AVCodecContext, AVFrame)→ 渲染。这条链路是现代FFmpeg的标准用法老版本用的是avcodec_decode_video2已经废弃了新代码不要再用。初始化流程也要记牢avformat_open_input→avformat_find_stream_info→ 遍历AVFormatContext.streams找到音视频流的index →avcodec_find_decoder(codecpar-codec_id)→avcodec_alloc_context3→avcodec_parameters_to_context→avcodec_open2。这一串调用一个都不能少顺序也不能乱。3.2 视频帧转QImage的正确姿势FFmpeg解码出来的是YUV420PQT的QImage不直接支持YUV420P新版本有支持但兼容性一般所以通常要转成RGB。转换有两种方式用FFmpeg的sws_scale或者用GPU的shader。CPU方案简单先讲这个。sws_scale的用法是先sws_getContext创建一个转换上下文参数包括源宽高、源像素格式、目标宽高、目标像素格式、缩放算法。然后准备一个目标缓冲区调用sws_scale把YUV转成RGB。转换完的RGB数据可以直接构造QImage格式用QImage::Format_RGB888。这里有个性能坑sws_getContext不要每帧都创建它是有开销的应该在初始化时创建一次复用。目标缓冲区也不要每帧malloc提前分配好。我见过有人每帧都sws_getContext加malloc1080P视频CPU直接跑满帧率掉到十几。改成复用之后同样的机器能跑满60帧。如果追求性能可以用QOpenGLWidget把YUV三个平面作为三个纹理传给GPU在fragment shader里做YUV到RGB的转换。这样CPU几乎不干活4K视频也能轻松跑。但shader方案代码复杂一些新手建议先用sws_scale把功能跑通再优化。3.3 音频PCM的播放与重采样音频这边FFmpeg解码出来的是PCM但格式不一定和声卡匹配。声卡可能要求48kHz、16位、双声道而解码出来的是44.1kHz、浮点、单声道。这时候需要重采样用swr_convert。SwrContext的创建和SwsContext类似用swr_alloc_set_opts指定输入输出参数然后swr_init。转换时准备输出缓冲区调用swr_convert。注意音频的样本数计算和视频不一样它按采样点算还要考虑声道数。播放用QT的QAudioOutput。流程是创建一个QAudioFormat设置采样率、声道数、样本大小、编码方式用QAudioDeviceInfo找到默认输出设备检查是否支持这个格式创建QAudioOutput拿到它的QIODevice把PCM数据写进去。QAudioOutput内部有自己的缓冲写太快会阻塞写太慢会断音所以音频数据的供给要平滑。提示音频播放最容易出的问题是咔咔的爆音通常是缓冲区欠载或者数据不连续导致的。检查两点一是重采样后的样本数是否和写入的字节数匹配二是音频时钟是否稳定。3.4 线程模型为什么不能全塞主线程QT的主线程负责界面刷新和事件循环如果你把解封装、解码、渲染全放主线程界面会卡死进度条拖不动按钮点不了。所以必须多线程。常见的模型是解封装一个线程解码一个线程或者音视频各一个渲染在主线程。解封装线程不断av_read_frame把packet放进队列解码线程从队列取packet解码成frame放进frame队列渲染在主线程用定时器或者信号槽触发从frame队列取数据画出来。队列要加锁用QMutex保护条件变量做等待唤醒。线程数量不是越多越好。我试过解封装、视频解码、音频解码各一个线程加上主线程一共四个结果上下文切换开销反而拖慢了性能。后来改成解封装一个线程、音视频解码合一个线程性能更好。具体几个线程要看你的场景本地文件播放两个线程足够网络流可能需要更多。4. 常见问题与排查技巧实录4.1 画面花屏、绿屏、颜色错乱的排查花屏和颜色问题几乎都出在像素格式和内存布局上。排查顺序是这样的第一步确认解码出来的AVFrame的format是什么打印出来看如果是AV_PIX_FMT_YUV420P那data[0]是Ydata[1]是Udata[2]是V如果是AV_PIX_FMT_NV12那data[1]里U和V是交错的处理方式完全不同。第二步确认linesize不要用宽度代替。第三步确认sws_scale的目标格式和QImage的格式一致QImage::Format_RGB888对应的是RGB24如果你sws转成了BGR24颜色就会红蓝颠倒。绿屏通常是U、V平面没数据或者数据错了。YUV420P里如果U、V全是0画面就是绿的。检查data[1]和data[2]是否为空linesize[1]和linesize[2]是否合理。花屏如果是块状的可能是解码器没喂够数据或者packet送错了流。4.2 音视频不同步的几种典型表现不同步有三种表现声音快画面慢、声音慢画面快、声音画面都正常但逐渐漂移。第一种通常是视频渲染太慢帧率跟不上需要丢帧或者降低渲染开销。第二种是音频缓冲太大声音滞后需要减小音频缓冲。第三种最麻烦是时钟源不稳定或者时间戳计算有累积误差需要检查时间基转换是否用了浮点导致精度丢失。我的经验是同步逻辑里所有时间计算都用整数单位统一到毫秒或者微秒避免浮点累积误差。音频时钟用已播放的样本数除以采样率来算这个最准。视频帧的PTS转成毫秒后和音频时钟比较差值超过阈值比如50ms就调整。4.3 内存泄漏与性能瓶颈速查表音视频开发里内存泄漏很常见因为FFmpeg的很多结构体要手动释放。下面这张表是我整理的常见泄漏点和排查方法。问题现象可能原因排查方法解决方式播放越久内存越大AVPacket/AVFrame未释放用valgrind或ASan跑每次av_read_frame后av_packet_unref每次receive_frame后av_frame_unrefCPU占用持续100%sws_getContext每帧创建打印调用次数初始化时创建一次复用帧率上不去解码和渲染在同一线程看线程CPU分布拆线程渲染用GPU拖动进度条卡顿每次都从头解码看seek逻辑seek到关键帧用av_seek_frame音频爆音缓冲欠载看音频回调增大缓冲平滑供给注意av_packet_unref和av_frame_unref只是重置结构体内部指针结构体本身还要用av_packet_free和av_frame_free释放。这两个层次别搞混。4.4 几个我踩过的坑和独家技巧第一个坑avcodec_send_packet返回AVERROR(EAGAIN)不是错误是让你先去avcodec_receive_frame把已有的帧取完再送。新手看到负数就以为出错了其实要判断具体错误码。第二个坑seek的时候av_seek_frame的第三个参数是目标时间戳单位是AVStream的time_base不是秒。要先把秒转成对应的时间戳否则seek位置完全不对。第三个技巧调试的时候把每个packet的pts、dts、size打印出来把每个frame的pts、format、宽高打印出来对照着看很多问题一眼就能发现。我习惯在开发阶段加一个宏开关打开就打印这些信息上线关掉。第四个技巧用ffprobe命令行工具先分析文件看它的流信息、编码格式、时间基、时长。ffprobe -show_streams -show_format input.mp4这条命令能省你很多调试时间先确认文件本身没问题再怀疑代码。5. 从零到能播完整实操流程5.1 环境准备与依赖配置先说环境。FFmpeg建议用4.x以上版本新API更规范。Windows下可以用预编译的dev包把include和lib配到工程里Linux下直接apt装libavformat-dev、libavcodec-dev、libavutil-dev、libswscale-dev、libswresample-devmacOS用brew装ffmpeg。QT用5.12以上或者6.x都行QT6的QAudioOutput接口有变化注意区分。工程文件里要链接的库avformat、avcodec、avutil、swscale、swresample。顺序有讲究被依赖的放后面一般是avformat avcodec swresample swscale avutil。链接顺序错了会报undefined reference这个坑很隐蔽。5.2 初始化流程的代码骨架初始化部分我写成这样你可以直接参考// 打开文件 AVFormatContext* fmtCtx nullptr; if (avformat_open_input(fmtCtx, path, nullptr, nullptr) 0) { // 处理错误 } if (avformat_find_stream_info(fmtCtx, nullptr) 0) { // 处理错误 } // 找音视频流 int videoIdx -1, audioIdx -1; for (unsigned i 0; i fmtCtx-nb_streams; i) { if (fmtCtx-streams[i]-codecpar-codec_type AVMEDIA_TYPE_VIDEO videoIdx 0) videoIdx i; if (fmtCtx-streams[i]-codecpar-codec_type AVMEDIA_TYPE_AUDIO audioIdx 0) audioIdx i; } // 初始化视频解码器 AVCodecParameters* vPar fmtCtx-streams[videoIdx]-codecpar; const AVCodec* vCodec avcodec_find_decoder(vPar-codec_id); AVCodecContext* vCtx avcodec_alloc_context3(vCodec); avcodec_parameters_to_context(vCtx, vPar); avcodec_open2(vCtx, vCodec, nullptr);音频解码器初始化同理把video换成audio。这段代码是模板几乎每个播放器都这么写。注意avcodec_find_decoder可能返回nullptr要做判空。5.3 解码循环与数据流转解码循环的核心是那个send/receive的配对AVPacket* pkt av_packet_alloc(); AVFrame* frame av_frame_alloc(); while (av_read_frame(fmtCtx, pkt) 0) { if (pkt-stream_index videoIdx) { avcodec_send_packet(vCtx, pkt); while (avcodec_receive_frame(vCtx, frame) 0) { // 处理frame送去渲染 av_frame_unref(frame); } } av_packet_unref(pkt); }这里的关键是内层while一次send可能对应多次receive因为解码器有内部缓冲。必须把receive循环到返回AVERROR(EAGAIN)为止否则会丢帧。这个细节很多教程没讲清楚导致新手解码出来的帧数不对。5.4 渲染与同步的落地视频渲染我用QWidget加paintEvent把AVFrame转成QImage画出来。转换用sws_scale上下文提前创建好。同步逻辑用一个audioClock变量记录当前音频播放位置视频帧显示前比较PTS差值在阈值内就显示超了就等或丢。音频用QAudioOutput把重采样后的PCM写进它的QIODevice。音频时钟用已写入的字节数除以每秒字节数来估算。这个估算不是绝对精确但足够用。整个流程跑通之后你会发现播放器能播了但可能还不够流畅。这时候就是调优阶段调缓冲大小、调同步阈值、调线程数量。这些参数没有标准答案要根据你的目标平台和视频规格来试。我的建议是先保证功能正确再谈性能不要一上来就追求4K60帧先把720P跑顺。音视频开发是个需要耐心的活基础概念打牢之后剩下的就是不断调试和优化。我到现在还会遇到新的格式、新的问题每次解决都是一次积累。把FFmpeg的日志级别开到debug多看它打印的信息很多答案就在日志里。 
长河君 · 2026/10/16 1:29:16 · 阅读 1.2k FFmpeg+QT播放器开发：从音视频基础到实战
音视频开发这个方向很多人第一次接触时都会被一堆名词砸晕封装、编码、码率、采样率、像素格式、时间戳……每个字都认识连在一起就不知道在说什么。我当初从纯业务后端转过来做播放器的时候也是对着FFmpeg的API文档发懵一个av_read_frame调下去返回的packet到底是个啥为什么要送去解码解码完的frame又为什么不能直接扔给显卡这些问题卡了我差不多两周。后来啃完了雷神的博客、翻了几遍FFmpeg源码里几个核心结构体的定义才算把这条链路理顺。这篇东西就是把我踩过的坑和理清楚的逻辑写下来面向的是有一定C基础、想用FFmpeg加QT做一个能跑的播放器、但被音视频基础概念卡住的朋友。我会从播放器的整体架构讲起把封装格式、编解码、像素与采样、时间戳与同步这几块基础打牢再落到FFmpeg核心数据结构和QT渲染的对接上最后给一份可以直接抄的实操流程和排查清单。看完你至少能明白一个MP4文件从磁盘读出来到屏幕上出现画面、喇叭里出声音中间到底经历了什么以及每一步在代码里对应哪个函数调用。1. 播放器整体架构与核心思路拆解1.1 为什么播放器要拆成这几层先想清楚一件事播放器本质上是一个翻译机。磁盘上躺着的MP4文件里面的数据是压缩过的、按特定规则打包的而显卡和声卡只认原始的像素和PCM采样。播放器要做的就是把压缩数据翻译成原始数据并且按照正确的时间节奏送出去。这个翻译过程天然分成几段每一段职责不同所以架构上也就分成了对应的层。我习惯把播放器拆成五层来看解协议层、解封装层、解码层、同步控制层、渲染输出层。解协议层处理的是数据从哪来本地文件、网络流、摄像头读取方式不一样解封装层负责把容器拆开分离出一路路音视频流同时拿到每路流的编码参数解码层把压缩的packet还原成原始frame同步控制层决定这一帧什么时候该显示、什么时候该丢弃渲染输出层把frame交给QT的绘制系统和音频输出设备。这么拆的好处是每一层可以独立替换和调试。比如你发现画面花屏问题可能在解码层也可能在渲染层的像素格式转换分层之后你可以单独把解码出来的frame存成一张图看看对不对快速定位。如果所有逻辑揉在一个函数里排查起来就是灾难。1.2 用FFmpeg还是自己撸解码器这个问题几乎每个新手都会问。我的答案很明确除非你的目标是学习编解码算法本身否则一律用FFmpeg。原因有三点。第一FFmpeg支持的封装格式和编码格式数量是工业级的H.264、H.265、VP9、AV1、AAC、MP3、FLAC这些主流格式全都覆盖你自己实现一个H.264解码器光是帧内预测的九种模式就够写一个月。第二FFmpeg的性能经过大量优化有汇编级别的SIMD加速你手写的C代码在速度上很难追上。第三FFmpeg的API虽然学习曲线陡但一旦理解了那几个核心结构体的关系用起来其实很顺。那QT负责什么QT在这个项目里主要干两件事界面和渲染。界面部分用QWidget或者QML都行按钮、进度条、音量条这些渲染部分视频用QOpenGLWidget或者QLabel配合QImage音频用QAudioOutput。QT的多媒体模块本身也有播放能力但那个封装太深你学不到底层的东西而且可控性差做不了精细的同步和自定义渲染。所以这个项目的定位就是FFmpeg管解码和同步QT管界面和输出各司其职。1.3 一个最小可用播放器的模块划分落到代码结构上我建议至少分成这么几个类。一个Demuxer类封装avformat_open_input、avformat_find_stream_info、av_read_frame这些调用对外提供给我下一个packet的接口。一个Decoder类封装avcodec_find_decoder、avcodec_open2、avcodec_send_packet、avcodec_receive_frame对外提供给我下一个frame。一个VideoRenderer类继承QOpenGLWidget或者用QWidget加paintEvent负责把AVFrame转成QImage再画出来。一个AudioPlayer类用QAudioOutput把PCM数据推给声卡。最后是一个PlayerController持有上面这些对象跑两个线程或者用QT的信号槽做异步协调解封装、解码、同步、渲染的节奏。这个划分不是唯一解但它的好处是每个类的职责单一接口清晰。你调试的时候可以单独new一个Demuxer把读出来的packet信息打印出来确认封装层没问题再往下走。这种逐层验证的调试习惯是我做音视频开发这几年觉得最省时间的做法。2. 音视频基础概念逐个击破2.1 封装格式与编码格式的区别这是新手最容易混淆的一对概念我必须掰开讲。封装格式Container Format是盒子编码格式Codec是盒子里装的东西的压缩方式。一个MP4文件是封装格式它里面可能装着H.264编码的视频和AAC编码的音频一个MKV文件也是封装格式它里面可能装着H.265的视频和FLAC的音频。盒子和内容是可以自由组合的。为什么要有封装这个东西因为一个视频文件不只有画面数据还有音频数据、字幕、章节信息、封面图、元数据时长、分辨率、帧率。封装格式定义了这些数据怎么组织在一起怎么索引怎么标记每一段数据属于哪一路流、在时间轴的什么位置。MP4用的是box结构一层套一层MKV用的是EBML一种类似XML的二进制格式TS流用的是固定188字节的包适合网络传输。在FFmpeg里封装格式对应AVFormatContext编码格式对应AVCodecContext。你调用avformat_open_input打开文件FFmpeg会自动识别封装格式然后avformat_find_stream_info会去读文件头把每一路流的编码参数解析出来填充到各个AVStream的codecpar里。理解这一点你就明白为什么打开文件之后还要单独去找解码器——因为封装层只告诉你这路流是H.264具体怎么解得靠解码器。2.2 视频编码的核心原理为什么能压缩几百倍一帧1080P的原始画面按YUV420P算大小是1920×1080×1.5≈3MB。一秒30帧就是90MB一分钟5.4GB。这显然没法存也没法传。H.264能把它压到几MB一分钟靠的是两把刷子空间冗余压缩和时间冗余压缩。空间冗余压缩就是帧内压缩利用一张图内部相邻像素高度相似的特点。比如一大片蓝天相邻像素值几乎一样没必要每个都存存一个块加上这块都一样的标记就行。H.264把画面切成16×16的宏块对每个宏块做预测帧内预测有九种方向模式然后对预测残差做DCT变换、量化、熵编码。量化是损失的关键量化步长越大压缩率越高画质越差。时间冗余压缩就是帧间压缩利用相邻帧之间画面变化不大的特点。H.264把帧分成I帧、P帧、B帧。I帧是关键帧独立编码不依赖其他帧P帧是前向预测帧只记录相对于前面帧的变化B帧是双向预测帧参考前后两帧。一个GOP图像组通常以I帧开头后面跟一串P帧和B帧。这就是为什么你拖动进度条跳到某个位置时播放器要先找到那个位置之前的最近一个I帧然后从那里开始解码一直解到你跳转的位置——因为P帧和B帧自己没法独立还原。注意I帧不等于清晰帧它只是独立编码的帧。I帧的量化参数如果很大一样会糊。判断画质要看码率和量化参数不能只看是不是I帧。2.3 音频编码的核心原理从PCM到AAC音频这边逻辑类似但维度不同。原始音频是PCM采样比如44.1kHz采样率、16位深度、双声道一秒的数据量是44100×2×2176400字节约172KB。一分钟10MB也不算小。AAC能把它压到十分之一左右。音频压缩利用的是人耳的感知特性这叫心理声学模型。人耳对某些频率的声音敏感对另一些不敏感一个强音附近的小声音会被掩蔽掉听不见。AAC编码器分析频谱把被掩蔽的成分直接丢掉把不重要的频率用更少的比特表示重要的频率多给比特。这个过程叫有损压缩但听感上损失很小。音频编码里几个关键参数必须搞清楚。采样率Sample Rate是每秒采多少个点常见44100Hz和48000Hz。位深Bit Depth是每个采样点用多少比特表示16位最常见。声道数Channels是单声道、双声道还是多声道。码率Bitrate是每秒多少比特AAC常见128kbps到320kbps。这四个参数决定了音频的基本质量也是解码器初始化时必须匹配的参数。2.4 像素格式YUV为什么比RGB更适合视频视频帧在内存里的排列方式叫像素格式。最常见的是YUV420P也有NV12、YUYV、RGB24等。为什么视频用YUV而不是RGB两个原因。第一人眼对亮度Y敏感对色度U、V不敏感所以可以亮度全采样、色度降采样YUV420P就是色度在水平和垂直方向都减半数据量比RGB24少了三分之一。第二YUV和RGB的转换是线性的历史上有硬件电路直接支持现在GPU也原生支持。YUV420P的内存布局要记清楚先存所有Y分量宽×高个字节再存所有U分量宽/2×高/2个字节最后存所有V分量宽/2×高/2个字节。所以一帧1080P的YUV420P大小是1920×1080 960×540 960×540 3110400字节约3MB。这个布局和RGB的交叉排列完全不同写渲染代码时如果搞错了画面会变成绿一块紫一块。FFmpeg解码出来的AVFramedata[0]指向Y平面data[1]指向U平面data[2]指向V平面linesize[0]、linesize[1]、linesize[2]分别是每行的字节数。注意linesize不一定等于宽度因为内存对齐的原因它通常比宽度大。这个坑我踩过直接按宽度去读会错位必须用linesize。2.5 时间戳与同步播放器最烧脑的部分时间戳是播放器同步的基石。FFmpeg里有两个时间戳概念PTSPresentation Time Stamp和DTSDecoding Time Stamp。PTS是这一帧应该显示的时间DTS是这一帧应该解码的时间。对于没有B帧的视频PTS和DTS相等有B帧的时候因为B帧要参考后面的帧所以解码顺序和显示顺序不一致DTS和PTS就分开了。时间戳的单位是时间基Time Base用分数表示比如1/90000表示每个单位是1/90000秒。不同流的time_base可能不一样视频流常见1/90000或1/1000音频流常见1/44100或1/48000。要比较音视频的时间必须先把它们转换到同一个时间基通常转成秒或者毫秒。转换公式是时间秒 timestamp × time_base。同步策略有三种以音频为主时钟、以视频为主时钟、以外部时钟为主时钟。实际播放器绝大多数用音频为主时钟因为人耳对声音的断续极其敏感音频必须连续播放不能卡人眼对视频偶尔丢帧或重复帧容忍度高。所以逻辑是音频按自己的节奏往声卡送视频帧显示前先看当前音频播到哪了如果视频帧的PTS比音频时钟快就等一等如果慢了就赶紧显示或者直接丢掉。这个等一等和丢一丢的阈值调优是播放器流畅度的关键。3. FFmpeg核心数据结构与QT对接实操3.1 必须吃透的几个结构体FFmpeg的API是围绕几个核心结构体转的理解了它们的关系代码就顺了。AVFormatContext是整个文件的上下文持有所有流的信息。AVStream是单路流的描述里面有codecpar编码参数和time_base。AVCodecContext是解码器的上下文由codecpar初始化而来。AVPacket是压缩数据包从av_read_frame拿到送给解码器。AVFrame是解码后的原始数据从avcodec_receive_frame拿到送去渲染。它们的数据流是这样的av_read_frame(AVFormatContext, AVPacket)→avcodec_send_packet(AVCodecContext, AVPacket)→avcodec_receive_frame(AVCodecContext, AVFrame)→ 渲染。这条链路是现代FFmpeg的标准用法老版本用的是avcodec_decode_video2已经废弃了新代码不要再用。初始化流程也要记牢avformat_open_input→avformat_find_stream_info→ 遍历AVFormatContext.streams找到音视频流的index →avcodec_find_decoder(codecpar-codec_id)→avcodec_alloc_context3→avcodec_parameters_to_context→avcodec_open2。这一串调用一个都不能少顺序也不能乱。3.2 视频帧转QImage的正确姿势FFmpeg解码出来的是YUV420PQT的QImage不直接支持YUV420P新版本有支持但兼容性一般所以通常要转成RGB。转换有两种方式用FFmpeg的sws_scale或者用GPU的shader。CPU方案简单先讲这个。sws_scale的用法是先sws_getContext创建一个转换上下文参数包括源宽高、源像素格式、目标宽高、目标像素格式、缩放算法。然后准备一个目标缓冲区调用sws_scale把YUV转成RGB。转换完的RGB数据可以直接构造QImage格式用QImage::Format_RGB888。这里有个性能坑sws_getContext不要每帧都创建它是有开销的应该在初始化时创建一次复用。目标缓冲区也不要每帧malloc提前分配好。我见过有人每帧都sws_getContext加malloc1080P视频CPU直接跑满帧率掉到十几。改成复用之后同样的机器能跑满60帧。如果追求性能可以用QOpenGLWidget把YUV三个平面作为三个纹理传给GPU在fragment shader里做YUV到RGB的转换。这样CPU几乎不干活4K视频也能轻松跑。但shader方案代码复杂一些新手建议先用sws_scale把功能跑通再优化。3.3 音频PCM的播放与重采样音频这边FFmpeg解码出来的是PCM但格式不一定和声卡匹配。声卡可能要求48kHz、16位、双声道而解码出来的是44.1kHz、浮点、单声道。这时候需要重采样用swr_convert。SwrContext的创建和SwsContext类似用swr_alloc_set_opts指定输入输出参数然后swr_init。转换时准备输出缓冲区调用swr_convert。注意音频的样本数计算和视频不一样它按采样点算还要考虑声道数。播放用QT的QAudioOutput。流程是创建一个QAudioFormat设置采样率、声道数、样本大小、编码方式用QAudioDeviceInfo找到默认输出设备检查是否支持这个格式创建QAudioOutput拿到它的QIODevice把PCM数据写进去。QAudioOutput内部有自己的缓冲写太快会阻塞写太慢会断音所以音频数据的供给要平滑。提示音频播放最容易出的问题是咔咔的爆音通常是缓冲区欠载或者数据不连续导致的。检查两点一是重采样后的样本数是否和写入的字节数匹配二是音频时钟是否稳定。3.4 线程模型为什么不能全塞主线程QT的主线程负责界面刷新和事件循环如果你把解封装、解码、渲染全放主线程界面会卡死进度条拖不动按钮点不了。所以必须多线程。常见的模型是解封装一个线程解码一个线程或者音视频各一个渲染在主线程。解封装线程不断av_read_frame把packet放进队列解码线程从队列取packet解码成frame放进frame队列渲染在主线程用定时器或者信号槽触发从frame队列取数据画出来。队列要加锁用QMutex保护条件变量做等待唤醒。线程数量不是越多越好。我试过解封装、视频解码、音频解码各一个线程加上主线程一共四个结果上下文切换开销反而拖慢了性能。后来改成解封装一个线程、音视频解码合一个线程性能更好。具体几个线程要看你的场景本地文件播放两个线程足够网络流可能需要更多。4. 常见问题与排查技巧实录4.1 画面花屏、绿屏、颜色错乱的排查花屏和颜色问题几乎都出在像素格式和内存布局上。排查顺序是这样的第一步确认解码出来的AVFrame的format是什么打印出来看如果是AV_PIX_FMT_YUV420P那data[0]是Ydata[1]是Udata[2]是V如果是AV_PIX_FMT_NV12那data[1]里U和V是交错的处理方式完全不同。第二步确认linesize不要用宽度代替。第三步确认sws_scale的目标格式和QImage的格式一致QImage::Format_RGB888对应的是RGB24如果你sws转成了BGR24颜色就会红蓝颠倒。绿屏通常是U、V平面没数据或者数据错了。YUV420P里如果U、V全是0画面就是绿的。检查data[1]和data[2]是否为空linesize[1]和linesize[2]是否合理。花屏如果是块状的可能是解码器没喂够数据或者packet送错了流。4.2 音视频不同步的几种典型表现不同步有三种表现声音快画面慢、声音慢画面快、声音画面都正常但逐渐漂移。第一种通常是视频渲染太慢帧率跟不上需要丢帧或者降低渲染开销。第二种是音频缓冲太大声音滞后需要减小音频缓冲。第三种最麻烦是时钟源不稳定或者时间戳计算有累积误差需要检查时间基转换是否用了浮点导致精度丢失。我的经验是同步逻辑里所有时间计算都用整数单位统一到毫秒或者微秒避免浮点累积误差。音频时钟用已播放的样本数除以采样率来算这个最准。视频帧的PTS转成毫秒后和音频时钟比较差值超过阈值比如50ms就调整。4.3 内存泄漏与性能瓶颈速查表音视频开发里内存泄漏很常见因为FFmpeg的很多结构体要手动释放。下面这张表是我整理的常见泄漏点和排查方法。问题现象可能原因排查方法解决方式播放越久内存越大AVPacket/AVFrame未释放用valgrind或ASan跑每次av_read_frame后av_packet_unref每次receive_frame后av_frame_unrefCPU占用持续100%sws_getContext每帧创建打印调用次数初始化时创建一次复用帧率上不去解码和渲染在同一线程看线程CPU分布拆线程渲染用GPU拖动进度条卡顿每次都从头解码看seek逻辑seek到关键帧用av_seek_frame音频爆音缓冲欠载看音频回调增大缓冲平滑供给注意av_packet_unref和av_frame_unref只是重置结构体内部指针结构体本身还要用av_packet_free和av_frame_free释放。这两个层次别搞混。4.4 几个我踩过的坑和独家技巧第一个坑avcodec_send_packet返回AVERROR(EAGAIN)不是错误是让你先去avcodec_receive_frame把已有的帧取完再送。新手看到负数就以为出错了其实要判断具体错误码。第二个坑seek的时候av_seek_frame的第三个参数是目标时间戳单位是AVStream的time_base不是秒。要先把秒转成对应的时间戳否则seek位置完全不对。第三个技巧调试的时候把每个packet的pts、dts、size打印出来把每个frame的pts、format、宽高打印出来对照着看很多问题一眼就能发现。我习惯在开发阶段加一个宏开关打开就打印这些信息上线关掉。第四个技巧用ffprobe命令行工具先分析文件看它的流信息、编码格式、时间基、时长。ffprobe -show_streams -show_format input.mp4这条命令能省你很多调试时间先确认文件本身没问题再怀疑代码。5. 从零到能播完整实操流程5.1 环境准备与依赖配置先说环境。FFmpeg建议用4.x以上版本新API更规范。Windows下可以用预编译的dev包把include和lib配到工程里Linux下直接apt装libavformat-dev、libavcodec-dev、libavutil-dev、libswscale-dev、libswresample-devmacOS用brew装ffmpeg。QT用5.12以上或者6.x都行QT6的QAudioOutput接口有变化注意区分。工程文件里要链接的库avformat、avcodec、avutil、swscale、swresample。顺序有讲究被依赖的放后面一般是avformat avcodec swresample swscale avutil。链接顺序错了会报undefined reference这个坑很隐蔽。5.2 初始化流程的代码骨架初始化部分我写成这样你可以直接参考// 打开文件 AVFormatContext* fmtCtx nullptr; if (avformat_open_input(fmtCtx, path, nullptr, nullptr) 0) { // 处理错误 } if (avformat_find_stream_info(fmtCtx, nullptr) 0) { // 处理错误 } // 找音视频流 int videoIdx -1, audioIdx -1; for (unsigned i 0; i fmtCtx-nb_streams; i) { if (fmtCtx-streams[i]-codecpar-codec_type AVMEDIA_TYPE_VIDEO videoIdx 0) videoIdx i; if (fmtCtx-streams[i]-codecpar-codec_type AVMEDIA_TYPE_AUDIO audioIdx 0) audioIdx i; } // 初始化视频解码器 AVCodecParameters* vPar fmtCtx-streams[videoIdx]-codecpar; const AVCodec* vCodec avcodec_find_decoder(vPar-codec_id); AVCodecContext* vCtx avcodec_alloc_context3(vCodec); avcodec_parameters_to_context(vCtx, vPar); avcodec_open2(vCtx, vCodec, nullptr);音频解码器初始化同理把video换成audio。这段代码是模板几乎每个播放器都这么写。注意avcodec_find_decoder可能返回nullptr要做判空。5.3 解码循环与数据流转解码循环的核心是那个send/receive的配对AVPacket* pkt av_packet_alloc(); AVFrame* frame av_frame_alloc(); while (av_read_frame(fmtCtx, pkt) 0) { if (pkt-stream_index videoIdx) { avcodec_send_packet(vCtx, pkt); while (avcodec_receive_frame(vCtx, frame) 0) { // 处理frame送去渲染 av_frame_unref(frame); } } av_packet_unref(pkt); }这里的关键是内层while一次send可能对应多次receive因为解码器有内部缓冲。必须把receive循环到返回AVERROR(EAGAIN)为止否则会丢帧。这个细节很多教程没讲清楚导致新手解码出来的帧数不对。5.4 渲染与同步的落地视频渲染我用QWidget加paintEvent把AVFrame转成QImage画出来。转换用sws_scale上下文提前创建好。同步逻辑用一个audioClock变量记录当前音频播放位置视频帧显示前比较PTS差值在阈值内就显示超了就等或丢。音频用QAudioOutput把重采样后的PCM写进它的QIODevice。音频时钟用已写入的字节数除以每秒字节数来估算。这个估算不是绝对精确但足够用。整个流程跑通之后你会发现播放器能播了但可能还不够流畅。这时候就是调优阶段调缓冲大小、调同步阈值、调线程数量。这些参数没有标准答案要根据你的目标平台和视频规格来试。我的建议是先保证功能正确再谈性能不要一上来就追求4K60帧先把720P跑顺。音视频开发是个需要耐心的活基础概念打牢之后剩下的就是不断调试和优化。我到现在还会遇到新的格式、新的问题每次解决都是一次积累。把FFmpeg的日志级别开到debug多看它打印的信息很多答案就在日志里。