FFmpeg使用RTSP/TCP传输Yoosee（GWIPC-26xxx）IP摄像头流时报错“Nonmatching transport in server reply”求助

我之前处理过不少非标准RTSP设备的兼容性问题，结合你已经排查出的FFmpeg源码细节，这里给你几个可行的解决思路：

1. 修改FFmpeg源码绕过严格传输协议检查 #

你已经定位到核心问题：这款摄像头的RTSP服务器返回的RTP/AVP/TCP传输格式虽然合法，但和FFmpeg预期的枚举值匹配逻辑存在偏差，触发了"Nonmatching transport"报错。

你可以临时修改libavformat/rtsp.c中的判断逻辑来绕过检查：

// 找到原代码段
if (reply->transports[0].lower_transport != lower_transport) {
    av_log(s, AV_LOG_ERROR, "Nonmatching transport in server reply\n");
    err = AVERROR_INVALIDDATA;
    goto fail;
}

// 修改为以下内容（或直接注释掉整个判断块）：
if (reply->transports[0].lower_transport != lower_transport) {
    // 仅打印警告而非直接终止连接
    av_log(s, AV_LOG_WARNING, "Nonmatching transport in server reply, proceeding anyway\n");
    // 注释掉原错误退出逻辑
    // err = AVERROR_INVALIDDATA;
    // goto fail;
}

修改后重新编译FFmpeg，再执行TCP模式的录制命令：

ffmpeg -rtsp_transport tcp -i rtsp://admin:pass@192.168.0.103:554/onvif1 streamfile.mkv

这种方法能直接解决兼容性问题，但需要你自行编译FFmpeg源码。

2. 尝试FFmpeg兼容参数调整 #

部分非标准RTSP设备可以通过调整FFmpeg参数绕过兼容性限制，你可以试试这个命令：

ffmpeg -rtsp_transport tcp -rtsp_flags prefer_tcp -stimeout 5000000 -analyzeduration 0 -probesize 32 -i rtsp://admin:pass@192.168.0.103:554/onvif1 streamfile.mkv

关键参数说明：

• -rtsp_flags prefer_tcp：强制优先使用TCP传输
• -stimeout 5000000：设置5秒RTSP会话超时，避免设备响应慢导致连接失败
• -analyzeduration 0 -probesize 32：减少流探测时间，适配廉价设备不标准的流头格式

3. 用openRTSP做中间转发层 #

既然你已经确认openRTSP能正常通过TCP连接摄像头，可以用它作为中间层，把流转发给FFmpeg处理，无需修改任何源码：

openRTSP -n -D 1 -c -B 10000000 -b 10000000 -q -Q -P 30 -t -u admin pass rtsp://192.168.0.103:554/onvif1 | ffmpeg -i - -c copy streamfile.mkv

这个方案利用openRTSP基于live555库的兼容性优势，通过管道将流传递给FFmpeg，-c copy参数还能避免重新编码，保证录制效率和画质。

问题根源说明 #

这款GWIPC-26xxx/Yoosee摄像头的RTSP服务器实现并不完全符合RFC标准——虽然它支持RTP over TCP交织传输，但返回的Transport响应头格式和FFmpeg的严格匹配逻辑不一致，导致触发报错。而openRTSP对非标准RTSP服务器的兼容性处理更宽松，因此能正常建立连接。

内容的提问来源于stack exchange，提问作者imbr