Qt集成FFmpeg实现RTSP播放：从拉流到QImage显示的完整工程实践

简介：这是一份基于Qt与FFmpeg的RTSP播放器演示工程，面向刚接触C++音视频开发的初学者，完整展示了在Qt界面中拉取RTSP流、解码视频帧并渲染画面的过程，可直接迁移到远程监控、在线直播等实时视频场景。压缩包共16个文件，核心是5个cpp源码与4个头文件，另有3个ui界面文件、Makefile、pro工程和说明文档，整体仅14KB，结构精炼，适合按模块逐文件查看。已有671人学习下载。工程划分了主程序入口、FFmpeg封装类、界面与业务逻辑层，阅读源码可以掌握avformat_open_input、av_read_frame等常用API的配合方式，了解Qt信号槽机制、事件循环与多线程如何协同完成视频刷新；同时，通过Makefile还能熟悉Linux下源码编译与链接的自动构建流程。对于想要快速上手Qt多媒体编程或正在准备RTSP播放器项目的开发者，这是一份轻量而完整的参考实现。

1. 为什么Qt播放RTSP绕不开FFmpeg：一个演示项目解决的问题

很多Qt开发者把QMediaPlayer拖上去，丢一个RTSP地址进去，结果要么黑屏，要么直接报错“无法解析”。Qt自带多媒体框架对本地文件支持尚可，对RTSP这种网络流却经常无能为力，尤其在桌面平台上，能解码H.264/H.265的路径非常有限。所以做视频监控、低延迟图传、网络摄像头预览这类项目，主流方案就是把FFmpeg集成进来。

这个“Qt-FFmpeg-RTSP-Demo”要解决的正是这条最实际的路径：用FFmpeg的avformat拉流、avcodec解码，再把视频帧转成QImage交给Qt控件显示。它不是一个完整播放器，而是一个可以抄进自己工程的最小框架。适合刚接触Qt和FFmpeg的桌面开发者，也适合正在排查延迟、颜色、线程崩溃这些老问题的人拿来当对照实现。

2. RTSP播放的技术底座：从拉流到上屏，FFmpeg在管线里的角色

不管界面写得多花哨，RTSP播放的底层链路都绕不开几个固定环节：网络协议协商、数据包接收、解码、像素格式转换、上屏。这一章先把每个环节在技术上的职责讲清楚，同时给出一份能直接落地的工程配置，后面再往里面填线程和画面控制。

2.1 先搞清RTSP和FFmpeg各自负责什么

RTSP本身是一个网络控制协议，它只负责协商播放地址、发起播放暂停等动作，真正载着视频数据的是旁边的RTP流。FFmpeg的libavformat把这些协议层的细节全部封装掉了：你给avformat_open_input传一个rtsp://地址，它会自动完成RTSP握手、RTP接收、解复用，输出AVPacket。压缩的视频数据再交给libavcodec解码，得到原始YUV或RGB帧。

要在Qt工程里把FFmpeg用起来，第一步是工程配置。下面是一份CMakeLists.txt的最小配置，用pkg-config方式查找FFmpeg库，这是Linux/macOS上最不容易出错的做法。

cmake_minimum_required(VERSION 3.16) project(RtspPlayerDemo) set(CMAKE_CXX_STANDARD 17) find_package(PkgConfig REQUIRED) pkg_check_modules(AVCODEC REQUIRED IMPORTED_TARGET libavcodec) pkg_check_modules(AVFORMAT REQUIRED IMPORTED_TARGET libavformat) pkg_check_modules(AVUTIL REQUIRED IMPORTED_TARGET libavutil) pkg_check_modules(SWSCALE REQUIRED IMPORTED_TARGET libswscale) find_package(Qt6 COMPONENTS Widgets REQUIRED) add_executable(rtsp_demo main.cpp videothread.cpp widget.cpp) target_link_libraries(rtsp_demo PRIVATE Qt6::Widgets PkgConfig::AVCODEC PkgConfig::AVFORMAT PkgConfig::AVUTIL PkgConfig::SWSCALE)

为什么用pkg-config而不是手写绝对路径？因为FFmpeg在发行版里通常带有完整的.pc文件，pkg-config能自动给出头文件目录、库目录和依赖项，比如libavformat可能依赖libavutil，这些都会自动带出来。手上没有pkg-config环境的时候，再退回find_path/find_library去手动指定。

注意一个细节：不同平台上pkg模块名可能略有区别，比如个别系统里libavcodec.pc不存在，只有libavcodec.so。先用pkg-config --exists --cflags libavcodec验证一下比较稳。Windows上走MSVC的话，pkg-config不一定好使，常见做法是把FFmpeg头文件和库目录复制到工程内，然后用find_path指定位置，这个在3.1还会展开。

2.2 解码后的数据怎么变成Qt能画的QImage

FFmpeg解码出来的AVFrame里，视频数据通常不是Qt想要的RGB32或RGB24。绝大多数H.264流的原生像素格式是YUV420P，而Qt的QImage原生支持的是RGB系列格式。所以中间必须有一次像素格式转换，这个转换器就是libswscale。

YUV420P里Y和UV分离，且UV分量是水平、垂直各减半采样，直接用QImage读取会得到花屏或错色的图像。用swscale转成RGB24后，每个像素按红绿蓝连续排列，QImage::Format_RGB888就能直接对应。这里最容易漏的是linesize，它表示一行数据的实际字节数，不等于图像宽度乘以字节数，因为FFmpeg分配内存时会对齐。

// 把AVFrame转换为QImage // videoFrame是解码出来的原始帧，假设已经拿到了正确的尺寸和格式 SwsContext* sws = sws_getContext( videoFrame->width, videoFrame->height, (AVPixelFormat)videoFrame->format, videoFrame->width, videoFrame->height, AV_PIX_FMT_RGB24, SWS_BILINEAR, nullptr, nullptr, nullptr); if (!sws) { // 转换器创建失败，通常是源格式或分辨率非法 return QImage(); } uint8_t* dstData[4] = {nullptr, nullptr, nullptr, nullptr}; int dstLinesize[4] = {0, 0, 0, 0}; av_image_alloc(dstData, dstLinesize, videoFrame->width, videoFrame->height, AV_PIX_FMT_RGB24, 32); sws_scale(sws, videoFrame->data, videoFrame->linesize, 0, videoFrame->height, dstData, dstLinesize); // 用copy()把像素数据从FFmpeg缓冲区拷进QImage内部，后续可以安全释放 QImage image(dstData[0], videoFrame->width, videoFrame->height, dstLinesize[0], QImage::Format_RGB888).copy(); av_freep(&dstData[0]); sws_freeContext(sws);

这段代码里有两个关键点。第一，目标格式用的是AV_PIX_FMT_RGB24，不是BGR24。如果写成BGR24，画出图后红蓝两个通道会互换，人物的脸会变成青紫色。第二，av_image_alloc的align参数给32，是为了让目标行的字节数按32字节对齐，兼顾性能和内存访问安全。最后必须调用copy()，把QImage从dstData指针上独立出来，否则后面av_freep一释放，QImage就成了空壳。

2.3 为什么用线程而不是在GUI线程里直接拉流

不少初版Demo直接在按钮的槽函数里调av_read_frame，结果播放开始后窗口拖不动、按钮点不了，因为网络阻塞加上解码计算把Qt事件循环卡死了。RTSP流从网络读到一帧要几到几十毫秒，期间任何UI交互都会被排队，表现出来就是窗口假死。

正确做法是单独开一个工作线程，把avformat_open_input、av_read_frame、avcodec_send_packet、avcodec_receive_frame这一整条链路放在线程里跑，每解出一帧通过信号发给主线程。主线程的槽函数只做图像拷贝和控件更新，不碰任何解码逻辑。

线程类的基础结构可以这样设计：

class VideoThread : public QObject { Q_OBJECT public: explicit VideoThread(QObject* parent = nullptr); ~VideoThread() override; public slots: void startPlay(const QString& rtspUrl); void stopPlay(); signals: void frameReady(const QImage& image); void errorOccurred(const QString& message); private: AVFormatContext* fmtCtx = nullptr; AVCodecContext* codecCtx = nullptr; QAtomicInt running{false}; };

这里running用一个原子变量而不是普通bool，是因为它会被工作线程和UI线程同时读写。普通bool的读写不是原子操作，可能在一个线程刚写入一半时另一个线程就读取了，轻则功能错乱，重则崩溃。原子变量解决的是这个可见性和顺序问题，不需要额外加锁。

视频帧信号用QImage跨线程传递时，Qt的元对象系统会自动选择队列连接，copy-on-write语义会让传递成本很低。但要注意，发送方不能在线程结束时再发信号，否则主线程可能收到一个空壳对象。这个生命周期问题，到第5章避坑时再详细拆。

3. 从零搭一个Qt+FFmpeg RTSP播放Demo：环境配置与最小线程框架

原理清楚了，这一章直接组装一个能跑起来看到实时画面的最小工程。工程结构不复杂：main.cpp负责启动事件循环，videothread.cpp封装解码线程，widget.cpp放一个QLabel和两个按钮。我会把每个文件的写法拆开讲，你照着建文件就能在本地复现。

3.1 工程配置：CMake里引FFmpeg库的正确姿势

第2章用pkg-config解决了Linux的配置问题，但Windows上MSVC编译时，比较省心的方法是把FFmpeg的include和lib目录统一放到第三方目录里，然后在CMake里手动指定。

set(FFMPEG_ROOT "C:/thirdparty/ffmpeg") find_path(AVCODEC_INCLUDE_DIR libavcodec/avcodec.h PATHS ${FFMPEG_ROOT}/include) find_library(AVCODEC_LIBRARY avcodec PATHS ${FFMPEG_ROOT}/lib) # 复制一份给libavformat、libavutil、libswscale find_path(AVFORMAT_INCLUDE_DIR libavformat/avformat.h PATHS ${FFMPEG_ROOT}/include) find_library(AVFORMAT_LIBRARY avformat PATHS ${FFMPEG_ROOT}/lib) include_directories( ${AVCODEC_INCLUDE_DIR} ${AVFORMAT_INCLUDE_DIR} ) target_link_libraries(rtsp_demo PRIVATE ${AVCODEC_LIBRARY} ${AVFORMAT_LIBRARY} ${AVUTIL_LIBRARY} ${SWSCALE_LIBRARY})

用find_path/find_library的好处是，头文件和库的路径没有硬编码在代码里，换一台机器只需要改FFMPEG_ROOT。编译时会遇到的一个常见问题：FFmpeg的共享库在Windows上还有后缀的dll导入库，比如avcodec.lib，但在Linux上是libavcodec.so，CMake的find_library会自动匹配当前平台，不用自己去区分。

真正要留意的是库的依赖顺序。链接FFmpeg的静态库时，libavformat和libavcodec都依赖libavutil，还有可能依赖libswresample，链接顺序写错会报一堆undefined reference。保守做法是把所有FFmpeg库全部列出来，并让依赖库排在后面。示例里没列libswresample，如果你的FFmpeg版本里avformat依赖它，补上就好。

3.2 解码线程的骨架：循环读帧、解码、转换

工程里最核心的就是videothread.cpp的startPlay函数。它要做的事按顺序拆：打开RTSP地址，拿到流信息，找到视频流，创建解码器上下文，然后进入一个循环反复读包、解包、发帧。

void VideoThread::startPlay(const QString& rtspUrl) { running.store(true); AVFormatContext* fmt = nullptr; AVDictionary* opts = nullptr; av_dict_set(&opts, "rtsp_transport", "tcp", 0); av_dict_set(&opts, "stimeout", "3000000", 0); int ret = avformat_open_input(&fmt, rtspUrl.toStdString().c_str(), nullptr, &opts); if (ret < 0) { emit errorOccurred("打开RTSP失败: " + QString::fromUtf8(av_err2str(ret))); return; } ret = avformat_find_stream_info(fmt, nullptr); if (ret < 0) { emit errorOccurred("无法获取流信息"); return; } int videoIndex = -1; for (unsigned int i = 0; i < fmt->nb_streams; ++i) { if (fmt->streams[i]->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) { videoIndex = static_cast<int>(i); break; } } if (videoIndex < 0) { emit errorOccurred("未找到视频流"); return; } AVCodecParameters* params = fmt->streams[videoIndex]->codecpar; const AVCodec* codec = avcodec_find_decoder(params->codec_id); AVCodecContext* codecCtx = avcodec_alloc_context3(codec); avcodec_parameters_to_context(codecCtx, params); if (avcodec_open2(codecCtx, codec, nullptr) < 0) { emit errorOccurred("解码器打开失败"); return; } AVPacket* packet = av_packet_alloc(); AVFrame* frame = av_frame_alloc(); while (running.load() && av_read_frame(fmt, packet) >= 0) { if (packet->stream_index == videoIndex) { ret = avcodec_send_packet(codecCtx, packet); if (ret < 0) { av_packet_unref(packet); continue; } while (avcodec_receive_frame(codecCtx, frame) == 0) { QImage img = convertToQImage(frame); // 复用2.2的转换代码 if (!img.isNull()) { emit frameReady(img); } av_frame_unref(frame); } } av_packet_unref(packet); } av_frame_free(&frame); av_packet_free(&packet); avcodec_free_context(&codecCtx); avformat_close_input(&fmt); }

两个关键参数在代码里写得很明白：rtsp_transport=tcp强制走TCP传输。UDP在弱网下会丢包，花屏和马赛克频繁出现，TCP用重传换流畅，代价是延迟会稍微高一点，但作为播放稳定性的首选没错。stimeout单位是微秒，3000000就是3秒，超过这个时间连不上或读不到数据就返回错误，不会让界面一直停在“连接中”。

这段代码里还有一个容易忽略的坑：avformat_open_input的URL参数必须是有效且生命周期足够长的char*。直接传rtspUrl.toStdString().c_str()会构造一个临时string，取到c_str后传给函数，但函数内部可能不会马上复制这个字符串，如果临时对象析构了，行为就不可预料。稳妥做法是提前用一个std::string或QByteArray把转换结果存下来，再把_.data()传进去。

3.3 在QLabel上显示第一帧：把AVFrame转成QImage

videothread把QImage发到主线程，主线程这边要做的就是接住信号，把它显示出来。这一层逻辑没有花活，但顺序错了同样会出问题。

void MainWidget::onFrameReady(const QImage& image) { // 先保存一份，用于快照功能 lastFrame = image; QLabel* label = ui->videoLabel; label->setPixmap(QPixmap::fromImage(image) .scaled(label->size(), Qt::KeepAspectRatio, Qt::SmoothTransformation)); }

如果界面里只看到一帧，多半是线程启动时序不对。正确的启动姿势是：先创建VideoThread对象并moveToThread，再启动QThread，然后用一个自定义信号触发startPlay，这样才能保证startPlay跑在子线程里。

// 按钮点击的处理 workerThread = new QThread(this); videoThread = new VideoThread; videoThread->moveToThread(workerThread); connect(workerThread, &QThread::finished, videoThread, &QObject::deleteLater); connect(videoThread, &VideoThread::frameReady, this, &MainWidget::onFrameReady); connect(videoThread, &VideoThread::errorOccurred, this, &MainWidget::onThreadError); connect(this, &MainWidget::requestStart, videoThread, &VideoThread::startPlay); connect(this, &MainWidget::requestStop, videoThread, &VideoThread::stopPlay); workerThread->start(); emit requestStart(ui->urlEdit->text());

新手常犯的错误是直接调用videoThread->startPlay()，因为startPlay是普通槽函数，谁调用就在谁的线程里执行。点了按钮后，UI线程会阻塞在av_read_frame里，效果和不用线程并没什么区别。必须把startPlay通过信号连接到子线程对象上，让Qt的事件循环把它调度到workerThread里执行。

4. 让画面动起来并可控：播放、暂停、停止与延时控制

很多Demo能做到第一帧显示就停了，但实际项目至少需要播放/暂停/停止三个操作。这一章把控制逻辑加进去，同时给出几个直接影响播放延迟的FFmpeg参数。理解了这些，你手里的Demo才算有了成为播放器的底子。

4.1 暂停不是停线程：用标志位控制解码循环

直接在暂停槽里调stopPlay会把线程停掉，再次播放时重新连接RTSP，等待时间少说一两秒，而且摄像头或后端设备不一定允许频繁建立新会话。正确的做法是让解码线程继续跑，但在发送帧之前检查暂停标志，暂停时阻塞等待恢复。

// VideoThread里增加控制成员 QAtomicInt paused{false}; QMutex pauseMutex; QWaitCondition pauseCond; // 解码循环中，解出一帧后发送前检查 if (paused.load()) { pauseMutex.lock(); pauseCond.wait(&pauseMutex); // 线程在这里暂停 pauseMutex.unlock(); }

UI线程的暂停按钮只需改标志位：

void MainWidget::onPauseBtn() { if (videoThread) { videoThread->pause(); } } void MainWidget::onResumeBtn() { if (videoThread) { videoThread->resume(); } }

对应的pause和resume实现：

void VideoThread::pause() { paused.store(true); } void VideoThread::resume() { paused.store(false); pauseCond.wakeAll(); }

这里wait会释放pauseMutex，所以resume里唤醒时不需要再额外加锁。为什么不直接用一个布尔变量sleep循环？因为忙等会占满一个CPU核心，QWaitCondition才让出CPU。要注意的是，暂停状态下av_read_frame仍会继续读取网络数据，部分摄像头会在TCP层累积缓存，恢复播放后可能先看到几秒钟的旧画面。这个很难完全避免，但可以通过4.3里的缓冲控制来减轻。

4.2 快照与拖动：这个Demo能做到什么程度

快照逻辑非常简单，因为每一帧都已经到了主线程的槽函数里。在前面的onFrameReady里我们保存了lastFrame，快照按钮只需一行保存：

void MainWidget::onSnapshotBtn() { if (!lastFrame.isNull()) { QString name = QDateTime::currentDateTime().toString("yyyyMMdd_hhmmss") + ".png"; lastFrame.save(name); } }

需要说明的是，lastFrame = image这一步是深拷贝吗？QImage的拷贝构造函数是浅拷贝，但它的底层是隐式共享，当image是视频帧转换过来时，如果上一个QImage还持有同一缓冲区，两边会共享。为了确保快照不随下一帧刷新而改变，需要在赋值时调用copy()，或者像这样再额外拷贝：

void MainWidget::onFrameReady(const QImage& image) { lastFrame = image.copy(); // 强制深拷贝 // ...显示代码 }

拖动进度条方面，这个Demo不打算做。RTSP的直播流大多没有可seek的索引，服务器只会按实时时间推流，AVFormatContext里的start_time往往也是无效的。如果是本地RTSP文件点播，可以用av_seek_frame去碰碰运气，但失败率不低。做监控类的实时预览，直接用暂停和快照就够了，拖进度条是另一套针对on-demand流的工程问题。

4.3 参数调优：三个直接影响延迟的FFmpeg开关

RTSP延迟高，除了网络物理距离，播放端的接收缓冲和解码积压占了很大比例。下面这张表列出三个最值得调的参数，每项都给出惯用值和使用场景。

除了这三个，解码线程和UI线程之间的帧队列长度也需要限制。如果解码速度比显示速度快，Qt信号队列里会堆积大量QImage，延迟越来越大。最简单的控制方法是让VideoThread在每解出一帧后，检查上一次发送的帧是否已经被UI处理完。

// VideoThread里增加一个计数器 QAtomicInt pendingFrames{0}; // 发帧前检查 if (pendingFrames.load() > 0) { // 上一帧还没被处理，说明UI已经落后了，丢弃当前帧 av_frame_unref(frame); continue; } pendingFrames.store(1); emit frameReady(img);

主线程的槽函数处理完后，需要把计数器减回去：

void MainWidget::onFrameReady(const QImage& image) { lastFrame = image.copy(); // ...显示 if (videoThread) { videoThread->frameConsumed(); } }

frameConsumed里执行pendingFrames.store(0)。这个策略对实时流很实用，它保证UI永远显示最新的一帧，而不是积压的旧帧。延迟会稳定在一个小范围内，代价是编码器输出的某些中间帧被丢弃，这在视觉上几乎感知不到。

5. 避坑：RTSP播放里最常见的5个翻车现场和排查方法

框架能跑起来只算过了第一关。实际接入摄像头、NVR或者网络视频平台时，各种奇怪问题比解码本身费神。这一章整理了5个我见过好几次的坑，每个都按“现象、原因、解决”的顺序写，方便你直接对号入座。

5.1 画面卡成PPT：是网络还是解码跟不上

现象：视频能播放，但帧率只有一两帧，CPU占用率却只有20%左右，关掉界面缩放也没有明显改善。

原因：一类是网络层丢包导致重传，TCP抓包能看到大量重传；另一类是FFmpeg解码器内部缓冲较大，视频源是低帧率或关键帧间隔很长，播放端必须在缓冲积累到一定量才开始出帧。

解决：先用ffprobe对同一个RTSP地址做探测，观察Duration和Start Time是否正常。然后加大stimeout到10秒，排除网络抖动。如果问题依旧，把rtsp_transport从tcp切回udp试试，某些网络环境下UDP反而更流畅。最后检查代码里是否对图像做了不必要的scaled，QLabel本身可以设置setScaledContents(true)，避免每帧都做一次缩放计算。

5.2 程序退出时崩溃：线程和QObject的生命周期没管好

现象：关闭窗口时控制台打印“QThread: Destroyed while thread is still running”，或者在avcodec_free_context里段错误。

原因：窗口析构时，QThread对象先于子线程结束被销毁，而解码循环还悬挂在子线程里，拿着已经释放的AVCodecContext继续用。

解决：必须在主窗口的closeEvent或析构函数里，按顺序停止线程：

void MainWidget::closeEvent(QCloseEvent* event) { if (videoThread) { emit requestStop(); // 让running置false，退出循环 workerThread->quit(); // 退出QThread事件循环 workerThread->wait(); // 等待线程真正结束 } QWidget::closeEvent(event); }

顺序不能反。先让解码循环退出，再quit和wait。如果先用wait，而子线程还在av_read_frame阻塞，wait会无限等待下去。有些RTSP源在stimeout设得很大时，av_read_frame会卡几十秒，这时候需要把stimeout调小，或者把stopPlay设计成先中断阻塞。

5.3 画面颜色偏绿/偏紫：像素格式转换踩的坑

现象：人物肤色发绿，或者整个画面呈现紫青色偏色，但轮廓和运动是正常的。

原因：最常见的是AVFrame的format不是YUV420P而是NV12或YUVJ420P，却依然按YUV420P初始化sws。另一种情况是转换目标用了BGR24而QImage用了Format_RGB888，造成红蓝通道互换。

解决：解码后打一行日志，把frame->format打印出来，根据实际format创建sws。如果想兼容多种格式，代码里可以先判断format再映射到AV_PIX_FMT_YUV420P或AV_PIX_FMT_NV12。对于红蓝互换，把sws目标格式和QImage格式配对检查：AV_PIX_FMT_RGB24对应Format_RGB888；AV_PIX_FMT_BGR24对应Format_BGR888。不要想当然。

5.4 延迟越来越大：队列没有限长或没有清空策略

现象：刚打开时延迟几百毫秒，播放五分钟后延迟到两三秒，暂停再恢复能暂时追回来。

原因：解码线程持续解码，UI线程的显示速度低于解码速度，Qt信号队列里的帧越积越多。延迟就是这些积压帧的播放耗时。

解决：按4.3的pendingFrames计数方案限制队列深度。如果队列里已经有上一帧未处理，就丢弃当前帧。还要注意QImage的scaled如果放在槽函数里，耗时会被计入UI线程的每帧处理时间，间接加大积压。把scaled改成在解码线程内完成，或者在QLabel上设置scaledContents，让Qt在绘制时再缩放，效果更好。

5.5 认证失败：RTSP URL里的用户名密码带特殊字符

现象：avformat_open_input返回Authentication failed，但同一个地址用通用播放器却能正常打开。

原因：URL里直接写用户名密码时，如果密码或用户名里含有@、%、/等字符，没有做百分号编码，FFmpeg会把密码后面的部分误认为是主机地址，认证自然失败。

解决：拼URL前对用户名密码做URL编码：

QString user = "admin"; QString pass = "p@ss:123"; QString encodedUser = QString::fromUtf8(QUrl::toPercentEncoding(user)); QString encodedPass = QString::fromUtf8(QUrl::toPercentEncoding(pass)); QString url = QString("rtsp://%1:%2@192.0.2.10:554/stream") .arg(encodedUser, encodedPass);

注意@符号在密码里会被解析分隔，必须先编码成%40。还有的摄像头在路径后带?参数，整个URL的query部分也要保证特殊字符被转义。最后提醒一句：把明文密码写进URL本身就不安全，正式产品建议在代码里从配置文件读取，URL只作为运行时临时拼接的结果。

6. 从Demo到可用播放器：低延迟、硬解码与多路流的进阶思路

如果你要把这个Demo投入到正式项目里，建议先做三件事。

第一件事，针对实时画面延迟，把FFmpeg的probesize和analyzeduration调小。这两个参数影响打开流时的探测时间，默认值会多读几百毫秒的数据来确定参数，对直播场景是没必要的开销。在avformat_open_input之后、avformat_find_stream_info之前加一行配置：

fmt->probesize = 32 * 1024; fmt->analyzeduration = 500000; // 0.5秒

调小后首帧出现更快，但遇到H.265或高码率流，探测不足可能导致找不到码流参数。建议先用默认值跑通，再逐步调小观察首帧时间和画面稳定性的平衡。

第二件事，桌面端优先启用硬解码。Windows上可以用d3d11va，Linux上用vaapi，macOS上用videotoolbox。硬解码能把CPU占用从80%降到20%以下，对多路流尤其重要。但它有个额外步骤：硬解码出来的AVFrame的format是硬件格式，不能直接送给sws_scale，得先用av_hwframe_transfer_data把帧从GPU拷贝回CPU，再走RGB转换。那一坨代码不难，但要注意判断硬件帧何时不需要拷贝，何时必须拷贝，不同平台的API行为略有差异。

第三件事，多路流播放时，不要让每路画面都在UI线程里做高清缩放。我见过一个项目把四路1080p的scaled都放在QLabel更新里，UI线程每帧要拷十几MB数据，界面直接变成幻灯片。合适的做法是在解码线程里先把帧缩放到需要的显示尺寸，比如640x360，然后才跨线程发送。这样内存带宽消耗和UI负担都小得多，四路同时跑也能保持30fps。这也是我经历过的教训：一开始觉得显示尺寸小，问题不大，结果一上四路就崩。后来改成在线程里预缩放，才彻底解开卡顿。

这个Demo本身的价值不在于播放一个RTSP地址，而在于把拉流、解码、线程、显示这一条链路的边界画清楚了。你往里加录制、加录像回放、加音频，都绕不开这一章提到的几个决策点。希望帮到你。

本文还有配套的精品资源，点击获取