c++ - FFMPEG: 'Nonmatching transport in server reply' 但 openRTSP 有效

Question

我买了一个便宜的中国网络摄像机(GWIPC-26xxx/Yoosee)。我想用 ffmpeg 记录它的流。
在 FFMPEG 上，我设法让它工作 仅限 使用 RTSP/UDP 传输协议(protocol)，如下所示。它在 VLC 上也能完美播放。

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

pass是在安卓相机应用客户端上定义的密码。
但是 我非常喜欢 RTSP/TCP 传输 因为使用 UDP 图像是 经常损坏。出现涂抹和撕裂的图像。所以我几乎测试了任何东西，甚至编译了 FFMPEG从源使用 latest repository .但是没有什么能让ffmpeg工作，android或windows。如果使用 -rtsp_transport tcp我总是最终收到:

[rtsp @ 0xxxxxxx] Nonmatching transport in server reply

终于发现了 openRTSP使用与 VLC 相同的库。有了它，我设法使它使用 RTSP/TCP 连接(从源代码编译后)。

openRTSP -n -D 1 -c -B 10000000 -b 10000000 -q -Q -F cam_file \ 
-d 60 -P 30 -t -u admin pass rtsp://192.168.0.103:554/onvif1

更多详情请访问 openRTSP参数 here .
最奇怪的部分是 的比较RTSP 设置消息 (FFMPEG 与 openRTSP)。很明显，网络摄像机服务器支持 RTP/AVP/TCP。 RTP 交织到现有的 TCP 连接中。
并查看 ffmpeg/libavformat/rtsp.c 的源代码它接缝 ffmpeg 在识别它时遇到了一些问题？

...
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;
}
...

Answer 1

Quoting Wisdom

IP cameras are of varying quality, some behaving erratically in my experience. Dealing with their RTSP streams requires a dose of fault-tolerance.
This appears to be a byproduct of the low-end of the CCTV industry playing fast and loose with standards, RTSP and ONVIF being the two most frequently abused.Fortunately, you can usually work around these problems. Unless your IP cameras and controller are all designed to play nicely together, only use ONVIF for once-only discovery and settings management.

FFMPEG 在 RTSP 设置中不是很宽容
挣扎之后，我开始比较 RTSP/ 设置 openRTSP 之间的消息和 ffmpeg . openRTSP默认情况下已经输出了很多详细的诊断信息。
开放RTSP openRTSP发送命令 OPTIONS , DESCRIBE然后 SETUP .设置消息是:

Sending request: SETUP rtsp://192.168.0.103:554/onvif1/track2 RTSP/1.0
CSeq: 6
Authorization: Digest username="admin", realm="HIipCamera", nonce="ddd21dbd0620b6fb4b1f9bcbb06340a0", uri="rtsp://192.168.0.103:554/onvif1", response="91d9c611aa004eeb1390b3fbb9373648"
User-Agent: ./openRTSP (LIVE555 Streaming Media v2021.02.11)
Transport: RTP/AVP/TCP;unicast;interleaved=2-3
Session: 3a4d2e6d

相机回应:

Received a complete SETUP response:
RTSP/1.0 200 OK
CSeq: 6
Transport: RTP/AVP;unicast;destination=192.168.0.100;source=192.168.0.103;interleaved=2-3
Session: 3a4d2e6d;timeout=60

FFMPEG
对于 FFMPEG你必须使用 -v 9 and -loglevel 99参数以查看 RTSP 消息。它只发送了 DESCRIBE请求是:

DESCRIBE rtsp://192.168.0.103:554/onvif1 RTSP/1.0
Accept: application/sdp
CSeq: 2
User-Agent: Lavf58.67.100

相机回应:

Transport: RTP/AVP;unicast;destination=192.168.0.100;source=192.168.0.103;interleaved=0-1
Session: 37287775;timeout=60

RTSP 滥用和 FFMPEG hacking-解决方案
比较消息很明显，相机可以使用 RTSP/AVP/TCP 交错 TCP 连接。但我们可以通过摄像头的回答看到，在“运输:”行中它不包括 。 'TCP' 之后 'RTP/AVP' 按照要求。喜欢:

Transport: RTP/AVP/('TCP' missing here);....

我分析了代码和 ffmpeg/libavformat/rtsp.c并找到以下直观的调用顺序: ff_rtsp_connect , ff_rtsp_make_setup_request , ff_rtsp_send_cmd , ff_rtsp_read_reply和 ff_rtsp_parse_line .在最后一个里面我发现了 rtsp_parse_transport和以下代码:

if (!av_strcasecmp(lower_transport, "TCP"))
    th->lower_transport = RTSP_LOWER_TRANSPORT_TCP;
else
    th->lower_transport = RTSP_LOWER_TRANSPORT_UDP;

lower_transport是 'RTP/AVP;' 之后解析的文本在我的情况下是 ""空字符字符串，因为相机服务器不包含它。
我插入了 || !av_strcasecmp(lower_transport, "")在代码中。假设传输是 RTSP_LOWER_TRANSPORT_TCP当 lower_transport被省略。像下面这样:

if (!av_strcasecmp(lower_transport, "TCP") || !av_strcasecmp(lower_transport, ""))
    th->lower_transport = RTSP_LOWER_TRANSPORT_TCP;
else
    th->lower_transport = RTSP_LOWER_TRANSPORT_UDP;

这个用于 ffmpeg 的小补丁 (git) 可用 here .使用 git am < RTSP_lower_transport_TCP.patch 申请在 ffmpeg git repo 上。
重新编译后:FFMPEG 运行良好!
我 破解 FFMPEG 使其能够容忍摄像机服务器正在执行的 RTSP 滥用。由于我的 FFMPEG 版本只能在我未使用的 android 电视(作为 cctv/nvr 摄像机服务器)上运行，因此不会产生任何其他问题。
更好的解决方案是 FFMPEG ( Ticket)，还要考虑 rtsp 服务器答案上缺少较低传输的情况。然后与客户端发送的请求进行比较，以定义是否省略了较低的传输。并尝试与之建立联系。
建议
可能如果您到达这里，您的网络摄像机 可能遭受一些 RTSP 滥用。我建议您尝试使用 openRTSP首先看看它是否设法连接。如果是这样，则尝试调试其 RTSP/设置消息。如果您修改(风险自负) ffmpeg/libavformat/rtsp.c，则可能存在一些自定义或黑客解决方案。代码。或者你可能/应该使用 live555 库、VLC 或 mplayer。