Working with Real-Time Media Streams(翻译自ＪＭＦ)

用实时的媒体流工作

 

通过Internet或Intranet发送或接收一个生活的媒体广播或管理一段视频会议，你需要能够实时的接收并传输媒体流。这一章介绍了流媒体的概念，并且描述了实时传输协议ＪＭＦ，用于接收和传输网络媒体流。

 

流媒体

 

当媒体内容被即时的流化到一个客户端时，客户端可以开始播放流，而不用等待数据下载完毕。事实上，这个流甚至可能没有一个确切的时间周期―――在播放之前下载整个流将是不可能的。这个期间里，流媒体常常被用于实时的通过网络传递内容的技术和实时显示所发送的媒体内容。

 

流媒体在网络是到处存在的-------生活广播，电视，网络广播和事件都正在被提出，他们通过快速增长的大量网络入口，并且现在可以通过因特网操作音频和视频会议。通过实现动态传递，在网络中交互媒体内容，流媒体正在改变着人们交流和访问信息的方式。

 

流媒体协议

 

通过网络实时的传输媒体数据需要高吞吐量。补偿丢失的数据要比补偿长时间的数据接收延迟更容易。访问静态数据是很困难的，比如一个文件，最重要的事情就是所有的数据都能到达它的目的地。因此，协议用于静态数据作为流媒体是不能很好的进行处理的。

 

HTTP和FTP协议是基于传输控制协议(TCP)的。TCP是传输层协议-------设计用于窄带，高出错率网络的可靠数据通信。当一个包丢失或出错，它是转发的。关键是保证可靠数据传输会降低整体传输速度。

 

因为这个原因，不同于TCP的底层协议更有代表性的用于流媒体。一个普遍的被用到的是用户独立寻址协议（UDP）。UDP是一个未实现的协议;它不能保证每个包都会到达目的地。也不保证发送的包会有序的到达。接收端能够补偿丢失的数据，包的副本，和无序到达的包。

 

像TCP, UDP是一个普通的传输层协议----一个低级网络协议，它在更多的被构建的特殊应用程序协议之上。为传输实时数据的因特网标准，比如音频和视频是实时传输协议(RTP)。

 

RTP被定义在IETF RFC 1889中，一个工作在因特网引擎任务组(IETF)的ＡＶＴ产品。

 

实时传输协议

 

RTP为实时数据的传输提供首尾相连（end-to-en）的网络传递服务。RTP是独立的网络和传输协议，虽然它常常被用UDP之上。

 

Figure 7-1: RTP architecture.

 

RTP可被用于包括unicast和多点传送(multicast)的网络服务。在一个unicast网络服务之上，把数据的备份分开来从数据源发送到每个目的地。在一个多点传送的网络服务上，数据仅被从数据源发送一次，并且对于传输数据到多个位置是可靠的。多点传送对于许多多媒体应用程序来说更有效，比如视频会议。标准IP支持多点传送。

RTP服务

RTP能够让你识别正在传输的数据的类型，确定要播放的数据包的顺序，并且从不同的源同步媒体流。

RTP数据包不能保证到达他们被发送的顺序------事实上，他们根本不能保证到达。接收端能够胜任去重建发送端的包序列，并且用包头提供的信息检测丢失的包。

当RTP不能提供任何机置以确保及时传输或提供其他服务保证的质量，它是通过一个控制协议扩展的，使你能够监听数据发布的质量。RTCP也为RTP传输提供控制和鉴定机置。

如果服务的质量是一个特殊的应用程序的根本，RTP能被用于在一个资源上保留协议，以提供导向连接的服务。

RTP体系结构

一个RTP  session　是一组用RTP通信的应用程序的联合之一。一个session被看成是通过一个网络地址和一对端口。一个端口被用于媒体数据，并且其它的被用于控制(RTCP)数据。

一个participant 是一个单独的结构、主机、或用户在session中共同参与的。参与进一个session中能够组成被动的数据的接收(receiver)，主动的数据的传输(sender)，或者全部。

每种媒体类型不同的session中传输。例如，如果音频和视频都被用于一个会议中，一个session被用于传输音频数据，并且另一个单独的session被用于传输视频数据。这可以使参与者选择他们想接收的媒体类型---例如，用窄带的连接的人可能只想接收会议的音频部分。

数据包

一个session的媒体数据作为一系列的包被传输。一系列的包的源头是一个特殊的被作为RTP流的数据源。每个在流里的RTP数据包都包含两部分，一个构成包头，一个是实际的数据（包的有效载荷）。

Figure 7-2: RTP data-packet header format.

一个RTP数据包的包头包括：

l  The RTP version number(V):２字节。这个version通过当前的规范是２来定义。

l  Padding(P)：１字节。如果padding字节被设定，包的尾部就有一个或多个字节不属于有效载荷。包内的最后的字节指出了有效载荷的字节数。这个补充部分被用于一些密码运算。

l  Extension(X)：１字节。如果extension字节被设定，固定的包头就多了一个头扩充。这个扩充机置能够实现添加信息到RTP的包头。

l  CSRC Count(CC):４字节。CSRC 标识符跟在固定包头后。如果CSRC是零，同步源就是有效载荷的源。

l  Marker(M)：１字节。一个marker字节通过特别的媒体剪辑来定义。

l  Payload Type(PT):７字节。一个媒体剪辑索引表描述了有效载荷的格式。在RFC　1890 中，音频和视频的有效载荷的映射是指定的。

l  Sequence Number：１６字节。一个唯一的包的号码确定了这个包在序列包中的位置。包的号码通过每个发送的包来增加。

l  Timestamp:32字节。反射出有效载荷中的第一个字节的取样。一些连续的包能够有同样的邮戳，如果他们在逻辑上是同一时间发生的---例如，如果他们都是同一视频帧的一部分。

l  SSRC:32字节。定义同步源。如果CSRC字数是零，有效载荷源就是同步源。如果CSRC不是零，SSRC被看成是混合的。

l  CSRC:每个32字节。确定有效载荷的有效源。有效源的数量通过CSRC字数域被指定;他们能胜任16个字节的有效源。如果有多个有效源，有效载荷就是从这些源中的混和数据。

控制包

除一个session的媒体数据外，控制数据(RTCP)包被定时发送给session中的所有参与者。RTCP包能够包含为session参与者服务的参数的信息，在数据端口上正在被传输的媒体源的信息，统计附加到已被传输的数据等。

RTCP包的一些类型：

l  发送报告

l  接收报告

l  源描述

l  附加

l  特殊的应用程序

RTCP包是”stackable”，并且被当作一个命令包发送，至少包含两个包，一个报告包和一个源描述包。

Session中的所有的参与者发送RTCP包。一个最近发送数据包的参与者发布一个sender report。这个sender report(SR)包含包的全部数字，和从不同的sessions中被用于同步媒体流的信息一样的字节。

所有在session中的参与者都发送RTCP包。一个最近发送数据包的参与者发布一个sender report。这个sender report(SR)包含包的总数，也包括发送的不同的sessions中被用于同步媒体流的信息字节。

对所有接收包的数据源，Session参与者周期性的发布receiver reports。一个receiver report (RR)包括关于丢失包的数量，接收到的最大序列，和一个可以被用于估算数据在发送端和接收端来回经过所用时间的邮戳。

第一个在复合RTCP包中的包一定是report包，甚至如果没有数据被发送或接收---在这种情况下，将发送一个空的接收report。

所有的复合RTCP包必需包含一个源描述（SDES）元素，这个元素包括定义这个源的规范的名字。可能包含附加的信息，比如源的名字，邮箱地址，电话号码，地理位置，程序名字，或者一个描述源的当前状态的消息。

当一个源不再活动时，它发送一个RTCP BYE包。这个BYE通知能够包含源被离开session的原因。

RTCP APP包提供一个机置，为应用程序定义和发送经由RTP控制端口的客户信息。

RTP应用程序

RTP应用程序常常被分隔开，一些需要能够从网络接收数据(RTP客户端)，一些需要能够从网络传输数据（RTP服务器端）。一些应用程序负责全部----例如，会议应用程序摄像，并且在同一时间传输从网络接收到的数据。

从网络中接收媒体流

对一些类型的应用程序来说，能够接收RTP流是必要的。例如：

l  会议应用程序需要能够从一个RTP session中接收一个流媒体，然后在控制台中展现出来。

l  一个电话应答机置的应用程序需要能够从RTP session中接收一个流媒体，然后存储到文件中。

l  一个记录谈话或会议的应用程序必须能够从RTP session中接收一个流媒体，然后把它们在控制台上全部展现出来，并存储进文件中。

 

在网络中传输媒体

RTP服务器应用程序在网络中传输拍摄或存储的媒体。

例如，在一个会议应用程序中，可能用摄像机拍摄一断媒体流，然后发送一个或多个RTP session。媒体流可能被编码进多媒体格式中，然后为会议在几个RTP session上用不同种类的接收器发送。通过使用多unicast RTP sessions可以实现没有IP的多个会议。