之前写过一个 rtsp server 作为服务端的简单demo
这次分析下 rtsp作为客户端 推流和拉流时候的过
A.作为客户端拉流 TCP方式
1.Client发送OPTIONS方法 Server回应告诉支持的方法
2.Client发送DESCRIPE方法 这里是从海康摄像机拉流并且设置了用户名密码 Server回复未认证
3.客户端通过服务器回复的realm nonce 计算response 重新带认证信息的DESCRIBE报文
服务器回复
4.客户端发送SETUP报文
5.客户端发送 PLAY报文
RTSP交互的过程如上
实际测试中发现 几点需要注意：
a.需要用户密码的 大多数是在发送DESCRIBE方法后返回401 有的是第一次发送OPTIONS方法就会返回401
b.服务端包含视频流 音频流 必须单独发送一次SETUP视频流 再发送一次SETUP音频流 我本来想只要视频流 不要音频流 但是实测发现不行 必须 视频流 音频流都SETUP
c.最后发送play报文之后 server回复报文的时候大多数时候 会将rtp报文连带一起发过来
需要做切割
需要用户名密码时候的认证信息计算 大多数都是走DIGEST方式 仅仅介绍此种方式
首先计算loginhash 计算方法为 MD5(username:realm:password) 之后转换为字符串
然后针对method和uri计算method_hash MD5(method:uri)
需要注意的是:SETUP时候的uri 和其他方法的uri是不一样的
最后计算response = MD5(MD5(loginhash:nonce):method_hash) 如下图
整个过程中 loginhash只需要计算一次既可 别的 每次都要计算
由于是tcp方式 和RTSP RTP RTCP 共用一个端口 后面 解析数据包即可
不管是rtp包还是rtcp包 前面有一个四个字节的头
首字节固定0x24 后面一个字节channel 区分 音视频 rtp rtcp 一般偶数通道标识rtp包 奇数标识rtcp包 后面两个字节表示包长
0x24 channel datalen
但是实际测试中发现 部分rtsp server tcp方式发送的时候 rtcp包没有这四个字节 找0x24头的时候找不到 ffmpeg会将错误原因设置为End of file 如下图 80 C8 00 06 是RTCP的报文
在我自己的测试程序中 可以直接跳过这个包 直接继续接受数据处理 即可 发现也没问题 采用ffmpeg的话 就只能更改ffmpeg源码了 会比较麻烦
以上是作为客户端拉流的时候
2.RTSP作为客户端推流 这里 采用ffmpeg推流rtsp 默认UDP方式 server采用ZLMediakit 分析
客户端发送OPTIONS方法 服务端回复支持的方法 可以看到比一般的摄像头多了ANNOUNCE RECORD方法
客户端发送ANNOUNCE方法
客户端发送SETUP方法
客户端发送RECORD方法
