流媒体传输规范和节目流控制

目前IPTV系统中采用的流传输技术规范主要有ISMA方式和MPEG-2TSoverIP方式。

       互联网流媒体联盟(InternetStreamingMediaAlliance,ISMA)是在200。年12月成立的标准化组织，其目标就是制定在互联网流媒体编码器、服务器和播放器之间信息传递的开放标准，其原则是最大程度地利用现有互联网国际标准。

       ISMA规范涵盖视音频编解码、文件格式、流传输机制和供参考的SDK。ISMA1.0版本规定了基于MPEG-4的视音频格式和流传输JSMA2.0版本在1.0版本基础上扩充了对H.264标准的支持。ISMA的基本流传输过程如图3-1所示。

图3-1 ISMA的基本流传输过程

      从图3-1可见,ISMA通过服务器/客户端的结构实现流数据的传输，在应用层釆用了RTSP控制协议，媒体数据釆用RTP封装后承载在TCP或UDP上，并通过RTP/RTCP协议进行传输质量的监测。ISMA协议栈如图3-2所示。

图3-2   ISMA的协议栈

      需要指出的是-ISMA协议栈中，媒体数据需要经过流化处理,MPEG-4格式遵循MP4文件格式规范(即ISO/IEC14496-14：MP4 file format),H.264格式遵循高级视频编码文件格式规范(即ISO/IEC14496-15：Advanced Video Codingfileformat)o二者在规范中均采用了线索追踪索引方式，使得流服务器能够通过实时流方式传输媒体通道的信息。线索追踪中将视频和音频媒体信息是分开的，即媒体数据按照视频流和音频流分开传输。

       MPEG-2传输流的参考标准为MPEG-2的系统层。MPEG-2传输流是广播电视领域广泛采用的流传输标准。MPEG-2传输流标准定义了复用一个或多个音频、视频和数据元素流的方法。为应用于IPTV,媒体数据经过MPEG-2传输流封装后，再通过TCP/IP协议栈封装成IP数据包。

       基于IP的MPEG-2传输流方式的基本流传输过程如图3-3所示。

图3-3   基于IP的MPEG-2传输流方式的基本流传输过程

       基于IP的MPEG-2传输流方式同样采用服务器/客户端的结构。因为ISO/IEC13818-1标准并未定义控制层协议，应用于IPTV后，基于IP的MPEG-2传输流方式在控制层可采用RTSP或HTTP协议,媒体数据釆用MPEG-2传输流封装后，一般承载在UDP上。为了减少网络抖动等影响，也可在UDP之上釆用RTP协议封装TS包。

       基于IP的MPEG-2传输流方式流传输协议栈如图3-4所示。

        媒体数据流被打包加上时间标识，通过节目基本流(PES)打包和复用后形成可存储和传输的单一输出TS流。TS包由包头、自适应区和包数据3部分组成。由于每个包长度为固定的188B,在封装成UDP包和IP包后，需要考虑合适的包长度。与ISMA不同，基于IP的MPEG-2传输流方式是将视音频数据复用后在封装成TS包，因此输出流是单一的。

图3-4   基于IP的MPEG-2传输流方式d的流传输协议栈

       虽然ISMA和基于IP的MPEG-2传输流方式均可用于IPTV的流传输，但由于标准制定的机构和初衷不同，在对IPTV业务支持方面存在一定的差异，具体分析如下。

(1) 对业务功能的支持

      ISMA目前支持MPEG-4和H.264,不支持其他的编码标准。由于将视音频流分开传输,ISMA对于多音轨、多字幕等DVD体验功能和交互式场景的观看支持更灵活，且无须占用额外带宽资源。ISMA采用互联网已有协议，对于互动性业务的支持也更灵活并且若未来要支持视频通信、VoIP等通信类业务.ISMA的协议栈在视音频数据封装上也可直接支持,无须做扩展。

      基于IP的MPEG-2传输流方式对编解码标准无限制，可支持MPEG-2/4.H.264以及VC-1等多种编解码标准。但由于是将视音频流复用后单一流传输，基于IP的MPEG-2传输流方式对于多音轨、多字幕和未来交互式场景的观看的支持需要将所有流信息统一封装，势必要浪费用户不需要的那部分带宽。对于视频通信.VoIP等通信类业务，基于IP的MPEG-2传输流方式也需做扩展才能支持。

(2) 对业务性能的支持

       ISMA引入了RTP/RTCP协议，因此可通过RTCP来监测网络状况，便于对业务QoS控制。接收端通过RTP协议的时间戳实现视音频数据流的同步。但由于釆用了SDP描述流建立需要的信息，当进行直播频道切换时，客户端需要重新获取SDP文件，可能带来一定的切换时延。ISMA的封装协议开销主要来自RTP.TCP/UDP和IP的包头，开销相对较小，带来的传输效率较高。一般釆用UDP承载，如果未部署应用层丢包重传措施，当网络出现丢包时就容易出现画面马赛克等现象。接收端用PES包中的DTS/PTS作为解码和显示时间戳，时间信息更丰富，频道切换时间的延迟则主要来自网络。由于釆用固定长度的包结构，基于IP的MPEG-2传输流方式需要占用更多的开销相，也导致了其传输效率比ISMA低。

       总体来说.ISMA最大的优势在于是面向互联网应用而制定的开放标准，IP网的双向互动性带来对未来增值业务的支持更灵活，而基于IP的MPEG-2传输流方式最大的优势是成熟，尤其适合广播类业务，对互动性业务的支持则需要做一定的扩展。

       值得一提的是，虽然目前也有IPTV解决方案不是釆用上述两种协议，而是采用私有的第三方协议，但其基本思想也是利用互联网已有协议，与ISMA相近，只是在具体实现时略有差别。IPTV是一个跨行业、跨产业链、融合了多种技术的综合性业务，流传输技术是其端到端系统的关键技术之一。流传输机制的选择不仅与技术本身的特点相关，还与相应的产业链成熟度、系统成熟度和网络环境等因素相关。相信随着IPTV业务的开展，流传输技术也将逐步地成熟和完善，并形成统一的标准。

       IP网络上的数据包都携带着发出请求的终端IP地址、被请求的服务器的目标IP地址和端口号。端口号可以被看成是一个虚拟的邮箱入口，每当数据到达的时候，终端将根据端口号决定应当由哪个应用程序来接收该数据包。

       在网络通信中许多端口号被应用于特定的服务，如网络服务器的80端口应用于HT-TP服务的请求。当浏览器向一个网络服务器发出数据请求时，它把数据包发到服务器的80端口。因为数据请求是从80端口得到的，所以服务器就知道应当把它送给网页服务器的应用程序。实际上任何程序都可以使用80端口，同时网页服务器也可以使用任何其他端口,80端口仅仅是一个标准的网页服务器端口。其他的端口号服务于其他的程序或协议，如FTP,Telnet,收发电子邮件以及其他的网络服务。

        防火墙可以根据端口号决定是否将数据包进入终端所在的局域网。23端口是标准的Telnet端口，系统管理员可能使用防火墙堵塞来自外界对23端口的请求，以防止有人远程登录其服务器。除了端口号之外，不同的程序可以使用不同的协议建立相互的连接。HTTP协议就是网页浏览器和网络服务器用来进行数据传输的网络协议。

       很多应用程序在使用网络时，可同时使用不同的端口和协议。很多流媒体服务器可以通过HTTP协议，或同时使用RTSP协议来传输流媒体数据以避开防火墙。当流媒体服务器在使用HTTP协议时，如果80端口已经被同一台计算机上的网页服务器占用了，则媒体服务必须使用其他不同的端口。此时，一个应用程序使用了两种协议HTTP和RTSP。除此之外，同一终端上的两个应用程序可以使用相同的协议，但要使用不同的端口号以免发生冲突。

       流媒体服务器一般使用特别的协议与终端媒体播放器进行通信。HTTP不是特别适合流媒体，因为它内部有大量的数据结构，并缺少控制通道。缺少控制通道就意味着不能快速地前进或回退流数据。代替HTTP协议，流媒体服务器使用RTSP实时流协议，或是MMS协议与终端媒体播放器进行通信。

       实时流协议(Real-TimeStreamingProtocol,RTSP)是工作在RTP之上的应用层协议。它的主要目标是为单播和多播实时流媒体信息提供可靠的播放性能。RTSP的主要思想是提供控制多种应用数据传送的功能，即提供一种选择传送通道的方法，例如UDP、TCPJP多播，同时提供基于RTP传送机制的方法。RTSP控制通过单独协议发送的流，与控制通道无关。RTSP控制信息可通过TCP连接，而数据流通过UDP连接。通过建立并控制一个或几个时间同步的连续流数据，其中可能包括控制流，RTSP能为服务器提供远程控制功能。另外，由于RTSP在语法和操作上与HTTP类似,RTSP请求可由标准HT-TP或MIME解析器加以解析，并且RTSP请求可被代理与缓存处理。与HTTP相比，RTSP是双向的，即客户机和服务器都可以发出RTSP请求。

       RTSP可以用来控制一到数个音频或视频的媒体流，它负责的是流的控制，但传输时所用的协议或机制却不在它定义的范围内。也就是说，服务器可以选择用TCP或UDP来实现它的传输协议RTP。

       RTSP协议被设计为与下层协议无关的。它可以控制多个数据流传输的会话，并且这些会话可以使用下层的多个协议，如TCP、UDP、组播UDP等。一般地,RTSP所控制的实时流多同时使用RTP协议,但这并不是必须的。RTSP协议可以建立并控制一个或多个时间同步的连续流，但它本身并不传输流，它所起到的作用对于媒体服务器来说相当于一种“网络遥控功能”。RTSP协议在语法和操作方面极为相似于HTTP/1.1,但二者还是有着许多区别：

      （1） RTSP引入了许多新方法，并且具有一个和HTTP不同的协议标识符；

      （2） 在任何情况下.RTSP都要维持一种特定的状态（即使是默认的）；

      （3） 使用RTSP协议的客户机和服务器都可以发布请求信息；

      （4） 数据由一个不同的协议实施传输。

RTSP协议支持以下几种操作：

      （1） 从媒体服务器上接收媒体流。这是其最主要的功能。

      （2） 邀请一个媒体服务器参加一个视频会议，这种方式多应用于分布式教学系统中。

      （3） 使一个新的媒体流加入到一个已存在的演示中。这在直播演示时特别有用。

RTSP协议的具体操作模式可以有以下几种：

      （1） 单播式，媒体流从服务器传到客户。

      （2） 组播式，服务器选择地址：如直播或一般组播应用。

      （3） 组播式，客户选择地址：这种情况多出现在服务器参加一个已存在的视频会议时。

       MMS（Microsoft Media Server protocol）是另一种流媒体传送协议，用来访问并流式接收WindowsMedia服务器中由.asf文件描述的流媒体信息。MMS协议用于访问Windows Media发布点上的单播内容。若用户在Windows Media Player中用URL,而不是通过超级链接访问其所需的流媒体信息，则必须使用MMS协议引用该媒体流，MMS的默认端口是1755。作为一个流控制协议,MMS协议非常适合多媒体数据边传输边同时呈现的场合，如视频显示和音频播放。MMS协议不支持服务器端的播放列表，这一功能在RTSP窗口媒体扩展和窗口媒体HTTP流协议中提供。在多媒体数据总是用TCP传输的场合，窗口媒体HTTP流协议比MMS协议更适合，因为它不包括UDP功能。

       MMS协议利用TCP连接控制流媒体会话。当用户作为发起TCP连接的实体时，服务器则作为响应该连接的实体，同时多媒体数据从服务器流向客户。客户可以通过TCP连接向服务器发送MMS协议请求消息，请求服务器执行开始、停止多媒体数据流的动作。多媒体数据既可以通过相同的TCP连接传送，也可以通过UDP包传送数据流。在服务器将多媒体数据传送给客户时，客户可以发送MMS协议消息给服务器，请求改变正在传输的流。例如，客户可以请求服务器用一个是较低比特率的版本来代替现在正在传输的视频流。如果UDP被用来传输多媒体数据给客户端，客户可以发送一个MMS协议消息给服务器，请求它重传一个UDP包。当客户没有收到服务器已经发送的UDP包时，这一方法非常有用。不像客户发出的其他MMS协议消息，这一重发UDP包的请求是用UDP包来发送的。

        当使用MMS协议连接到节目信息发布点时,可使用协议翻转以获得最佳连接。“协议翻转”始于试图通过MMSU来连接客户端,MMSU是MMS协议结合UDP数据传送。如果MMSU连接不成功，则服务器会尝试使用MMST,MMST是MMS协议结合TCP数据传送。

        如果用户连接到.asf文件，并想对媒体流进行快进、后退、暂停、开始和停止等操作，则必须使用MMSO若想从独立的WindowsMediaPlayer连接到节目信息发布点，则必须指定单播内容的URL。若内容在主发布点点播发布，则URL由服务器名和.asf文件名组成。例如：

        mms://windows_media_server/sample.asf

       其中windows_media_server是Windows Media服务器名,sample,asf是想要使之转化为媒体流的.asf 文件名。

       如有实时内容要通过广播单播发布，则该URL由服务器名和发布点名组成。例如：   mms://windows_media_server/liveevents

       这里windows_media_server是Windows Media服务器名，而liveevents是发布点名。