rtsp协议无法设置解码(rtsp连接异常处理)

rtsp 交互失败是什么原因?

解码器出现了问题。

RTSP（Real Time Streaming Protocol），RFC2326，实时流传输协议，是TCP/IP协议体系中的一个应用层协议，由哥伦比亚大学、网景和RealNetworks公司提交的IETF RFC标准。该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。

RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或UDP完成数据传输。HTTP与RTSP相比，HTTP请求由客户机发出，服务器作出响应；使用RTSP时，客户机和服务器都可以发出请求，即RTSP可以是双向的。

RTSP是用来控制声音或影像的多媒体串流协议，并允许同时多个串流需求控制，传输时所用的网络通讯协定并不在其定义的范围内，服务器端可以自行选择使用TCP或UDP来传送串流内容，它的语法和运作跟HTTP 1.1类似，但并不特别强调时间同步，所以比较能容忍网络延迟。

而前面提到的允许同时多个串流需求控制（Multicast），除了可以降低服务器端的网络用量，更进而支持多方视讯会议（Video Conference）。

因为与HTTP1.1的运作方式相似，所以代理服务器〈Proxy〉的快取功能〈Cache〉也同样适用于RTSP，并因RTSP具有重新导向功能，可视实际负载情况来转换提供服务的服务器，以避免过大的负载集中于同一服务器而造成延迟。

RTSP请求可以几种不同方式传送：

1、持久传输连接，用于多个请求/响应传输。

2、每个请求/响应传输一个连接。

3、无连接模式。

传输连接类型由RTSP URL来定义。对“rtsp'’方案，需要持续连接；而"rtspu"方案，调用RTSP请求发送，而不用建立连接。

不像HTTP，RTSP允许媒体服务器给媒体用户发送请求。然而，这仅在持久连接时才支持，否则媒体服务器没有可靠途径到达用户，这也是请求通过防火墙从媒体服务器传到用户的惟一途径。

有关opencv无法解码网络摄像头rtsp流的解决办法

首先连接还是正常的使用videocapture（）函数，传入地址后用imshow（）读取视频流。

重点来了， rtsp流无法读取的时候。我们一般能在网络摄像头中找到有关码流的设置

其中主码流是rtsp格式，而辅码流是可以选择mpeg格式的。

这就是解决问题的重点，既然我们无法用imshow（）函数播放rtsp码流，那么可以曲线救国，选择mpeg格式的辅助码流！

监控rtsp交互失败怎么回事?

原因是将摄像机接入EasyNVR之后，出现摄像机经常拉流失败的情况，于是系统过于频繁重连，导致摄像机把EasyNVR禁用拉流。市面上确实有部分摄像机有这个机制，不允许拉流客户端在拉流失败后，一直循环向摄像机发送拉流请求。

如果一直请求，会把拉流客户端禁用，导致后续无法拉流。目前EasyNVR的重连机制恰巧就是不断向终端发送拉流请求，导致EasyNVR被禁用，拉流失败。针对此类情况，需要对EasyNVR拉流重连机制进行了优化。在EasyNVR拉流失败且重连超时后，才重新发起连接请求。

相关信息

实时传输协议（RTP）是一个网络传输协议，它是由IETF的多媒体传输工作小组1996年在RFC 1889中公布的。国际电信联盟ITU-T也发布了自己的RTP文档，作为H.225.0，但是后来当IETF发布了关于它的稳定的标准RFC后就被取消了。

作为因特网标准在RFC 3550（该文档的旧版本是RFC 1889）有详细说明。RFC 3551（STD 65，旧版本是RFC 1890）详细描述了使用最小控制的音频和视频会议。RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。

它一开始被设计为一个多播协议，但后来被用在很多单播应用中。RTP协议常用于流媒体系统（配合RTSP协议），视频会议和一键通（Push to Talk）系统（配合H.323或SIP），使它成为IP电话产业的技术基础。RTP协议和RTP控制协议RTCP一起使用，而且它是创建在UDP协议上的。