RTSP作为客户端 推流 拉流的过程分析

之前写过一个 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方法