简介这是一套基于Qt与FFmpeg的流媒体播放器完整工程面向需要开发RTSP拉流、音视频播放或录像截图功能的C开发者。压缩包为rar格式共263个文件其中包含144个C头文件、13个cpp源文件、45个dll运行库、8个lib库以及pro/pri工程配置、qm翻译文件、ui界面文件、mp4示例视频和编译产物等整体约43.23MB。目前已有1992人学习/下载。工程基于Qt 5.832位与FFmpeg 5.1搭建支持TCP/UDP方式拉取监控摄像头RTSP实时流音频使用QAudioOutput输出视频经FFmpeg解码后由YUV转RGB并在QOpenGLWidget中渲染。读者可从中获取完整的播放器源码、界面与工程组织结构理解音视频解码、渲染、截图、录像等关键实现适合进阶练习或移植改造。1. 用 Qt 做 ffmpeg 流媒体播放器先从一次播放器的翻车开始前阵子帮某开发者调试一个基于 Qt 的流媒体播放器他用的是 Qt 自带的 QMediaPlayer结果接 RTSP 工业相机流时画面延迟拉到两秒开外截图还会黑屏。折腾一晚上之后他换成了 ffmpeg Qt 的方案ffmpeg 负责解协议和解码Qt 只做两件事——渲染视频帧和用 QAudioOutput 输出 PCM 音频。换了架构之后延迟压到了两三百毫秒截图、录像也顺手实现了。这个项目的核心思路就是把 ffmpeg 当成一个纯解码黑盒用 Qt 的多线程机制把解码、渲染、音频输出三条流水线串起来。如果你是做桌面播放器、需要接 RTSP/HTTP 流、或者想给自己的工具软件加一个自带截图录像能力的播放模块这份资源值得对着源码走一遍。2. 播放器的骨架线程模型与数据流转决定了你能不能顺手加截图和录像2.1 为什么用 ffmpeg 手写渲染而不是 QMediaPlayerQMediaPlayer 在播放本地文件时没问题但一旦你需要在播放过程中做三件事——取原始帧截图、把帧序列录制成文件、精确控制音频输出缓冲它就会变得非常难用。QMediaPlayer 不给你 YUV 帧的访问权截图只能用 grab() 抓窗口录像更是无从谈起。ffmpeg 的 libavcodec 和 libavformat 则完全不一样你拿到的是解码后的 AVFrame想怎么操作都行。视频帧可以转成 QImage 画到控件上也可以直接丢给编码器做录像音频帧拿到的是 AVFrame 里的 PCM 数据通过 QAudioOutput 喂给声卡播放。这也是本项目把 QAudioOutput 放进关键词的原因——Qt Multimedia 模块的 QAudioOutput 本质就是一个音频输出设备封装接受 PCM 字节流不关心数据是怎么解码出来的。2.2 三个线程两个队列的基本结构我拿到这个项目的第一件事是看它的线程组织方式。播放器这类程序如果你在主线程里一边解码一边渲染遇到网络抖动或者高码率流界面立刻卡死。这个项目的做法是三个线程// 解码线程从 ffmpeg 的 demuxer 读取 AVPacket送进解码器得到 AVFrame void PlayerCore::decodeLoop() { while (m_playing.load()) { if (m_pause.load()) { msleep(10); continue; } int ret av_read_frame(m_fmtCtx, m_packet); if (ret 0) { // 读到流尾部或出错这里不做退出处理而是等缓冲耗尽 msleep(20); continue; } if (m_packet-stream_index m_videoStreamIdx) { if (avcodec_send_packet(m_vCodecCtx, m_packet) 0) { AVFrame *frame av_frame_alloc(); if (avcodec_receive_frame(m_vCodecCtx, frame) 0) { m_videoQueue-push(frame); // 队列只收解码后的 AVFrame } else { av_frame_free(frame); } } } else if (m_packet-stream_index m_audioStreamIdx) { // 音频帧走同样的路线进入音频队列 } av_packet_unref(m_packet); } }这段代码有几个细节值得注意。av_read_frame 返回小于 0 的值时不是直接退出循环而是 sleep 一下继续等因为你可能只是临时断流网络恢复后还能继续读。队列里存的是 AVFrame 而不是 AVPacket因为解码后的帧才是渲染和录像真正需要的单位。每帧都 av_frame_alloc 免得踩内存复用的坑。渲染线程和音频线程分别从两个队列里取帧视频队列负责供给 paintEvent 里要画的 QImage音频队列把 PCM 喂给 QAudioOutput。两个队列之间不需要互相等待同步工作由时间戳来完成这部分我在第 6 章单独说。2.3 控制字段用原子变量而不是互斥锁项目里控制播放、暂停、停止用的是 std::atomic 而不是 QMutex这是经验老到的写法。暂停状态下解码线程只是 sleep 不退出渲染线程收到暂停信号后停在上一帧不继续取队列。这样做的好处是避免了停止播放时线程互相等待造成死锁。// PlayerCore.h 中关键的控制字段 std::atomicbool m_playing { false }; // 是否处于播放状态 std::atomicbool m_pause { false }; // 是否暂停 std::atomicint64_t m_seekTarget { -1 }; // 待跳转的时间戳毫秒值m_seekTarget 是另一个有意思的设计。跳转时不能直接清空队列——你清空了解码线程可能还没反应过来在清空之后又推入几帧旧数据造成画面回跳。这个项目选择在解码线程里检查 m_seekTarget一旦发现需要跳转先 av_seek_frame 再清空队列让队列填充从头开始。队列本身用一个 QMutex 保护但控制字段全部用原子变量把锁竞争降到最低。3. 核心实现路径从打开流到屏幕上出现第一帧画面3.1 初始化流程avformat 上下文、解码器参数与打开失败兜底播放器的初始化是整个工程里最容易出现空指针崩溃的地方。项目里封了一个 openMedia 函数完整流程是avformat_open_input 打开源avformat_find_stream_info 读取流信息找到视频流和音频流的 index分别打开对应的解码器。bool PlayerCore::openMedia(const QString url) { // url 可以是本地文件路径也可以是 rtsp:// 或 http:// 流地址 std::string uStr url.toStdString(); if (avformat_open_input(m_fmtCtx, uStr.c_str(), nullptr, nullptr) ! 0) { emit errorOccurred(QStringLiteral(无法打开媒体源)); return false; } if (avformat_find_stream_info(m_fmtCtx, nullptr) 0) { emit errorOccurred(QStringLiteral(无法读取流信息)); avformat_close_input(m_fmtCtx); return false; } m_videoStreamIdx -1; m_audioStreamIdx -1; for (unsigned int i 0; i m_fmtCtx-nb_streams; i) { AVCodecParameters *par m_fmtCtx-streams[i]-codecpar; if (par-codec_type AVMEDIA_TYPE_VIDEO m_videoStreamIdx 0) m_videoStreamIdx static_castint(i); else if (par-codec_type AVMEDIA_TYPE_AUDIO m_audioStreamIdx 0) m_audioStreamIdx static_castint(i); } if (m_videoStreamIdx 0) { emit errorOccurred(QStringLiteral(未找到视频流)); avformat_close_input(m_fmtCtx); return false; } // 打开视频解码器 AVCodecParameters *vPar m_fmtCtx-streams[m_videoStreamIdx]-codecpar; const AVCodec *vDecoder avcodec_find_decoder(vPar-codec_id); if (!vDecoder) { avformat_close_input(m_fmtCtx); return false; } m_vCodecCtx avcodec_alloc_context3(vDecoder); if (avcodec_parameters_to_context(m_vCodecCtx, vPar) 0) { avcodec_free_context(m_vCodecCtx); avformat_close_input(m_fmtCtx); return false; } m_vCodecCtx-thread_count 4; // 多线程解码对 4K 流提升明显 if (avcodec_open2(m_vCodecCtx, vDecoder, nullptr) 0) { avcodec_free_context(m_vCodecCtx); avformat_close_input(m_fmtCtx); return false; } // 音频解码器打开方式类似略 return true; }这里有个细节thread_count 设置为 4 而不是直接设置成 CPU 核心数。ffmpeg 的解码器多线程化在帧之间有依赖时收益有限设成核心数反而可能增加线程切换开销。项目实际测试里 4 线程在常规桌面 CPU 上对 H.264 高码率流的解码收益最高。音频解码器不要开多线程意义不大。打开失败的处理很关键。这个函数里每一个失败分支都会释放已经打开的资源再返回避免调用方拿到一个残半的对象。实际调试中经常遇到的问题是只检查 avformat_open_input 的返回值后面 find_stream_info 失败导致空指针这里把每一层都检查了。3.2 视频渲染YUV 帧转 QImage 的两种做法解码出来的 AVFrame 不能直接画到 QWidget 上。常见做法有两种项目里两个都实现了通过一个标志切换方便对比性能。做法一是用 sws_scale 把 YUV420P 转成 RGB32再构造 QImage做法二是直接生成一个 QImage 用来存 YUV 数据绘制时用 QPainter 配合自定义着色器。第二种需要 OpenGL 支持代码复杂度高。项目默认走第一种// 把解码线程传来的 AVFrame 转成 QImage 并放进待渲染队列 QImage PlayerCore::frameToImage(AVFrame *frame) { int w frame-width; int h frame-height; if (!m_swsCtx) { m_swsCtx sws_getContext( w, h, static_castAVPixelFormat(frame-format), w, h, AV_PIX_FMT_RGB32, SWS_BILINEAR, nullptr, nullptr, nullptr); } QImage img(w, h, QImage::Format_RGB32); uint8_t *dst img.bits(); int dstLineSize img.bytesPerLine(); uint8_t *srcData[4] { frame-data[0], frame-data[1], frame-data[2], nullptr }; int srcLineSize[4] { frame-linesize[0], frame-linesize[1], frame-linesize[2], 0 }; sws_scale(m_swsCtx, srcData, srcLineSize, 0, h, dst, dstLineSize); return img; }这里最需要留意的参数是 linesize。ffmpeg 解码出来的视频帧每一行的字节数不是简单的 width * 3它有对齐要求某些分辨率下 linesize 会比实际宽度大如果直接按 width 去计算偏移就会得到一张斜着撕裂的图。用 sws_scale 转换时 srcLineSize 必须从 frame-linesize 取原始值不能自己算。这也是我调试这个项目时踩过最典型的坑之一。帧率控制放在渲染线程里用帧自身携带的 PTS 来判断该不该立即渲染而不是固定 sleep 固定毫秒数。因为视频流里有 B 帧时PTS 不一定是单调递增的直接按 PTS 差值 sleep 可能出现时间倒退。项目用了一个简单方案记录上一帧渲染时刻的 QElapsedTimer结合当前帧 PTS 与上一帧 PTS 的差值计算应等待时长差值为负则立即渲染。3.3 音频解码与 QAudioOutput 的对接方式音频部分是这个项目区别于其他播放器实现的关键。不用 SDL 而是用 Qt 的 QAudioOutput好处是 UI 线程能直接拿到音频设备的缓冲状态而且不需要额外引入 SDL 依赖。// 音频输出初始化与数据喂送 QAudioFormat fmt; fmt.setSampleRate(m_audioSampleRate); // 从音频流参数中获取 fmt.setChannelCount(m_audioChannels); fmt.setSampleSize(16); fmt.setCodec(audio/pcm); fmt.setByteOrder(QAudioFormat::LittleEndian); fmt.setSampleType(QAudioFormat::SignedInt); m_audioOutput new QAudioOutput(fmt, this); m_audioIODevice m_audioOutput-start(); // 拿到设备的 IO 通道启动之后音频线程循环从音频队列取 AVFrame把 AVFrame 里的 PCM 数据写入 m_audioIODevice。关键点有两个第一QAudioOutput 的缓冲区大小有默认值但建议手动调整到与音频帧时长匹配的量级推荐设置为 200ms 左右的数据量太大延迟高太小容易在系统负载高时断续第二写入操作要判断 QAudioOutput 的 bytesFree 是否足够不够就等待写入不能直接 write 因为底层缓冲满了会阻塞。这个设计真正的优势体现在录像功能上——录像封装需要的是解码后的 PCM 而不是压缩前的 AAC 流从 AVFrame 里拿 PCM 做编码比从 QAudioOutput 做环路采集要干净得多网络流场景下也不会丢包。4. 截图与录像两个高频功能的实现细节4.1 截图功能从视频帧转 QImage 与文件命名策略截图功能看起来简单实际上有个技术决策点是直接从解码线程的帧队列里取帧还是单独解码一帧。这个项目选择从队列里取当前最新的一帧来做截图而不是暂停解码去专门解码一帧。这样做的原因是暂停解码会引入人为延迟而在播放过程中截图取到的帧与用户视觉上看到的内容差一帧的间隔完全够用。void PlayerWidget::captureScreenshot() { AVFrame *frame m_core-latestVideoFrame(); // 从队列中拿最新帧不阻塞 if (!frame) return; QImage img m_core-frameToImage(frame); QString dir QStringLiteral(captures); QDir().mkpath(dir); // 文件名带时间戳避免覆盖 QString fname dir QStringLiteral(/screenshot_) QDateTime::currentDateTime().toString(yyyyMMdd_hhmmss_zzz) QStringLiteral(.png); img.save(fname); emit statusMessage(QStringLiteral(截图已保存: %1).arg(fname)); }注意这里的 QDateTime 不只精确到秒还带毫秒。因为快速连点截图时每秒最多需要保存几十张。只精确到秒的话同一秒内的截图会互相覆盖。取最新帧用的是一个带保护的单帧读取接口从队列尾部取而不出队这样不会破坏播放的连续性。4.2 录制功能复用 ffmpeg 编码器封装 MP4录像的实现思路是同时开一条编码链路解码得到的视频帧进 sws_scale 转成编码器要求的像素格式再送进 libx264 编码器音频 PCM 送进 AAC 编码器两条流用 av_interleaved_write_frame 写进 MP4 容器。整个逻辑封装在一个 Recorder 类里和 PlayerCore 解耦。bool Recorder::start(const QString outputPath, int width, int height, int fps) { avformat_alloc_output_context2(m_fmtCtx, nullptr, mp4, outputPath.toStdString().c_str()); if (!m_fmtCtx) return false; // 创建视频流编码器用 libx264 m_vStream avformat_new_stream(m_fmtCtx, nullptr); m_vCodecCtx avcodec_alloc_context3(avcodec_find_encoder(AV_CODEC_ID_H264)); m_vCodecCtx-width width; m_vCodecCtx-height height; m_vCodecCtx-time_base { 1, fps }; m_vCodecCtx-pix_fmt AV_PIX_FMT_YUV420P; avcodec_open2(m_vCodecCtx, avcodec_find_encoder(AV_CODEC_ID_H264), nullptr); // 打开输出文件并写入头部 avio_open(m_fmtCtx-pb, outputPath.toStdString().c_str(), AVIO_FLAG_WRITE); avformat_write_header(m_fmtCtx, nullptr); return true; }编码参数的设置有几个讲究。width 和 height 必须是偶数因为 YUV420P 的色度采样按 2x2 块划分奇数维度会直接编码失败。time_base 的分子一定要是 1写成 {30, 1} 之类会在封装 MP4 时产生非整数的帧率导致播放器显示的时间轴漂移。码率控制项目里默认采用 CRF 方式在编码器参数里设置 crf23这个值在画质和文件体积之间比较平衡网络流原始码率本身不低时CRF 要比固定码率更稳妥。录制的完成阶段有一个最容易翻车的点必须调用 av_write_trailer 来写 moov 原子并且要 flush 编码器里残留的帧。直接关闭文件写出的 MP4 在播放器里打不开。4.3 录像时的音视频时间戳对齐录制 MP4 时最影响播放体验的是音视频时间戳不同步。项目里录制的视频帧 PTS 用的是相对录制开始时刻的毫秒数音频帧 PTS 则从解码帧自带的 PTS 换算。网络流来源的音频 PTS 基准和视频 PTS 基准可能不一致。这里的处理办法是在录制开始时记录第一帧视频和第一帧音频的原始 PTS后续每帧都减去对应的起始 PTS再统一乘以时间基转换成毫秒。// 视频帧写入 int64_t ptsMs (frame-pts - m_vStartPts) * av_q2d(vStream-time_base) * 1000; frame-pts av_rescale_q(ptsMs, {1, 1000}, vStream-time_base); // 音频帧做同样操作但用音频流的 time_base av_interleaved_write_frame(m_fmtCtx, packet);这样处理之后只要能保证从源流解码出来的 PTS 是可靠的录制出来的文件音画同步就不会出问题。做完这一步录像文件用播放器查看时间轴是正常的。5. 播放器避坑手册线程退出崩溃、爆音、首帧黑屏、文件打不开5.1 线程退出时崩溃析构函数里乱 join现象关闭播放窗口时程序闪退断点定位在 PlayerCore 的析构函数里。原因析构函数先释放了 ffmpeg 的 AVFormatContext而解码线程还在 av_read_frame 里。上下文已经被释放线程仍在这个上下文上工作等于访问野指针。更隐蔽的是线程在 push 队列时队列所属对象已经被析构。解决严格按照「先停线程再释放资源」的顺序写析构。做法是在析构函数里先把 m_playing 置为 false然后 join 解码线程确认线程退出后再逐个释放 fmtCtx、codecCtx、队列。还有一个小细节是解码线程里读到的最后一帧可能还在队列里没被消费完要在 join 之后、释放队列之前先把队列清空。PlayerCore::~PlayerCore() { m_playing.store(false); if (m_decodeThread.joinable()) m_decodeThread.join(); if (m_audioThread.joinable()) m_audioThread.join(); m_videoQueue-clearAndFreeFrames(); // 先把残留 AVFrame 释放掉 if (m_vCodecCtx) avcodec_free_context(m_vCodecCtx); if (m_fmtCtx) avformat_close_input(m_fmtCtx); }从那以后我每次写播放器类都会把「停线程 → 清队列 → 释放 ffmpeg 对象」的注释写进析构函数里因为这个问题调试起来非常痛苦崩溃栈每次都不一样很难定位。5.2 QAudioOutput 爆音和卡顿缓冲设置与写入时机现象播放本地文件时偶尔爆音播放 RTSP 视频流时声音一顿一顿画面正常。原因两个问题叠加。第一QAudioOutput 内部缓冲区默认值偏小网络流延迟波动时底层声卡缓冲区欠载产生爆音。第二写入 PCM 数据时没有检查 bytesFree盲目 write 造成数据被丢弃或写入阻塞。解决把 QAudioOutput 的缓冲区设置到 200ms 对应的字节数比默认值大很多。同时音频线程里循环写入每次先读 bytesFree不够就等 10ms 再写。int bytesPerMs m_audioSampleRate * m_audioChannels * 2 / 1000; m_audioOutput-setBufferSize(bytesPerMs * 200); // 200ms 缓冲 // 写入音频帧时 QByteArray pcmData(reinterpret_castconst char*(frame-data[0]), frame-linesize[0]); int written 0; while (written pcmData.size()) { int freeBytes m_audioOutput-bytesFree(); if (freeBytes 0) { msleep(10); continue; } int chunk qMin(freeBytes, pcmData.size() - written); m_audioIODevice-write(pcmData.constData() written, chunk); written chunk; }这是调节音频延迟的第一档旋钮。如果你的场景对延迟要求极高比如需要对嘴型或做实时交互可以把这个缓冲往下压到 80ms但如果你在 Windows 上使用 WASAPI 之外的默认音频后端低于 50ms 会出现频繁爆音。项目里默认 200ms 是一个不怎么出错的保守值。5.3 首帧黑屏宽高为 0 时 SWS 上下文创建失败现象播放某些 H.265 编码的流媒体时前 2-3 秒画面是黑屏然后突然出现画面。原因解码器输出帧的宽高在初始化时拿不到。某些编码器在解码前几个帧时不会输出完整的帧信息frame-width 为 0此时 sws_getContext 传 0 宽高会失败返回 nullptrframeToImage 函数在条件判断时跳过转换直接返回空 QImage。解决frameToImage 里加入宽高合法性检查宽高不为 0 时才创建 SWS 上下文上下文创建失败时返回空 QImage 但不要 crash。另外一个更稳妥的规避方式是初始化时从 AVCodecParameters 里拿宽高作为兜底值如果 frame 的宽高为 0 就用这个值。网络流场景里 avformat_find_stream_info 之后就能拿到正确的宽高用它的好处是解码器延迟输出的问题完全被绕开了。int w frame-width 0 ? frame-width : m_codecParamsWidth; int h frame-height 0 ? frame-height : m_codecParamsHeight;这样改完H.265 流也能在首帧解码后立刻显示画面不再黑屏等待。5.4 录像文件打不开闪退进程没来得及写 trailer现象程序崩溃后打开刚录的 MP4 文件提示文件已损坏或无法渲染。原因MP4 的 moov 原子在文件尾部录制过程中写道一半崩溃av_write_trailer 没执行文件结构不完整。这是录制类功能最容易踩的坑尤其是录制网络流时网络闪断导致的崩溃概率更高。解决除了正常的析构函数里保证调用 av_write_trailer 之外项目里加了一个记录恢复机制录制开始时每秒在另一个文本文件里写一次「当前写入字节数」和「最后成功写入帧的 PTS」。崩溃重新打开时如果发现 MP4 文件大小与记录的字节数不匹配就提示用户录像是损坏的同时在保存录像之前先临时写到 .part 文件全部完成后再 rename 成 .mp4。这个方法很土但确实能避免一堆「为什么文件打不开」的工单。5.5 播放过程中 seek 导致花屏没清 B 帧参考链现象拖动进度条后偶尔出现几帧花屏或绿屏不恢复只能重新打开流。原因关键帧间隔与解码器参考帧完整性的问题。拖到的地方不是关键帧解码器从该位置开始解缺少参考帧输出的画面是花的。有些实现在这种情况下会连续出错帧而不恢复。解决seek 之后立即丢弃解码器里所有缓存的帧——用 avcodec_flush_buffers 清空解码器内部参考帧缓存同时清空显示队列。下一个关键帧到达之前解码器会输出空白帧但不会花屏。这个函数的调用必须在解码线程里做因为解码器上下文同一时刻只能有一个线程访问。if (m_seekTarget.load() 0) { int64_t target m_seekTarget.exchange(-1); av_seek_frame(m_fmtCtx, -1, target * AV_TIME_BASE, AVSEEK_FLAG_BACKWARD); avcodec_flush_buffers(m_vCodecCtx); m_videoQueue-clearAndFreeFrames(); continue; }AVSEEK_FLAG_BACKWARD 表示向后 seek 到最近的关键帧这样解码器能从关键帧解起。从实际测试看这个方案花屏概率从每次必现降到了几乎不可见。6. 音视频同步用 QAudioOutput 的缓冲水位做时钟基准6.1 音频主时钟为什么不让视频自己走时间播放器项目一般推荐音频时钟作为主时钟。人类的听觉系统对声音的中断极其敏感一帧音频数据的延迟或提前都比视频的闪烁更难以接受。视频这边通过丢帧或补帧来追赶音频音频只做小范围微调。项目的同步控制放在渲染线程的等待逻辑里核心代码如下// 渲染循环中计算当前帧是否应该显示 int64_t videoPtsMs frame-pts * av_q2d(m_vStreamTimeBase) * 1000; int64_t audioClockMs m_core-audioClockMs(); // 当前播放到的音频位置毫秒 int diff static_castint(videoPtsMs - audioClockMs); if (diff 10) { // 视频帧比音频早到等待 msleep(qMin(diff, 50)); } else if (diff -10) { // 视频落后丢弃当前帧不下发渲染 continue; }这里的关键是 audioClockMs 怎么算。直接用 QAudioOutput 的 processedUSecs 是准的。processedUSecs 表示从启动到现在声卡实际消费了多少微秒的数据加上每次写入的 audioDevice 的缓冲时长修正约等于当前正在播放的音频位置。项目里的实现是int64_t PlayerCore::audioClockMs() { if (!m_audioOutput) return 0; qint64 processed m_audioOutput-processedUSecs() / 1000; qint64 buffered m_audioOutput-bufferSize() ? (m_audioOutput-bufferSize() - m_audioOutput-bytesFree()) * 1000 / m_bytesPerMs : 0; return processed buffered; }为什么要加上 buffered 项因为 processedUSecs 统计的是声卡已经消费掉的 PCM 数据而那些已经在 QAudioOutput 内部缓冲里排队等待播放的数据还没被 processed 统计。不加这个修正值音频时钟会比实际播出的位置滞后 200ms 左右对应的音频永远感觉在视频前面一点点。加了之后就准确了。6.2 音频帧解码过多时的丢帧策略网络流经常出现音频帧成批到达的现象解码线程一口气解码出几十毫秒的 PCM音频队列瞬间塞满。如果不做限制QAudioOutput 缓冲会被填满然后整个系统开始等待视频也会跟着卡顿。项目里做了队列水位上限音频队列超过 300ms 数据量时解码线程直接丢弃新解码的音频帧直到队列降到 150ms 以下再恢复输送。这个逻辑和 TCP 的流量控制思路类似就是不让生产端超过消费端能力太多。6.3 从同步异常反查原因的排查路线如果你最终发现音画不同步不要先调代码先看几个值。打印三个数据视频帧 PTS、audioClockMs、两者差值。差值为正说明视频超前为负说明视频滞后。如果差值在你播放的每一秒里都在缓慢漂移大概率是音频采样率或 channels 设置错QAudioOutput 实际输出的 PCM 播放速度和源流速度不一致这种漂移量会随时间线性增长。如果差值跳变没有规律就要看是不是 seek 之后没有重置时间基准导致旧帧残留。项目在调试时加了一个简单的 HUD 文本显示把这三个值实时画在播放窗口角落。调试完这个 HUD 不要删它在你后续调整缓冲大小、修改同步策略时价值巨大。从那次之后我每次写播放器都会保留这个 HUD 面板用它来做一切延迟相关问题的第一道排查工具。希望你从这份资源里拿到的不仅是能跑的代码更是这套排查思路能帮你在自己的项目里少走几个晚上。本文还有配套的精品资源点击获取
