实时传输协议(RTP)和实时控制协议(RTCP)

 

RTP是一种提供端对端传输服务的实时传输协议,用来支持在单目标广播和多目标广播网络服务中传输实时数据,而实时数据的传输则由RTCP协议来监视和控制。

RTP定义在RFC

使用RTP协议的应用程序运行在RTP之上,而执行RTP的程序运行在UDP的上层,目的是为了使用UDP的端口号和检查和。如图16-12所示,RTP可以看成是传输层的子层。由多媒体应用程序生成的声音和电视数据块被封装在RTP信息包中,每个RTP信息包被封装在UDP消息段中,然后再封装在IP数据包中。

1889 中。信息包的结构包含广泛用于多媒体的若干个域,包括声音点播(audio-on-demand)、影视点播(video on demand)、因特网电话(Internet telephony)和电视会议(videoconferencing)。RTP的规格没有对声音和电视的压缩格式制定标准,它可以被用来传输普通格式的文件。例如,WAV或者GSM(Global System for Mobile communications)格式的声音、MPEG-1和MPEG-2的电视,也可以用来传输专有格式存储的声音和电视文件。

 

TCP/IP模型

 

应用层(application)

传输层

RTP

 

UDP

 

IP

 

数据链路层(data link)

 

物理层(physical)

图16-12 RTP是传输层上的协议

从应用开发人员的角度来看,可把RTP执行程序看成是应用程序的一部分,因为开发人员必需把RTP集成到应用程序中。在发送端,开发人员必需把执行RTP协议的程序写入到创建RTP信息包的应用程序中,然后应用程序把RTP信息包发送到UDP的套接接口(socket interface),如图16-13所示;同样,在接收端,RTP信息包通过UDP套接接口输入到应用程序,因此开发人员必需把执行RTP协议的程序写入到从RTP信息包中抽出媒体数据的应用程序。

TCP/IP模型

 

应用层(application)

 

RTP

 


套接接口

UDP

 

IP

 

数据链路层(data link)

 

物理层(physical)

 

图16-13 RTP和UDP之间的接口

现以用RTP传输声音为例来说明它的工作过程。假设音源的声音是64 kb/s的PCM编码声音,并假设应用程序取20毫秒的编码数据为一个数据块(chunk),即在一个数据块中有160个字节的声音数据。应用程序需要为这块声音数据添加RTP标题生成RTP信息包,这个标题包括声音数据的类型、顺序号和时间戳。然后RTP信息包被送到UDP套接接口,在那里再被封装在UDP信息包中。在接收端,应用程序从套接接口处接收RTP信息包,并从RTP信息包中抽出声音数据块,然后使用RTP信息包的标题域中的信息正确地译码和播放声音。

如果应用程序不使用专有的方案来提供有效载荷类型(payload type)、顺序号或者时间戳,而是使用标准的RTP协议,应用程序就更容易与其他的网络应用程序配合运行,这是大家都希望的事情。例如,如果有两个不同的公司都在开发因特网电话软件,他们都把RTP合并到他们的产品中,这样就有希望:使用不同公司电话软件的用户之间能够进行通信。

这里需要强调的是,RTP本身不提供任何机制来确保把数据及时递送到接收端或者确保其他的服务质量,它也不担保在递送过程中不丢失信息包或者防止信息包的次序不被打乱。的确,RTP的封装只是在系统端才能看到,中间的路由器并不区分那个IP数据报是运载RTP信息包的。

RTP允许给每个媒体源分配一个单独的RTP信息包流,例如,摄像机或者麦克风。例如,有两个团体参与的电视会议,这就可能打开4个信息包流:两台摄像机传送电视流和两个麦克风传送声音流。然而,许多流行的编码技术,包括MPEG-1和MPEG-2在编码过程中都把声音和电视图像捆绑在一起以形成单一的数据流,一个方向就生成一个RTP信息包流。

RTP信息包没有被限制只可应用于单目标广播,它们也可以在一对多(one-to-many)的多目标广播树或者在多对多(many-to-many)的多目标广播树上传送。例如,多对多的多目标广播,在这种应用场合下,所有发送端通常都把他们的RTP信息包流发送到具有相同多目标广播地址的多目标广播树上。

16.6.2 RTP信息包标题域

RTP标题由4个信息包标题域和其他域组成:有效载荷类型(payload type)域,顺序号(sequence number)域,时间戳(timestamp)域和同步源标识符(Synchronization Source Identifier)域等。RTP信息包的标题域的结构如下图所示:

Payload

Type
(有效载荷类型)

Sequence Number

(顺序号)

Timestamp

(时间戳)

Synchronization Source Identifier
(同步源标识符)

Miscellaneous Fields
(其他)

 

1. 有效载荷类型

RTP信息包中的有效载荷域(Payload Type Field)的长度为7位,因此RTP可支持128种不同的有效载荷类型。对于声音流,这个域用来指示声音使用的编码类型,例如PCM、自适应增量调制或线性预测编码等等。如果发送端在会话或者广播的中途决定改变编码方法,发送端可通过这个域来通知接收端。表16-01列出了目前RTP所能支持的声音有效载荷类型。

表16-01 目前RTP所能支持的声音有效载荷类型

有效载荷号

声音类型

采样率(kHz)

数据率(kb/s)

0

PCM mu-law

8

64

1

1016

8

4.8

2

G.721

8

32

3

GSM

8

32

6

DVI

16

64

7

LPC

8

2.4

9

G.722

8

48~64

14

MPEG Audio

90

-

15

G.728

8

16

对电视流,有效载荷类型可以用来指示电视编码的类型,例如motion JPEG, MPEG-1,MPEG-2或者H.231等等。发送端也可以在会话或者期间随时改变电视的编码方法。表16-02列出了目前RTP所能支持的某些电视有效载荷类型。

表16-02 目前RTP所能支持的声音有效载荷类型

有效载荷号

电视格式

26

Motion JPEG

28

-

31

H.261

32

MPEG-1 video

33

MPEG-2 video

 

2. 顺序号

顺序号(Sequence Number Field)域的长度为16位。每发送一个RTP信息包顺序号就加1,接收端可以用它来检查信息包是否有丢失以及按顺序号处理信息包。例如,接收端的应用程序接收到一个RTP信息包流,这个RTP信息包在顺序号86和89之间有一个间隔,接收端就知道信息包87和88已经丢失,并且采取措施来处理丢失的数据。

3. 时间戳

时间戳(Timestamp)域的长度为32字节。它反映RTP数据信息包中第一个字节的采样时刻(时间)。接收端可以利用这个时间戳来去除由网络引起的信息包的抖动,并且在接收端为播放提供同步功能。

4. 同步源标识符

同步源标识符(Synchronization Source Identifier,SSRC)域的长度为32位。它用来标识RTP信息包流的起源,在RTP会话或者期间的每个信息包流都有一个清楚的SSRC。SSRC不是发送端的IP地址,而是在新的信息包流开始时源端随机分配的一个号码。

16.6.3 实时传输控制协议

实时传输控制协议(Real-time Control Protocol,RTCP)也定义在1996年提出的RFC 1889中。多媒体网络应用把RTCP和RTP一起使用,尤其是在多目标广播中更具吸引力。当从一个或者多个发送端向多个接收端广播声音或者电视时,也就是在RTP会话期间,每个参与者周期性地向所有其他参与者发送RTCP控制信息包,如图16-14所示。RTCP用来监视服务质量和传送有关与会者的信息。对于RTP会话或者广播,通常使用单个多目标广播地址,属于这个会话的所有RTP和RTCP信息包都使用这个多目标广播地址,通过使用不同的端口号可把RTP信息包和RTCP信息包区分开来。

RTCP的主要功能是为应用程序提供会话质量或者广播性能质量的信息。每个RTCP信息包不封装声音数据或者电视数据,而是封装发送端和/或者接收端的统计报表。这些信息包括发送的信息包数目、丢失的信息包数目和信息包的抖动等情况,这些反馈信息对发送端、接收端或者网络管理员都是很有用的。RTCP规格没有指定应用程序应该使用这个反馈信息做什么,这完全取决于应用程序开发人员。例如,发送端可以根据反馈信息来修改传输速率,接收端可以根据反馈信息判断问题是本地的、区域性的还是全球性的,网络管理员也可以使用RTCP信息包中的信息来评估网络用于多目标广播的性能。

16.6.4 实时流放协议

实时流放协议(Real-Time Streaming Protocol,RTSP)是一个刚开始开发的协议,它的设想描述在RFC

播放的数据流被分成许多信息包,信息包的大小很适用于客户机和服务器之间的带宽。当客户机已经接收到足够多的信息包之后,用户软件就可开始播放一个信息包,同时对另一个信息包解压缩和接收第三个信息包。这样用户就不需要把整个媒体文件从服务器上下载之后就可立即播放。广播源可以是现场的数据流也可以是存储的数据流。

RTSP协议想要提供控制多种应用数据传送的功能,提供一种选择传送通道的方法,例如UDP, TCP, IP多目标广播通道,以及提供一种基于RTP协议的递送方法。正在设计的RTSP将工作在RTP的上层,用来控制和传送实时的内容。

RTSP能够与资源保留协议一起使用,用来设置和管理保留带宽的流式会话或者广播。

 

2326文件中。RTSP是应用级的实时流放协议,它主要目标是为单目标广播和多目标广播上的流式多媒体应用提供牢靠的播放性能,以及支持不同厂家提供的客户机和服务机之间的协同工作能力。
  • 0
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: 基于Linux和Qt的实时视频传输客户端和服务端应用程序是利用RTP(Real-time Transport Protocol,实时传输协议)来实现实时视频传输的。RTP是一种面向实时多媒体数据的传输协议,常用于音频和视频的传输。 在客户端和服务端的设计中,使用Qt作为界面开发工具和库,通过其提供的多媒体功能来处理和显示视频数据。客户端负责发送视频数据流,服务端负责接收并显示视频。以下是简要的实现步骤: 1. 客户端: - 使用Qt提供的音频和视频模块,打开摄像头和麦克风,获取音视频数据。 - 封装音视频数据为RTP数据包,包括相应的RTP头部和负载数据。 - 通过网络传输RTP数据包到服务端。 2. 服务端: - 使用Qt提供的音频和视频模块,接收网络数据包。 - 解析RTP数据包,获取音视频数据。 - 对音视频数据进行解码,得到原始的音视频帧。 - 将音视频帧显示在界面上。 需要注意的是,RTP协议本身并不提供数据传输的可靠性、安全性或容错功能。在实际应用中,可以结合其他协议(如RTCP或SRTP)来增加传输的可靠性和安全性。 此外,还需要考虑网络传输的带宽、延迟等因素,采用合适的编码格式和传输策略,以确保视频传输的实时性和流畅性。 总结来说,基于Linux和Qt的实时视频传输客户端和服务端利用RTP协议实现音视频数据的传输和显示,通过Qt的音视频模块处理数据并提供界面显示功能。但具体实现涉及到网络传输、编解码等复杂的技术,需要进一步深入学习和实践。 ### 回答2: 在Linux操作系统下使用Qt开发基于RTP协议实时视频传输客户端和服务端,可以通过以下步骤实现。 服务端: 1. 创建一个Qt项目,并引入RTP库,如live555,以便实现RTP协议的功能。 2. 使用QTcpServer类创建一个TCP服务器,用于接收客户端的连接请求。 3. 在接收到客户端连接请求后,创建一个RTP会话,并将客户端的地址信息绑定到会话上。 4. 使用RTP会话发送视频数据,可以将视频数据分片成RTP包进行传输,并将其发送到客户端。 客户端: 1. 创建一个Qt项目,并引入RTP库,如live555,以便实现RTP协议的功能。 2. 使用QTcpSocket类创建一个TCP套接字,用于向服务端发送连接请求。 3. 在连接成功后,创建一个RTP会话,并将服务端的地址信息绑定到会话上。 4. 使用RTP会话接收服务端发送的视频数据,并在界面上进行显示。 在实现过程中,需要注意以下几点: 1. RTP协议可以自定义载荷类型,可根据需求选择合适的载荷类型进行视频传输。 2. 考虑网络传输的延迟和带宽限制,可以通过设置RTP会话的一些参数,如时间戳,序列号等,来优化传输效果。 3. 在服务端和客户端中,需要进行视频数据的编码和解码操作,以便进行数据的传输和显示。 总结而言,如果想要在Linux Qt下实现基于RTP协议实时视频传输客户端和服务端,需要借助RTP库,创建RTP会话,并使用TCP套接字进行连接。同时,需要进行视频数据的编码和解码操作,以实现视频的传输和显示。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值