opencv mat不能直接推rtsp流，必须经h.264编码成nalu、rtp打包后才能被rtsp服务器接收；核心路径是cv::mat → avframe（bgr→yuv420p转换）→ libx264编码 → 提取sps/pps → rtp分片封装（fu-a处理）→ udp发送，全程内存操作以保障低延迟。
OpenCV Mat怎么转成RTSP能收的H.264流
不能直接推 cv::Mat，RTSP服务器（如FFmpeg、GStreamer或Live555）只认标准编码后的字节流，不是OpenCV的内存图像。必须先用H.264编码器把BGR/RGB帧压成NAL单元，再按RTP打包，最后走RTSP协议栈。
常见错误是试图用 cv::imwrite 或直接写文件再读取推流——延迟高、不可控、根本不是实时流。真正低延迟路径是内存中完成编码 → RTP分包 → UDP发送，全程不落盘。
- 推荐用FFmpeg的libavcodec + libavformat做编码和复用，它支持软编（
libx264）和硬编（h264_nvenc、h264_qsv），性能和兼容性最稳 - OpenCV自带的
cv::VideoWriter仅支持写文件或部分后端（如cv::CAP_FFMPEG），但无法控制RTP头、SPS/PPS插入时机，不适合RTSP推流 - 若用GStreamer，需构造pipeline：
appsrc ! videoconvert ! x264enc ... ! rtph264pay ! udpsink，但C++调用需处理GstBuffer与cv::Mat数据拷贝，注意内存对齐和时间戳
如何用FFmpeg把Mat喂给libx264编码
核心是把cv::Mat的BGR数据转成FFmpeg的AVFrame，并确保格式匹配（如AV_PIX_FMT_BGR24 → AV_PIX_FMT_YUV420P）。跳过格式转换会触发编码器崩溃或输出花屏。
关键步骤：
- 初始化
AVCodecContext时设pix_fmt = AV_PIX_FMT_YUV420P（H.264 baseline/main要求），再用sws_getContext()创建转换器，把cv::Mat的data指针送入sws_scale() - 为每帧填
AVFrame->pts，单位是AV_TIME_BASE，建议用单调递增的frame_count * av_rescale_q(1, time_base, c->time_base)，否则播放器卡顿或音画不同步 - 编码返回
avcodec_send_frame()和avcodec_receive_packet()必须成对调用；未flush完会导致末尾几帧丢失 - 记得在第一帧前输出SPS/PPS：从
AVCodecParameters->extradata提取，或监听AVPacket->flags & AV_PKT_FLAG_KEY判断IDR帧
RTSP推流必须自己实现RTP打包吗
不用从零写RTP头，但必须控制关键字段。FFmpeg本身不生成RTP包，它只输出H.264 Annex.B格式的AVPacket（含start code 0x00000001）。你需要手动拆NALU、填RTP header（timestamp、sequence number、marker bit），再UDP发给RTSP服务器或直接发给拉流端。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
容易踩的坑：
- RTP timestamp不是系统时间，而是基于90kHz时钟累加：
timestamp += 90000 * frame_duration_sec，且要和编码器time_base对齐 - 单个NALU超过1400字节（典型MTU）必须用FU-A分片，漏处理会导致接收端丢整帧；
nal_unit_type == 28才是FU-A，不是所有长NALU都要分 - SPS/PPS必须作为独立RTP包发送，且
marker=1，否则VLC/ffplay无法解码——很多demo只发了视频NALU，没单独推SPS/PPS
有没有轻量级现成方案绕过FFmpeg复杂API
有，但得接受限制。比如用cv::VideoWriter配合"rtsp://..."地址（仅限OpenCV 4.5.5+且编译时启用了WITH_FFMPEG），内部会调FFmpeg，但参数不可控：
- 无法指定profile（baseline）、level、bitrate动态调整，固定参数易卡顿或超带宽
- 不暴露RTP timestamp接口，网络抖动时同步差
- 错误全打
stderr，无回调机制，连接断开难感知 - 实测延迟常在800ms以上，而手动FFmpeg+RTP可压到120ms内（1080p@30fps）
真要快速验证，可用ffmpeg -f v4l2 -i /dev/video0 -c:v libx264 -f rtsp rtsp://localhost:8554/stream起一个中转服务，再用OpenCV读帧→存临时文件→触发FFmpeg重推——但这不是“实时”，是伪实时，只适合调试。
真正生产环境，绕不开手动管理FFmpeg编码管线和RTP打包逻辑，尤其当需要多路并发、动态码控或对接自定义RTSP服务器时，SPS/PPS的时机、RTP序列号连续性、时间戳精度这些细节，错一点就播不出画面。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
