RTP

本文详细介绍了实时传送协议(RTP)的原理、工作方式及在流媒体系统中的应用。RTP是网络传输协议,常与UDP协议配合使用,用于端到端的多媒体流控制。它通过定义RTP报文和RTCP报文,实现了音频和视频数据的高效传输。文章进一步解释了RTP报文的组成部分及其在互联网上的标准数据包传递过程,以及如何在流媒体系统中利用RTP和RTCP协议实现媒体数据的稳定传输。

     实时传送协议(Real-time Transport Protocol或简写RTP,也可以写成RTTP)是一个网络传输协议,经常和UDP协议一起使用。是一种端到端多媒体流控制机制。在网络带宽充足的情况下,RTP具有一定的带宽调节能力来保证端到端多媒体流的同步,但如果带宽不足,它的调控能力受限。

RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。它一开始被设计为一个多播协议,但后来被用在很多单播应用中。

RTP定义RTP报文和RTCP报文,RTP报文用于传送音视频数据,它由RTP报头和RTP数据组成,RTP数据称为有效载荷payload,RTCP报文用于传输control信息

RTP和RTCP报文均为下层协议的数据单元。如果用UDP,RTP和RTCP报文将使用两个相邻的UDP端口,RTP使用低端口,RTCP使用高端口。

如果不采用UDP协议,RTP和RTCP可以合并到一个数据单元中一起传输,控制数据在先,媒体数据在后。

RTP协议常用于流媒体系统(配合RTCP协议或者RTSP协议)。因为RTP自身具有Time stamp所以在ffmpeg 中被用做一种formate.

 有一个RtpProfile的全局变量,该变量在rtp初始化的时候赋值,该变量中有一个PayloadType的数组,每个PayloadType对应一种媒体流,PayloadType中包含了媒体流的特性,包括名称,采样率,声音位数,静音格式,占用带宽等。

 media session是一个RtpSession对象,包含多种属性和方法。RtpScheduler中包含一个RtpSession的队列,用来支持多媒体流。

 

RTP报文由两个部分构成--RTP报头和RTP的负载:

PT: 有效载荷类型,占7位,用于说明RTP报文中有效载荷的类型,如GSM音频、JPEM图像等,在流媒体中大部分是用来区分音频流和视频流的,这样便于客户端进行解析。

序列号:占16位,用于标识发送者所发送的RTP报文的序列号,每发送一个报文,序列号增1。这个字段当下层的承载协议用UDP的时候,网络状况不好的时候可以用来检查丢包。同时出现网络抖动的情况可以用来对数据进行重新排序,在helix服务器中这个字段是从0开始的,同时音频包和视频包的sequence是分别记数的。

时戳(Timestamp):占32位,时戳反映了该RTP报文的第一个八位组的采样时刻。接收者使用时戳来计算延迟和延迟抖动,并进行同步控制。

    其主要用于在互联网上传递音频和视频的标准数据包。在当前三网融合中RTP可以用来承载TS流,进行电视媒体数据的传播。RTP可以用来传送像TS流这种自身已经具有formate的媒体流,同时也可以用来承载AVC,AAC等去除了fromate的媒体流,这时rtp协议可被看做为一种formate,这种形式最少常见于helix 流媒体服务器的rtp流。其控制流由RTSP协议来提供。

    从在420包中就可以更加清析的看出这个RTP流的情况。其PT即payload type为mpeg2 transport streams 也就是ts流,其SSRC为:0x65737D6c,其Seq号为15764,从中也可以看出对于一个RTP流其SEQ号可以开始于一个随机的数值,但是肯定是逐包递增的。下图为420包的展开图:

### Real-time Transport Protocol (RTP) Overview #### Purpose and Functionality The Real-time Transport Protocol (RTP) serves as the primary protocol for delivering audio and video over IP networks. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as interactive voice or video conferences. It offers several key features including payload type identification, sequence numbering, timestamping, and delivery monitoring[^1]. #### Data Transmission Mechanism In conjunction with RTSP servers which manage control operations like play, pause, and rewind, RTP handles actual media stream transmission typically via UDP due to its lower latency compared to TCP. This setup ensures efficient handling of time-sensitive multimedia content where timely delivery outweighs error-free transmission. #### Quality Control through RTCP To maintain quality during streaming sessions, RTP works alongside RTCP (RTP Control Protocol). When employing profiles like RTP/AVPF, additional feedback mechanisms become available; these include Negative Acknowledgements (NACK), Picture Loss Indication (PLI), Full Intra Request (FIR), among others. Such messages inform senders about reception status so they can promptly respond accordingly[^2]. For instance, reduced-size RTCP packets may also be utilized under specific conditions but are restricted from regular reporting duties depending on the profile being used[^3]. #### Session Description Integration An example scenario illustrating how RTP integrates into session descriptions involves specifying ports within SDP attributes. An entity might declare willingness to accept incoming streams directed at particular addresses while expecting associated control traffic on adjacent ports[^4]: ```plaintext m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 ``` This configuration directs media towards port `49170` whereas related RTCP reports would target `49171`. #### Synchronization Sources Identification For accurate synchronization across multiple streams originating from different sources yet partaking in unified presentations—such as layered coding schemes involving scalable bitrates—the concept of SSRC plays a crucial role. Depending upon whether Single Stream Rollover Timestamp (SRST), Multiple Streams Same Timestamp (MSST), Multi-Rate Single-Timestamp (MRST), or Multi-Rate Multiple Timestamp (MRMT) strategies apply, varying numbers of unique identifiers will represent individual components constituting composite transmissions[^5].
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值