一个RtspServer的设计与实现和RTSP2.0简介

一个RtspServer的设计与实现和RTSP2.0简介

  前段时间着手实现了一个RTSP Server，可以正常实现多路RTSP流的直播播放，因项目须要，只作了对H.264和AAC编码的支持，可是相信其余编码的实现基本逻辑也是想通的。这里我把主要设计和思考过程，以及实现框架分享一下。由于关注的是直播，这里只讨论RTSP直播协议。

RTSP协议概述与RTSP2.0

  众所周知，RTSP协议是一个流媒体协议，能够实现直播和点播形式的音频与视频流的播放。RTSP协议定义了多种服务器-客户端之间交互的接口，主要有OPTIONS，DESCRIBE，SETUP，PLAY，TEARDOWN，RECORD，ANNOUNCE。网络上已经有不少针对RTSP协议的文章，我这里不许备进行过多介绍，详细的协议定义，能够参见RFC2326。RTSP并不包括具体数据的传输，该功能通常由RTP与RTCP协议来实现，并能够经过TCP或UDP两种底层传输方式进行。

  下图是典型的RTSP直播过程当中服务端-客户端主要交互过程：



  固然，直播过程当中也可能在服务器与客户端之间调用GET_PARAMETER等其余接口，上图偷懒省略了。上图绿色部分表示的是数据传输。以前说过，流媒体数据传输不是RTSP协议的内容，由RTP包来作。可是具体在实现上，RTP包能够经过UDP或TCP的方式来进行，并且这两种传输方式，区别其实还不小，下面具体说下。

RTSP 数据传输流程

1. RTSP over UDP

  对于udp模式，客户端在发送PLAY之后，就开始创建udp端口，以接收服务器发来的RTP包，一样，服务器也会创建udp端口，并向客户端发送RTP包。这是网上大部分程序所采用的方式，优势是逻辑清晰，实现方便，不过缺点也很明显，就是udp所固有的，容易丢包，尤为是在高分辨率高码率下。

  

2. RTSP over TCP

  对tcp模式，经过SETUP接口来指定传输方式，服务器返回一样数据以肯定双方经过tcp方式来传输数据。不过跟udp最大的不一样是，rtsp over tcp的形式，再也不建立单独的tcp通道，而是直接使用以前rtsp通讯所使用的tcp通道，流程以下所示：

  

  因为跟rtsp消息使用同一个tcp端口，为了区分，rtp以及rtcp包，增长了4个字节额外的字段，并经过特殊的标识'$'，与正常的rtsp消息进行了区分。

RTSP Live Server 设计与实现

1. 程序框架

  我此次所实现的RTSP Server，主要功能是采集摄像头和麦克风数据，进行h.264编码以及aac编码，并对外提供RTSP直播流服务。我在实际写代码中，也是首先实现了rtsp over udp的模式，然而，经过实际测试，我发如今高分辨率高码率状况下，因为h.264 NAL单元过大，会拆分红不少的rtp包，而udp不可靠的传输方式，老是不免丢包，在低码率的时候还不明显，高码率状况下，丢包致使的花屏会频繁出现，这样体验特别差。因而我从新实现了一份rtsp over tcp模式的代码，顺利解决了这个问题。

  

2. 关于h264在sdp中的描述

  h264在sdp中的媒体信息,大多都是能够直接填写的，可是有两项数据须要根据编码后的数据来提取，就是profile-level-id和sprop-parameter-sets。这两项字符串数据的计算公式

• profile-level-id = "Base16(sps[1])" + "Base16(sps[2])" + "Base16(sps[3])"
• sprop-parameter-sets = "Base64(sps)" + "," + "Base64(pps)"

3. 主要代码

3.1 Rtsp服务接口



3.2 RtspSession在TCP通道里处理RTSP消息与RTP报文

4. 运行效果

  同时用vlc和ffplay进行多路播放，以tcp请求的方式，效果以下，延迟极低。

关于RTSP 2.0

  2016年IETF发布了新的RTSP标准，这就是就是RTSP2.0协议（RFC7826），新标准仍是有很多修改的，除了完善一些原协议的中的定义，还有一些我以为比较重要的是，对接口method进行了修改，好比删除了RECORD和ANNOUNCE方法，新增了PLAY_NOTIFY方法。

• 删除了RECORD，这表示你不能再经过这个接口来控制服务器进行数据的录制了，能够选择在PLAY方法中，添加一些参数，来实现服务器对直播数据进行录制，还能够分隔录制。
• 删除了ANNOUNCE，这意味着，不能像RTMP同样，客户端经过向服务器推送数据，来实现本机数据对外直播了，这可能须要其余的推送途径来进行替代了。
• 至于PLAY_NOTIFY，它替代来原来Server向Client端发送ANNOUNCE方法，所实现的功能，也就是告诉客户端，须要根据新参数来调整直播播放状态。
• 删除经过UDP传输RTSP消息的形式
• 删除经过发PLAY消息来keep alive的方式（用SET_PARAMETER来作）
• RTSP Server也可向Client发TEARDOWN消息
• 支持IPV6
• RTSP请求，支持pipelining的形式，也就是聚合Request。好比能够不等服务器返回，把SETUP和PLAY一块儿发送，这样能够提升至少一个RTT的启动时间。固然须要在消息里加上相关字段。
• 重写了状态机，完善了服务器对客户端来讲在各个状态之间的转换和行为
• RTSP消息内支持URI了
• 扩展了REDIRECT方法，等，等等。

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

haibindev.cnblogs.com，合做请联系QQ。（转载请注明做者和出处~）

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++