一种基于RTPMulticast的流媒体传输系统设计

所谓流媒体，是指采用流式传输方式在Internet 播放媒 体文件。流式传输方式就是将整个音频和视频等连续媒体文 件经过压缩后，由服务器向用户计算机连续和实时传送。用 户只需经过几秒或几十秒的启动延时即可对进行播放和观 看，剩余部分将在后台继续下载，边下载边播放。与单纯的 下载方式相比，这种对多媒体文件边下载边播放的流式传输 方式不仅使启动延时大幅度地缩短，而且对系统缓存容量的 需求也大大降低。 为了配合网络上的流媒体应用，目前已经存在许多标准 协议。在流媒体中用得较多的RTP协议是实时传输协议RTP 和实时传输控制协议RTCP的统称。RTP 针对媒体数据流提 供负载标示、数据序列号，时间戳等用来进行流同步，RTP 会话期间会周期性的发送RTCP 包，提供数据包数量、丢包 数量等的统计资料，用来为流量控制和拥塞控制服务。实时 流协议RTSP(Real-Time Streaming Protocol)是一个应用级协 议，用来控制实时数据的发送。它可以由客户端或服务端发 起，协商数据传输的方式，同步多个服务器发送的内容，可 以相互配合实现VCR功能。会话宣告协议SAP和会话初始化 协议SIP都可以用来发起一次会话，而它们都需要会话描述 协议SDP 来对会话的名称、音频视频的编码方式和地址端 口，所用的传输协议进行描述。 网络带宽是流媒体传输的最主要瓶颈，要支持大规模的 流媒体服务，组播( Multicast ) 是最好的解决方法。由于TCP 的慢启动特性和丢失重传的可靠性保证，使得它并不适合流 媒体传输，更不适合组播。当前大多数研究均是基于UDP的 Multicast，而用RTP/RTCP作为信息反馈的框架。
第 30卷 第 9期 Vol.30 №9
计 算 机 工 程 Computer Engineering
文章编号： 1000— 3428(2004)09 — 0162— 04 文献标识码： A
2004年 5月 May 2004
中图分类号： TP37
・多媒体技术及应用・
一种基于 RTP/Multicast的流媒体传输系统设计
吴敏强，周 俊，朱晴波，陆桑璐，陈道蓄
（南京大学软件新技术国家重点实验室，南京 210093） 摘 要 ： 流媒体技术是当前研究和开发的一个热点。在开发基于多服务器的大规模流媒体服务器平台中，该文提出了一种基于 RTP/Multicast 的流媒体传输系统。这个传输系统实现了统一传输模型，即单播和组播配合实现对热门影片的组播，还实现了基于RTCP 反馈的简单流量 控 制算法NFC。该系统已经实现，并在做进一步的完善。 关键词： 流媒体；组播；流量控制
(2) 根据描述文件中的信息，客户程序通过 RTSP 与 Media Server 交互，协商传输TSP发送控制命令，如play, pause, stop。
C->M: SETUP rtsp://202.119.36.222/twister/video RTSP/1.0 基 金 项 目 ： 国家“ 863 ”计划资助项目 (2001AA113050) ；江苏省高 技术产业化推进项目资助 作者简介： 吴敏强（ 1977—），男，硕士生，研究方向：网络多媒 体；周 俊、朱晴波，硕士生；陆桑璐，副教授；陈道蓄，教授、 博导 收稿日期： 2003-04-14 E-mail： zhaujun@
该影片被点播的次数 (1)
将Pi按降序排列，即热门程度从高到低排列，取前面的 β%作为热门影片用来组播（例如β= 10，即可以覆盖大部 分的请求）,设共有B部热门影片M1,M2,… ,MB。 我们一共有N个频道，其中单播频道Nu个，组播频道Nm 个，假设Nm ≥ B，且Nm较大，影片能有多个频道播放。把N m 个频道在热门影片之间按照点播概率大小分配，这样热
1 流媒体传输系统 NDSMTS的结构和流程
NDSMTS系统的结构如图1所示。 (1) 浏览器通过HTTP/TCP 协议与Web服务器交互，以 便把需要传输的实时数据从原始信息中检索出来；然后浏览
—162—
CSeq: 1 Transport: RTP/AVP; multicast M->C: RTSP/1.0 200 OK CSeq: 1 Transport: RTP/AVP; multicast; destination=224.123.12.3; Port=3456-3457; ttl=16 Session: 0456804596 C->M: PLAY rtsp://202.119.36.222/twister/video RTSP/1.0 CSeq: 2 Session: 0456804596 M->C: RTSP/1.0 200 OK CSeq: 3 Session: 0456804596
Design of a RTP/Multicast Based Streaming Media Transmission System
WU Minqiang, ZHOU Jun , ZHU Qingbo, LU Sanglu, CHEN Daoxu
(State Key Lab for Novel Software, Nanjing University, Nanjing 210093) 【Abstract】 Streaming media technology is a hotspot of research and development these days. In the project of building a multi-server based large scale streaming media service platform, this proposes a RTP/Multicast based streaming media transmission system. This system designs the unified transmission model, i.e. single cast cooperates with multicast to multicasting hot media, and we also implements an RTCP based single flow control algorithm, NFC. This system has been implemented and will be improved later. 【Key words】Streaming media；Multicast；Flow control
ＴＲｉ
Ｃｉ
图3 组 播 示 意 图
假设系统有S部影片，记为Mi(1≤i≤S)，为简单起见设 每部影片的长度是L秒(这个假设不是必须的,也可以设每部 影片的长度为Li秒)。通常认为视频点播满足著名的的季普 夫（Zipf）分布，即绝大多数请求集中在少数影片上，因此 只对热门影片进行组播。假设每部影片被点播的概率为Pi(1 ≤i≤S)。 Pi = 所有影片总的点播次数
(2)
点播率每天统计一次，以反映影片的冷热变化。影片点 播率的变化会影响组播频道的分配，逐渐热门的影片将进入 组播，逐渐不热门的将退出组播。 剩下的Nu个单播频道共享一个请求队列，采用FCFS 策 略。这些单播频道有3个作用：(1)用于进一步减小用户的等 待时间；(2) 用于冷门影片的服务；(3)为用户的随机访问支 持保留。
门影片Mi能够在Ci = P
i B
∑
N
j
m
P
j =1

个频道进行组播（当然，
必须保证Ci≥1，若某个Ck = 0, 则我们不对k以后的影片进行 组播）。这样，对于热门影片Mi来说，每隔 TRi秒就有一个 流开始为用户服务。 B ∑ Pj ∗ L j =1 TRi = L / Ci = Pi ∗ Nm
器启动播放器，使用HTTP从Web服务器检索相关参数对播 放器初始化。这些参数可能包括目录信息、媒体数据的编码 类型或媒体服务器地址。参数格式采用会话描述协议SDP 来 进行描述。
图 1 NDSMTS 的结构和流程 C->W: GET /twister.sdp HTTP/1.1 Host: Accept: application/sdp W->C: HTTP/1.1 200 OK Content-Type: application/sdp v=0 o= - 2890844526 2890842807 IN IP4 202.119.36.100 s=RTSP Session m=video 0 RTP/AVP 31 a=control: rtsp://202.119.36.222/twister/video
图 2 UTM 的传输服务模型
影片长度（Ｌ） 某一组播 频道 重复组播 ・・・
2 统一传输服务模型
视频点播有两种方式：True-VOD （TVOD ）用户在任 何时候点播都立即响应并开始服务，这样必须为每个用户长 时间保留大量的网络和磁盘带宽；Near-VOD（NVOD）用 户点播之后并不是马上响应，而是积聚一定的请求之后，采 用一定的技术如批处理、组播等统一处理。TVOD 代价太 大，而NVOD却有很大的改进空间，因此成为研究的热点， 人们希望能够找到启动延迟短、随机性好支持请求多的方 法 。 这 里 提 出 一 个 统 一 的 传 输 模 型 UTM （ Unified Transmission Model），以组播为主，将单播和组播相结合统 一处理，单播最后并入组播输。通过流合并UTM将单播和 组播相结合，简单而易于实现，同时便于扩展。在此基础上 可以更进一步实现如金字塔广播算法、摩天大楼广播算法等 流调度算法。 2.1 UTM的频道分配方案 一个媒体流所占用的网络和磁盘带宽称为一个频道 （channel）。批处理技术（batching）通过聚集短时间内对 同一影片的请求，用一个媒体流为多个用户提供服务，这将 减少服务器服务特定数量用户而占用的系统资源。增加 batching 间隔时间能节约更多的带宽，但同时也会增加用户 的启动延迟。批处理技术有两种基本的策略：FCFS（ First Come First Serve）和MQL（Maximum Queue Length ）。 先来先服务策略 FCFS ，所有的请求都进入同一个队 列，先来的请求总是先离开队列，当一个请求得到服务后， 其他对该影片的请求也同时得到服务。这个策略比较公平， 但是，它没有考虑到不同影片的受欢迎程度，因此批处理带 来的系统收益不是很大。它可能让很多等待一部非常热门的 影片的用户离开，造成系统的反悔率大幅度的提高。 最长队列优先策略MQL，所有对同一个影片的请求将 进入同一个队列，而点播不同影片的请求将进入不同的队 列。服务器将选择队列长度最长的影片合并成一组进行服 务。这个策略将获得最大的批处理的性能收益，降低系统的 平均反悔率。但是，由于它没有考虑用户的等待时间，因此 它的服务是不公平的。在系统繁忙的情况下，那些点播非热 门的影片的用户将一直得不到服务。 采用一种改进的先来先服务策略，如图2和图3所示。