Open xizhibei opened 3 years ago
当我们谈到 RTSP 的时候,其实不仅仅是 RTSP 协议本身,我们其实不可避免会谈到以下几个协议:
这里相信你也能看出一些内容了,比如其实 RTSP 协议本身不负责播放,只负责交互控制,RTP 以及 RTCP 才是真正的视频传输。
下面我们将其中的详细内容展开来说说,并且会用实际的例子来说明。
在 Web 开发的时候,我们经常会使用到各种 HTTP 抓包工具,但是,作为一个有追求的工程师,你应该学会使用 WireShark,这是一款强大免费的网络抓包分析工具,它可以让我们看清楚,我们每天在使用的协议究竟是什么样的。
打开 WireShark (安装的过程就略过了,相信你可以自己搞定的),选择你电脑正在使用的网络端口,比如 Linux 可能是 eth0,Mac 是 en0 ,双击就能进入抓包。
接着在 WireShark 的筛选栏里,填入 rtsp || rtcp || rtp 这样,我们就能够把一些无关的协议过滤掉。
rtsp || rtcp || rtp
在继续之前,你还需要准备的是,一个 RTSP 服务器,我这里准备的是一个网络摄像头,另外就是本地的 RTSP 播放器,比如我就是用 VLC 来播放的。如果你身边暂时没有可用的,也可以临时造一个,可以看看 rtsp-simple-server 里面介绍的。
当然,还有客户端,我们可以直接用各种播放器(如 VLC)来播放 RTSP 视频源,或者你可以使用命令行, 比如 FFMpeg 的 ffplay:
ffplay rtsp://192.168.1.100/live
如果你跟我一样使用 VLC:点击打开媒体 -> 网络,然后在 URL 中填入视频源,点击打开就开始播放了,过几秒钟后点击停止播放。
下面两张图就是我用 VLC 播放以及停止之间发生的网络通信抓包,其中 192.168.2.31 是网络摄像头,而 192.168.2.115 则是我的电脑,即播放器所在的电脑。
需要注意到的部分:
接下来,让我们通过实际抓包的内容来作具体说明。
首先,客户端会发送一个与 HTTP 协议很类似的 RTSP 协议到 192.168.1.100 的 554 端口,是一个 OPTIONS 请求,即列出这个播放源可用的请求,注意 CSeq,每个 RTSP 请求都会带上,这样,服务端的回应就会跟客户端一一对应起来(这不就是 HTTP)。
然后服务器就会回应:
如上,服务器告诉客户端,可以使用 DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE 等几个请求。
现在,客户端发送 DESCRIBE 请求:
服务器会用 SDP 格式的内容回应:
WireShark 的一个非常友好的部分在于,它会把协议的说明描述显示出来,SDP 看不懂?它会很清楚地告诉你,另外,SDP 详细的协议解释清看 维基上的说明 。
这里注意下 rtpmap:96 H264/90000 这一行,这里表示这个视频源是用 H264 编码,采样频率是 90000 。
rtpmap:96 H264/90000
如上,服务器会展示出,这个视频源的实际视频内容是 MP4 格式的,视频在 0 通道,音频在 1 通道。
现在,我们到了 SETUP 步骤,相当于初始化(如果播放源既有音频又有视频,那么需要 SETUP 两次):
这里解释下 Transport 的内容:
记下来就是服务端回应:
这里需要注意下 Session,这是接下来的播放控制请求都会带上的,用来区别不同的播放请求。
接下来就是正式的请求了:
其中的 Range 表示播放时间的范围,而上图的 npt=0.000- 表示这是一个实时的视频源。
npt=0.000-
服务端会回应一个带有 RTP-Info 的头,其中的 seq 以及 rtptime 的信息都用来指示 RTP 包的信息。
如果你注意下上面的总览,你会发现服务端在接收到 PLAY 请求的同时,就开啊是发送 RTP 以及 RTCP 数据进行真正的播放了。
即停止播放请求,这里很简单,就不详述了。
相比于 RTSP 的 文本协议,RTCP 属于二进制协议,它的协议头如下2:
拿出实际例子,我们会发现服务端接受到 PLAY 请求后,紧接着就发送了一个 RTCP Sender Report:
从中需要注意的一点在于,它有两个时间戳,一个是 NTP (Network Time Protocol) 时间戳,用 8 个字节来表示的绝对时间,另一个则是 RTP 时间戳,这是相对时间,可以用来计算 RTP 包的时间,具体的计算规则是用两个 RTP 时间戳的差值除以视频采样频率,再加上这里的绝对时间,就是当前 RTP 包的绝对时间了。(不知道采样频率?回头去看看上面 RTSP 的 DESCRIBE 请求的回复。)
RTP 也属于二进制协议,它的协议头如下1:
我们选取第一个 RTP 包来看,我们可以看到,内容类型是 96,也就是 H264。
RTSP 协议本身不复杂,下一篇我们来说说关于 RTSP 的实践。
当我们谈到 RTSP 的时候,其实不仅仅是 RTSP 协议本身,我们其实不可避免会谈到以下几个协议:
这里相信你也能看出一些内容了,比如其实 RTSP 协议本身不负责播放,只负责交互控制,RTP 以及 RTCP 才是真正的视频传输。
下面我们将其中的详细内容展开来说说,并且会用实际的例子来说明。
几个协议的详细介绍
在 Web 开发的时候,我们经常会使用到各种 HTTP 抓包工具,但是,作为一个有追求的工程师,你应该学会使用 WireShark,这是一款强大免费的网络抓包分析工具,它可以让我们看清楚,我们每天在使用的协议究竟是什么样的。
打开 WireShark (安装的过程就略过了,相信你可以自己搞定的),选择你电脑正在使用的网络端口,比如 Linux 可能是 eth0,Mac 是 en0 ,双击就能进入抓包。
接着在 WireShark 的筛选栏里,填入
rtsp || rtcp || rtp
这样,我们就能够把一些无关的协议过滤掉。在继续之前,你还需要准备的是,一个 RTSP 服务器,我这里准备的是一个网络摄像头,另外就是本地的 RTSP 播放器,比如我就是用 VLC 来播放的。如果你身边暂时没有可用的,也可以临时造一个,可以看看 rtsp-simple-server 里面介绍的。
当然,还有客户端,我们可以直接用各种播放器(如 VLC)来播放 RTSP 视频源,或者你可以使用命令行, 比如 FFMpeg 的 ffplay:
如果你跟我一样使用 VLC:点击打开媒体 -> 网络,然后在 URL 中填入视频源,点击打开就开始播放了,过几秒钟后点击停止播放。
整体通信过程总览
下面两张图就是我用 VLC 播放以及停止之间发生的网络通信抓包,其中 192.168.2.31 是网络摄像头,而 192.168.2.115 则是我的电脑,即播放器所在的电脑。
需要注意到的部分:
RTSP 协议
接下来,让我们通过实际抓包的内容来作具体说明。
OPTIONS 请求
首先,客户端会发送一个与 HTTP 协议很类似的 RTSP 协议到 192.168.1.100 的 554 端口,是一个 OPTIONS 请求,即列出这个播放源可用的请求,注意 CSeq,每个 RTSP 请求都会带上,这样,服务端的回应就会跟客户端一一对应起来(这不就是 HTTP)。
然后服务器就会回应:
如上,服务器告诉客户端,可以使用 DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE 等几个请求。
DESCRIBE 请求
现在,客户端发送 DESCRIBE 请求:
服务器会用 SDP 格式的内容回应:
WireShark 的一个非常友好的部分在于,它会把协议的说明描述显示出来,SDP 看不懂?它会很清楚地告诉你,另外,SDP 详细的协议解释清看 维基上的说明 。
这里注意下
rtpmap:96 H264/90000
这一行,这里表示这个视频源是用 H264 编码,采样频率是 90000 。如上,服务器会展示出,这个视频源的实际视频内容是 MP4 格式的,视频在 0 通道,音频在 1 通道。
SETUP 请求
现在,我们到了 SETUP 步骤,相当于初始化(如果播放源既有音频又有视频,那么需要 SETUP 两次):
这里解释下 Transport 的内容:
记下来就是服务端回应:
这里需要注意下 Session,这是接下来的播放控制请求都会带上的,用来区别不同的播放请求。
PLAY 请求
接下来就是正式的请求了:
其中的 Range 表示播放时间的范围,而上图的
npt=0.000-
表示这是一个实时的视频源。服务端会回应一个带有 RTP-Info 的头,其中的 seq 以及 rtptime 的信息都用来指示 RTP 包的信息。
如果你注意下上面的总览,你会发现服务端在接收到 PLAY 请求的同时,就开啊是发送 RTP 以及 RTCP 数据进行真正的播放了。
TEARDOWN 请求
即停止播放请求,这里很简单,就不详述了。
RTCP 协议
相比于 RTSP 的 文本协议,RTCP 属于二进制协议,它的协议头如下2:
拿出实际例子,我们会发现服务端接受到 PLAY 请求后,紧接着就发送了一个 RTCP Sender Report:
从中需要注意的一点在于,它有两个时间戳,一个是 NTP (Network Time Protocol) 时间戳,用 8 个字节来表示的绝对时间,另一个则是 RTP 时间戳,这是相对时间,可以用来计算 RTP 包的时间,具体的计算规则是用两个 RTP 时间戳的差值除以视频采样频率,再加上这里的绝对时间,就是当前 RTP 包的绝对时间了。(不知道采样频率?回头去看看上面 RTSP 的 DESCRIBE 请求的回复。)
RTP 协议
RTP 也属于二进制协议,它的协议头如下1:
我们选取第一个 RTP 包来看,我们可以看到,内容类型是 96,也就是 H264。
总结
RTSP 协议本身不复杂,下一篇我们来说说关于 RTSP 的实践。
Ref