视频点播IPTV数字电视机顶盒——基于嵌入式Linux的设计

【中心议题】
    * IPTV数字电视机顶盒的总体设计
    * IPTV数字电视机顶盒的软件架构和模块设计
【解决方案】
    * 采用分层结构，分为内核层、中间解释层和应用层三个层次
    * 设计中引用了Live555开源类库

0视频点播IPTV数字电视机顶盒研发背景

IPTV（Internet Protocol Television）即交互式网络电视，是一种利用宽带网络作为基础设施，集互联网、多媒体、通讯等多种技术于一体，通过IP协议向用户提供包括数字电视在内的多种交互式服务的崭新技术。视频点播作为IPTV的核心业务，其实质是实现流媒体的播放，这样一来，流媒体播放机顶盒的功能和性能对于IPTV有着很大的影响。目前已经有一些适合商用的流媒体服务器，但是对基于IPTV机顶盒的流媒体终端还没有一个统一的解决方案，因此对基于IPTV机顶盒的视频点播终端的研究显得很有意义。

1 IPTV数字电视机顶盒的总体设计

本文研究的视频点播系统采用C／S模型，是实现一台服务器为多个客户端提供视频服务的多用户系统。系统结构如图1所示：

在该系统中，客户端为用户提供观看视频点播节目的接口。首先，客户端登录服务器，获取EPG节目单，得到感兴趣视频文件的URL，机顶盒与相应的流媒体服务器建立连接，发送点播请求。流媒体服务器根据点播的请求情况，创建相应的服务线程，而后从机顶盒返回SDP描述，传送相应节目的流数据。客户端将接收到的流数据进行解复用、音视频解码后通过电视机显示输出。同时，将用户的控制命令发送给服务器，并周期性的向服务器发送RTCP报文反馈信道质量信息。在节目播放过程中，用户可以根据自己的需要向流媒体服务器发送节目控制请求。如图2所示：

由图2可以看出，整个终端主要分为数据接收，媒体播放和显示输出三大部分。从功能上分别概括为流媒体数据接收模块，音视频解码播放模块和人机交互模块。

其中，流媒体数据接收模块，主要是登陆服务器，接收并处理来自网络的流媒体数据。本论文研究系统中为MPEG－2 TS流，并将其放入环形缓冲区中，实现客户端与服务器的交互。音视频解码播放模块，通过STB810开发板用硬件实现对MPEG－2 TS传输流的解复用，分解出视频基本流和音频基本流，并送往解码模块，调用DirectFB的解码器接口，完成对音视频流的解码，从而实现对媒体播放的处理和控制。

人机交互模块，涉及输入设备和图像的显示输出，并且由于嵌入式平台下面没有集成类似MFC（Microsoft Foundation Classes）的基础类库和完善的消息响应机制，本论文将借助于DirectFB实现了一套自己的事件响应、处理机制。同时使用封装好的DirectFB API接口直接将图形图像数据解码并显示。

2IPTV数字电视机顶盒的软件架构

IPTV机顶盒作为客户端，除了需要具有良好的硬件平台外，还需要拥有软件系统才能够实现IPTV业务功能。相应的，STB810和大多数的机顶盒软件一样采用分层结构，分为内核层、中间解释层和应用层三个层次：内核层：包括机顶盒终端硬件和Linux内核。而对于机顶盒终端硬件这一部分主要是指机顶盒硬件中的流媒体处理引擎与流媒体解码芯片。Linux内核（版本2.6.21）是指嵌入式Linux操作系统，用以控制硬件。中间解释层：重新搭建整个软件平台的开源软件的工具包。包括一个用于音视频直播／点播使用的视频传输协议栈，用于驱动流媒体解码芯片的驱动程序和外接存储设备以及摄像头的驱动程序，用于绘制界面、将解码后的数据显示并输出到电视上的DirectFB库。

软件基础构架如图3所示：

DVB API采用的是Linux DVB API version3，主要用到其中的Linux DVB Demux Device API，用于解复用TS流。

ALSA为Advanced Linux Sound Architecture，先进Linux声音架构，是Linux平台上的用途广泛的音频API，用于音频流混频。

DirectFB是专为嵌入式开发的轻量级图形界面库。

3IPTV数字电视机顶盒的模块设计

3.1数据接收模块

主要根据RTSP／RTP协议设计视频流的接收。详细设计中引用了Live555开源类库，原因是因为LIVE555开源库可用于流式化，接收和处理MPEG2、H.263＋、JPEG的视频和其他一些音频格式，同时也很容易扩展支持其他音视频格式，因此采用该库用来构建基本的RTSP终端。下面简单的介绍一下流媒体客户端运用到的LIVE555中各类的作用：

MediaSession：对session做总体控制，例如得到session的起始结束时间，session播放的scale以及Seek等。另外，使用RTSPClient传来的SDP信息初始化整个mediasession。

RTSPClient类：实现与RTSP服务器的交互，向RTSP服务器发送各种请求消息，接收并解析RTSP服务器返回的消息。

RTPSource类：实现从服务器读取RTP数据包，解析数据包的功能。本身只提供了少量实现，主要使用子类MultiFramedRTPSource实现具体的取包操作。

MultiFramedRTPSource类：获取服务器传过来的Frame，与读取RTP包密切相关。

RTPInterface类：实现RTP数据包的发送／接收的功能接口。

MediaSink类：数据接收的终点是Sink类，MediaSink是所有Sink类的基类。Sink类实现对数据的处理是通过实现纯虚函数continuePlaying（），通常情况下continuePlaying调用fSourc

e－＞getNextFrame来为Source设置数据缓冲区，处理数据的回调函数等。

3.2环形缓冲区

原有的数据接收模块设计并没有充分考虑网络传输时的时延抖动问题，对于数据接收的缓冲区设计也只是一个简单的写入读取操作。如图4所示：

每个item的长度为BUFFER＿PLAY＿THRESHOLD bytes，即一次写入或从缓冲区读取数据的比特数，这里将其用item代替。从图4可以看出，整个缓冲区的长度只有单个数据包的大小，对数据包的写入和读取都是通过调用首指针来进行操作，整个流程就重复着在同一个起始地址进行数据包读写。当网络传输发生时延时，数据包无法实时写入缓冲区，而读操作仍然调用首指针从起始位置读取数据包，但实质上读取的还是上一个数据包，从而导致了客户端无法获得实时数据，在视频点播时就会出现画面定格或解码出错等非正常现象。

基于以上原因，提出对缓冲区的改进，采用环形缓冲区存储数据过滤时延抖动。首先将从流媒体服务器端发送来的数据包（MPEG－2 TS流），存储到环形缓冲区中，当积累到一定的量时再将数据传给解复用设备，由PNX8550媒体处理引擎能够对TS流进行解复用，平稳地送往DirectFB解码器解码，从而解决了视频包抖动的问题。

缓冲区一般是在RAM中开辟的一段空间。而RAM是一种随机存储设备，不具有数据读写循环的特性，只是人工制定了一种读写规范，使得数据的读写好像是使用一段环形存储器，可以不断循环读写以实现数据的正确缓冲，这就是环形缓冲区技术。

环形缓冲区是一个先进先出的循环缓冲区，可以向通信程序提供对缓冲区的互斥访问，比普通缓冲要节省内存，时实性比较高。因为它不用等待缓冲区写满，只要有数据就可以读，只要有空间就可以写。环形数据缓冲区通常有两个指针：写指针（writePtr）和读指针（readPtr）。写指针指向环形缓冲区中可写的缓冲区，读指针指向环形缓冲区中可读的数据。所有写入缓冲区的数据，都通过写指针完成，所有读出缓冲区的数据都通过读指针完成。无论是写指针还是读指针都不得顺时针超越另一指针，当读指针赶上写指针表示缓冲区已空，当写指针赶上读指针表示缓冲区已满。环型数据缓冲如图5所示。从物理结构看，环形缓冲区就是普通的一段连续的内存，只是通过控制指针，从逻辑上使得其首尾相连，成环形状。

3.3音视频编解码播放模块

一般MPEG－2 TS流解码流程如图6所示：

4结束语

本文给出了一种良好的嵌入式机顶盒设计。该设计对终端流媒体数据接收模块中的缓冲区进行了深入的分析，提出采用环形缓冲区技术的改进方案，来解决网络传输中存在的时延抖动问题，有效地提高了视频播放的质量。