网络编程魔法Live555@IT·互联网

Live555源码解析(2) - RTSP协议概述

2017-05-24  本文已影响481人  SniperPan

上一篇Live555源码解析(1) - Main 寻根问祖,留其筋骨将main()函数脉络做了整体分析,通常来讲本篇应从服务器的创建开始讲起,但如前文所述,Live555媒体服务器是基于RTSP协议实现,为了便于源码阅读, 在这里有必要先整体介绍下RTSP协议及相关协议内容。如读者已掌握RTSP内容,则可跳过本篇,继续下一篇Live555源码解析(3) - 服务开启,愿者上钩的阅读。

编写本篇前,尽可能详细地翻译了RTSP Sepc,如有兴趣,可同时阅读RTSP Spec中文版

1. RTSP简史

RTSP出现以前,最热的大概就是HTTP协议。想象一下,当你需要欣赏网络中的某一段视频,通过HTTP协议访问其URL、开始下载、下载完成后播放。对于早期的视频采集设备、网络带宽或是负责渲染的显示器而言,似乎多给予一点耐心、多重连几次断开的HTTP连接、甚至多校验几次下载后文件的完整性,体验上也还能过得去。毕竟那时候的分辨率、帧率、带宽限制了互联网途径传播媒体文件的大小,信息的分享只能通过各种硬盘、U盘、光盘以存储后文件的形式进行传输。

随着硬件设备技术的发展,采集设备分辨率在提升,显示器支持了更高的帧率,网络带宽也指数增长,这都为更好的观影体验提供了基础支持。随着网络资源的日益丰富,用户时间的稀缺性日益凸显,为了快速观看、判别视讯本身是否符合自身口味,在线实时观看成了一大述求。而传统的HTTP下载显然不能够匹配该需求,因此在寻求streaming的道路上,RTSP脱颖而出。

RTSP全称实时流协议(Real Time Streaming Protocol),它是一个网络控制协议,设计用于娱乐、会议系统中控制流媒体服务器。RTSP用于在希望通讯的两端建立并控制媒体会话(session),客户端通过发出VCR-style命令如play、record和pause等来实时控制媒体流。

RTSP处理流时会根据端点间可用带宽大小,将音视频等数据切割成小分组(packet)进行传输,使得客户端在播放一个分组的同时,可以解压缓存中第二个甚至下载第三个分组。通过缓存和多码率流技术,用户将不会感觉到数据间存在停顿。至于RTSP的特性,则主要体现在如下方面:

1.1 相关协议介绍

RTSP组合使用了可靠传输协议TCP(控制)和高效传输协议UDP(内容)来串流(streaming)内容给用户。它支持点播(Video-On-Demand)以及直播(Live Streaming)服务。

RTSP协议本身并不负责数据传输,通常(非必须)是通过RTP(Real-time Transport Protocol)配合RTCP(Real-time Control Protocol)完成数据流和控制命令(同步、QOS管理等)的传输。具体应用中,三者的关系如下图所示:

RTSP RTCP RTP

2. RTSP方法

RTSP中并没有连接的概念,而是通过会话(Session)进行管理。每个会话有对应的会话ID,会话中可能可能涉及一至多个流,会话生命周期中,客户端也可能切换连接(如TCP)来传递RTSP请求(request)。

method direction object requirement
DESCRIBE C->S P,S recommended
ANNOUNCE C->S, S->C P,S optional
GET_PARAMETER C->S, S->C P,S optional
OPTIONS C->S, S->C P,S required(S->C:optional)
PAUSE C->S P,S recommended
PLAY C->S P,S required
RECORD C->S P,S optional
REDIRECT S->C P,S optional
SETUP C->S S required
SET_PARAMETER C->S,S->C P,S optional
TEARDOWN C->S P,S required

P: 呈现(Presentation),S:流(Stream)

一个RTSP应用(如点播)生命周期内,通常会话(所有交互)过程如下图所示:

2.1 必选方法

对于上述交互中涉及的RTSP方法,说明如下:

2.2 可选方法

除了上一小节中提到的5种必选方法外,还有如下方法是可选的。

2.3 RTSP状态机

RTSP Status Machine

2.4 嵌入式二进制数据(Embedded (Interleaved) Binary Data)

某些防火墙设计或其他环境因素可能迫使服务器将RTSP方法交错进流数据中。该种交错操作应尽可能避免,因为它提高了客户端和服务器操作的复杂度,也增加了额外的开销。嵌入式二进制数据应当只在RTSP通过TCP传输时使用。

C->S    SETUP rtsp://example.com/media.mp4 RTSP/1.0
        CSeq: 3
        Transport: RTP/AVP/TCP;interleaved=0-1

S->C    RTSP/1.0 200 OK
        CSeq: 3
        Date: 05 Jun 1997 18:57:18 GMT
        Transport: RTP/AVP/TCP;interleaved=0-1
        Session: 12345678

C->S    PLAY rtsp://example.com/media.mp4 RTSP/1.0
        CSeq: 4
        Session: 12345678

S->C    RTSP/1.0 200 OK
        CSeq: 4
        Session: 12345678
        Date: 05 Jun 1997 18:59:15 GMT
        RTP-Info: url=rtsp://example.com/media.mp4;
        seq=232433;rtptime=972948234

S->C    $\000{2 byte length}{"length" bytes data, w/RTP header}
        $\000{2 byte length}{"length" bytes data, w/RTP header}
        $\001{2 byte length}{"length" bytes RTCP packet}

3. Live555 openRTSP

openRTSP a command-line RTSP client

openRTSP是用于打开、串流、接收以及可选地录制媒体流的命令行客户端,媒体流通过RTSP URL指定,URL前缀为"rtsp://"。

本系列只以MediaServer源码为分析对象,因此对openRTSP不做讨论。

4. 实践检验

4.1 RTSP测试源

由于Windows真机环境负责,进程较多,进行抓包分析时干扰项很多,因此测试时创建了虚拟机,在发行版Ubuntu上进行了搭建。 Live555MediaServer Ubuntu可以直接下载,下载后在相同目录下放置媒体文件进行测试即可。

4.2 Wireshark抓包分析

下面就对应Wireshark抓包以及前述会话过程进行验证。

服务器地址:192.168.63.130:8554
客户端地址:192.168.63.1 :9571

4.2.1 TCP 三路握手

没有太多好说的,TCP标准三路握手,确定了窗口大小(Win),MSS等选项。

4.2.2 OPTIONS

OPTIONS请求、回复,有如下几个注意点:

4.2.3 DESCRIBE


DESCRIBE请求、回复,没有夹杂ACK。回复中以SDP协议格式给出了会话ID及其他会话属性。注意最后一个字段Meida Attribute中表明了control:track1,该值将在下一步SETUP中使用到。

4.2.4 SETUP

服务器在回复SETUP请求后,注意客户端有连续发出4个RTP/RTCP请求给服务器。

4.2.5 PLAY

PLAY请求中使用聚合控制URL,针对呈现本身,可同时作用于其中的多个流。Range值为从0开始到结束。

紧跟其后的是MPEG TS协议包,实际上是RTP协议通过UDP在传递TS流信息。

4.2.6 GET_PARAMETER

4.2.7 PAUSE

PAUSE中未携带Range域,表示立即暂停。客户端在收到服务器回复后,进行了额外ACK。

4.2.8 TEARDOWN

客户端请求关闭会话,Receiver Report属于客户端发往服务器的RTCP控制命令。

4.2.9 TCP四路断开


为什么不是四条,因为该种情况下两端同时断开,只需要将ACK放入发出的FIN中即可,不需要单独发送一条消息。
上一篇下一篇

猜你喜欢

热点阅读