1 引言

　　随着IT 的发展，互联网已进入千家万户，人们希望通过互联网来收听收看喜闻乐见的电视节目，流媒体（real-time media）技术的发展为人们提供了这种可能。电视作为典型的多媒体以其丰富的节目内容更加充实了互联网本身，电视和互联网的结合，将逐渐成为发展趋势，网络电视应运而生。网络电视，也叫IPTV，是利用宽带互联网的基础设施，以家用电视机作为主要终端，通过互联网协议（IP）来提供包括电视节目在内的多种数字媒体服务及其增值业务的技术。IPTV的优势在于“互动性”和“按需观看”，彻底改变了传统电视单向广播的特点。IPTV现在支持直播电视以及基于IP网络的视频点播业务。网络电视已成为当今互联网的亮点，越来越引起各级电视台的重视。

　　2 网络直播电视基本原理

　　网络直播电视针对电视台的现场节目（如娱乐晚会，体育比赛等），提供互联网接入方式。直播节目在网络传输上通常采用UDP组播方式，以达到节省网络带宽的目的。

　　图1中Broadcaster负责对直播节目的模拟信号进行采集、编码，并实时将编码后的数字信号采用RTP/RTCP协议组播出去。对于每一个直播节目频道，Broadcaster会生成一个SDP协议描述文件，描述该频道组播数据流的相关参数，包括组播网络地址、音视频的采样频率等。Player是支持组播功能的流媒体播放器。接收直播电视节目时，Player首先得到该直播频道的SDP文件，通过对SDP文件的解析，获得该直播频道的组播参数，加入组播组，接收组播数据流，收看直播节目。

　　3 延时续播电视设计与实现

　　通过网络直播电视，用户可以收看现场节目，突破了传统电视节目的传输模式，但还无法发挥出网络电视“互动性”和“按需观看”的优势。

　　由于某些原因，用户不能连续收看直播电视节目，比如在收看过程中需要接听电话或者处理其他紧急事务。传统的网络直播电视不能针对这种情况对电视节目做相应的调整，用户只能错过部分直播电视节目。而延时续播电视在这种情况下，可以对直播电视节目做“暂停”处理，当用户处理完手中的事情后再进行“续播”操作就可以从刚才中断的地方继续收看直播电视节目。

　　3.1 基本原理

　　延时续播电视的实现需要流媒体服务器的参与，在Broadcaster组播直播节目的过程中，流媒体服务器不间断地接收组播流，对组播流做缓冲处理。当用户进行“延时续播”操作的时候，播放器从接收组播模式转入延时续播模式，将延时的时间参数发送到流媒体服务器，接下来的电视节目数据由流媒体服务器从接收缓冲池中读取，并发送至播放器。

　　3.2 功能模块设计

　　3.2.1 接收组播流模块

　　系统启动时，流媒体服务器读取并解析SDP文件，获得每个直播频道的组播参数，加入组播组，开始接收组播流数据。针对组播的网络特性，在该模块中设置接收缓冲队列，根据接收RTP包的序号对组播流做排序处理，确保将RTP数据按照发送顺序写入缓冲文件。

　　3.2.2 缓冲文件操作模块

　　该模块包括将数据写入缓冲文件和从缓冲文件中读取数据的功能。本方案采用了缓冲技术对文件读写操作做优化。对缓冲文件读取时，为了快速定位，需要对缓冲文件按照时间建立索引。由于缓冲文件不断增长变化，缓冲文件的索引也要同步更新，因此需要单独生成索引文件、音频数据文件和视频数据文件。索引项数据结构如下：

　　typedef struct tagRTPFileIndex

　　{

　　time_t lTime;   // 索引时间（秒）

　　int  iVideoFileNum; // 视频文件序号

　　int  iVideoOffset;  // 视频文件偏移

　　int  iAudioFileNum; // 音频文件序号

　　int  iAudioOffset;  // 音频文件偏移

　　}RTP_FILE_IDX_T;

　　3.2.3 延时续播请求处理模块

　　流媒体服务器处理延时续播的流程与正常点播流程大致相同，但是操作的文件由普通流媒体文件改为缓冲文件，定位文件的时间参数也有所不同。本方案的实现中与播放器端约定以点播文件名后缀为“TS”标识延时续播点播请求。同时约定定位文件的时间参数表示点播时间据当前时间的间隔时长。

　　3.3 关键技术及解决方案

　　3.3.1 缓冲文件读写操作

　　流媒体系统运行过程中，随着用户数量的增加，系统对流媒体文件的访问频率也迅速增加。如果采取直接读取文件的方式，很容易造成系统的I/O性能瓶颈。同时，延时续播系统需要不间断地接收Broadcaster组播的RTP数据流，每个直播频道以50-100包/秒的频率发送RTP数据。如果以这个频率对缓冲文件进行写操作，将使系统的I/O性能急剧恶化。

　　本方案采用了缓冲技术优化文件写入操作。在写入缓冲文件前，先将RTP数据包在内存中整理成一个相对较大的数据块，再写入缓冲文件，大大降低了I/O操作频率。对于文件读取操作，则借鉴操作系统虚拟内存管理技术对系统访问的文件内容在内存中做了缓冲处理，有效降低了系统的IO访问频率。

　　读取操作处理流程如图4所示，首先确定缓冲内存块大小（本方案为8K），然后对磁盘文件按照内存块大小进行划分，建立磁盘文件MAP。MAP采用数组作为存储结构，记录对应磁盘文件分块的起始位置、结束位置、分块编号，以及对应内存缓冲块指针等信息。内存缓冲块中设置一个标志记录当前对应磁盘分块的编号。

　　读取磁盘文件时，按照以下步骤进行操作：

　　1． 根据读取位置在文件内的偏移计算出对应的分块编号；

　　2． 查找磁盘文件MAP；

　　3． 如果MAP项中内存缓冲块指针为空，转第7步；

　　4． 根据MAP项内存缓冲块指针，访问内存缓冲块；

　　5． 如果内存缓冲块记录的分块编号不等于该分块编号，转第7步；

　　6． 从内存缓冲块中读取文件内容；

　　7． 在内存缓冲块链表中按照近少使用规则（LRU）确定淘汰块；

　　8． 读取磁盘文件块的内容到淘汰块中，修改内存缓冲块文件分块编号；

　　9． 修改MAP项内存缓冲指针，指向该淘汰块，转第6步。

　　本方案对系统IO性能的改善体现在两个方面。首先对磁盘文件采取了按“块”读取的方式，实现了虚拟存储管理中的预调策略。而对流媒体文件的访问具有很强的顺序性，预调策略能有效提高内存缓冲区的命中率。用户数量增加时，各用户对文件访问的位置具有一定的分布特性。在某一时刻容易集中在文件的某一区域，比如影片的起始位置往往是访问较频繁的区域。这时，用户对文件访问的位置出现重叠，后访问的用户就可以直接从内存缓冲区中读取文件内容，减少了对磁盘文件的读取操作。

　　本方案实现中，对用户访问流媒体文件进行计数，根据计数动态调整内存缓冲块的数量。当某文件的访问计数增加时，增加缓冲块数量，反之则减少缓冲块数量。这样能有效利用内存缓冲块。

　　3.3.2 续播文件定位

　　通常情况下，流媒体系统中服务器和播放器的系统时间不能保持一致。这对延时续播电视中描述用户需要续播的时间点造成了一定困难。本系统实现中，采用相对时间偏移的概念来描述用户的续播需求。

　　如果用户在收看直播节目的过程中进行了“暂停”操作，播放器会记录下该时间点。当户用进

　　这种描述机制计算比较简单，避免了因为服务器和播放器系统时间不一致造成的时刻混乱。

　　3.3.3 短延时处理

　　当用户启动延时续播功能时，播放器实际上由接收组播流模式转变为点播模式。很明显，点播操作对服务器造成的性能影响和对网络造成的压力要远大于组播操作。因此在播放器端有必要采取适当的措施避免因用户误操作或者恶意操作造成的短延时续播。

　　本方案在播放器端设置了接收缓冲队列长度（比如60秒）。正常播放的情况下，接收缓冲队列处于较小的长度（比如2秒）。当用户暂停直播节目时，播放器停止读取接收缓冲队列的数据，但不立即停止接收组播数据。这种情况下，接收缓冲队列长度逐渐增大。如果用户在较短的时间间隔后进行了续播操作，播放器不用切换到延时续播模式，而是继续从接收缓冲读取数据。由于没有停止接收组播数据，所以播放器接收缓冲队列中的数据是连续的，只是队列的长度发生了改变，处于比正常播放情况更长的状态。如果用户暂停的时间较长，或者进行了反复的暂停操作，接收缓冲队列达到了长度，播放器停止接收组数据，当用户再次续播操作时，转入延时续播模式。

　　这种处理机制在播放器屏蔽了大多数短延时续播操作，即满足了用户的需求，又有效降低了服务器端和网络的压力。

　　4 结束语

　　本方案针对延时续播需求设计，但是对播放器稍作修改还可以实现对直播节目按时点播的功能。由于本方案的实现主要是在流媒体服务器端增加功能模块，对播放器端没有太多的修改，对播放器的运行环境也没有特殊的要求，容易实现对通用播放器的兼容。特别在嵌入式IPTV机顶盒应用中播放器端的运行环境比较苛刻，没有硬盘和大容量内存的支撑，实现延时续播功能只能在服务器做改进，本方案在这种情况下有较大的应用空间。

　　5 本文作者创新点

　　? 在服务器端实现直播电视节目的“时移”功能，不受播放器运行环境的限制，适合嵌入式终端应用；

　　? 在服务器端采用缓冲技术改善文件读写性能，提高服务器并发服务能力；

　　? 在播放器端采用动态缓冲队列屏蔽了“短延时”操作，提高系统的稳定性。
　　请登陆: 维库电子市场网（www.dzsc.com） 浏览更多信息