CN101827242A

CN101827242A - 一种基于网络电视机顶盒的可视电话系统实现方法

Info

Publication number: CN101827242A
Application number: CN 201010167582
Authority: CN
Inventors: 王汝传; 黄益贵; 黄小桑; 李致远; 韩志杰
Original assignee: Nanjing Post and Telecommunication University
Current assignee: Nanjing Post and Telecommunication University; Nanjing University of Posts and Telecommunications
Priority date: 2010-05-10
Filing date: 2010-05-10
Publication date: 2010-09-08
Anticipated expiration: 2030-05-10
Also published as: CN101827242B

Abstract

一种基于网络电视机顶盒的可视电话系统实现方法，是一种在网络电视(IPTV，Internet Protocol TV)机顶盒上实现可视电话功能的方案，基于本项目组在TI(德州仪器)公司提供的达芬奇数字平台TMS320DM6446上开发的IPTV对等计算机顶盒所提供的应用功能扩展，属于IPTV增值业务领域。该方法通过对可视电话系统的功能划分，设计多线程并行执行，嵌入式微处理器ARM负责视频采集与显示、语音编解码与音唇同步、数据包的传输与控制、信令控制，数字信号处理器DSP负责视频编解码，完成与网络电视IPTV机顶盒平台的无缝结合。

Description

一种基于网络电视机顶盒的可视电话系统实现方法

技术领域

本发明是一种在网络电视(IPTV，Internet Protocol TV)机顶盒上实现可视电话功能的方案，基于本项目组在TI(德州仪器)公司提供的达芬奇数字平台TMS320DM6446上开发的IPTV对等计算机顶盒所提供的应用功能扩展，属于IPTV增值业务领域。

背景技术

可视电话业务是通过传统电话网、互联网、视讯专网的形式，对称、实时地实现语音、图像、数据等信息交流的多媒体通信业务。目前可视电话业务的实现较常见于基于个人计算机、3G手机、专用的电视电话系统等软件。国际上制定的可视电话系统标准主要有H.323和SIP(Session Initiation Protocol)，本发明考虑该IPTV机顶盒开发平台的软硬件特性，决定采用H.323作为可视电话系统实现的标准。

H.323是国际电信联盟(ITU)的一个标准协议栈，该协议栈是一个有机的整体，根据功能可以将其分为四类协议，也就是说该协议从系统的总体框架(H.323)、视频编解码(H.26X)、音频编解码(H.7XX)、系统控制(H.245)、数据流的复用(H.225)等各方面作了比较详细的规定。为网络电话和可视电话会议系统的进一步发展和系统的兼容性提供了良好的条件。视频编解码协议包括H.261和H.263，H.264是由ITU和ISO(国际标准化组织)联合提出的视频编解码标准；音频编解码协议包括G.711协议(必选)、G.722、G.723.1、G.728、G.729等协议。

TMS320DM6446平台是基于TMS320DM6446高性能达芬奇双核处理器芯片，结合AIC32/TVP5146等高性能的音频编解码/视频解码芯片的一个视频通讯平台。TMS320DM6446首次把业界最为流行的ARM926和DSP6000集成在一片SOC(System On Chip)中，采用VLIW结构，同时还提供了高精度视频端口、无缝以太网、多通道音频等。该器件的性能水平高于一般媒体处理器，并为功能性与系统集成度的增长留有充分空间。TMS320DM6446芯片的结构特点包括：

(1)高性能。采用低功耗、高性能的32位C64x+内核和ARM926EJ-S内核，工作频率分别高达594MHz和297MHz，具有很强的运算处理能力。

(2)低功耗。多电源管理模式，双内核电压供给为1.6V；ARM926EJ-S内核具有16KB指令和8KB数据缓存(Cache)，TMS320C64x+DSP内核具有32KB程序RAM/Cache、80KB数据RAM/Cache及64KB未定义RAM/Cache；支持3.3V或1.8V的I/O接口和存储器接口。

(3)专用的视频图像处理器和视频处理子系统。专用的视频图像处理器用于对视频数据处理；视频处理子系统包括1个视频前端输入接口和1个视频末端输出接口，视频前端输入接口用于接收外部传感器或视频译码器等图像，视频末端输出接口输出图像到SDTV(标清电视)、LCD(液晶显示器)、HDTV(高清电视)等显示屏上。

(4)大存储容量。有256MB的32位DDR2SDRAM存储地址空间，128MB的16位FLASH存储地址空间。

(5)众多的外设。64通道增强型DMA控制器；串行端口(3个UARTS、SPI、音频串口)；3个64位通用定时器；10/100M以太网；USB2.0端口；3个PWM端口；多达71个通用I/O口；支持MMC/SD/CF卡等。

TMS320DM6446开发套件提供了丰富的API(Application ProgrammingInterface)供程序员较为方便的开发各种应用，其中核心部分便是用DSP(DigitalSignal Processor)处理各种音视频编解码，这主要包括视频MPEG-4、H.264编解码，音频G.711A律、G.729编解码等。笔者在本系统中采用遵循H.323协议框架的H.264标准编解码视频流，G.711A律标准编解码音频流。由于在该系统中DSP运算的独占性，在进行视频编解码运算的同时不能够支持音频编解码，我们将音频编解码采用ARM处理器运算。由于音频编解码的运算量较小，且在通话中利用silencesuppression(语音间隙删除)方法，即系统在音频编码前先对采集的音频信号进行静音侦测，如果客户在接听对方讲话就不编码，不发送或仅向对方发送最小的背景噪音帧，这样可进一步降低平均音频比特率，提高通话质量的同时使得音频运算量大幅度降低。

H.264的最大优势是具有很高的数据压缩比率，在同等图像质量的条件下，H.264的压缩比是MPEG-2的2倍以上，是MPEG-4的1.5～2倍。H.264标准的主要特点如下：

(1)更高的编码效率。同H.263等标准相比，能够平均节省大约50％的码率。

(2)高质量的视频画面。H.264能够在低码率情况下提供高质量的视频图像，在较低带宽上提供高质量的图像传输是H.264的应用亮点。

(3)提高网络适应能力。H.264可以工作在实时通信应用(如视频会议)低延时模式下，也可以工作在没有延时的视频存储或视频流服务器中。

(4)采用混合编码结构。同H.263相同，H.264也采用DCT变换编码加DPCM的差分编码的混合编码结构，还增加了如多模式运动估计、帧内预测、多帧预测、基于内容的变长编码、4x4二维整数变换等新的编码方式，提高了编码效率。

G.711也称为PCM(脉冲编码调制)，是ITU制定出来的一套语音压缩标准，主要用于电话。它主要用脉冲编码调制对音频采样，采样率为8k每秒。它利用一个64Kbps未压缩通道传输语音讯号。压缩率为1∶2，即把16位数据压缩成8位。分为A律编码和μ律编码两种，其中A律被特别设计用于计算机处理的。

IPTV机顶盒主要用于在普通电视机上享受IPTV服务，将计算机网络中的音视频流以及其它增值服务引入到只有模拟电视机的家庭，除了将数字信号转换为模拟信号的传统机顶盒功能外，更为主要的是基于MontaVista Linux操作系统的机顶盒可以支持各种ARM和DSP CPU运算能力可及的服务，如电子商务，股票交易，视频监控以及本专利所阐述的可视电话等功能。

综上所述，基于IPTV机顶盒的可视电话系统主要包括视频编解码模块、音频编解码模块、音视频数据的发送与接收模块，信令控制模块等。视频编解码模块包括用DSP编码本地摄像头捕获的原始数据，将其压缩成支持H.264标准的视频流以及用DSP解码从网络获取的视频数据，写入到显示缓冲中，在电视机上显示出来；音频编解码模块包括用ARM编码本地麦克风捕获的原始语音数据，将其压缩成支持G.711A律标准的音频流以及用ARM解码从网络获取的音频数据，写入到声卡的输出缓冲中，驱动扬声器发出语音。信令控制模块处理包括呼叫连接与呼叫释放，以及呼叫控制与连接控制。

发明内容

技术问题：本发明的目的是提供一种基于网络电视机顶盒的可视电话系统实现方法，解决其多任务并行执行、视频采集与显示、语音编解码、数据包的传输与控制、信令控制等问题。该方案遵循通用标准，针对特点平台量体裁衣，具有新颖性、易实现性、灵活性、易操作性和低成本性等优点。

技术方案：本发明的一种基于网络电视机顶盒的可视电话系统实现方法基于DM6446平台，调用该平台的DSP H.264编解码接口API实现本地视频的压缩编码和网络接收视频的解码显示；基于ARM编写G.711A律的音频编解码；引入多线程技术，并行处理各个功能模块；引入miniGUI库，用于信令管理的显示界面。体系结构：

基于机顶盒的可视电话系统的硬件部分除了机顶盒开发板以外，还需要添置摄像头、麦克风、扬声器(可使用电视机扬声器)，而在开发板的芯片需求上则需要有音视频采集模块，同时应配备有相应的硬件驱动程序，对于显卡模块，则采用机顶盒用于视频处理的Framebuffer，这些在DM6446开发板上都已经集成，我们在开发可视电话系统的时候只需要调用相应的API接口即可，当然这得处理好资源的共享与调度问题，我们将在方法流程里详细介绍。基于IPTV机顶盒的可视电话系统的体系结构如图1所示，从图中我们可以看到基于多线程的多任务调度和控制是软件结构设计的关键，因为在可视电话系统运行的时候，存在着视频采集、编码/解码、显示，音频采集、编码/解码、回放，信令管理，网络通信等多个任务同时并行处理，虽然DM6446平台是ARM+DSP双核结构，但是由于DSP的专用性，在本系统中其仅用于对视频的编码和解码工作进行处理，其余的工作则都有ARM处理，合理的占用CPU，才能提高多任务并行处理的利用率，才能够及时、同步的满足音视频通话的需求。

为了避免两个以上的线程同时访问共享资源而引起冲突，或当两个线程的执行有先后顺序时，合理的占用共享资源，我们借助于Linux Pthread多线程编程技术中的线程同步方案，我们知道Phread线程同步与互斥有四种方法，即是信号量(Semaphore)、事件(Event)、互斥量(Mutex)和临界区(Critical Section)4种。它们分有信号和无信号两种状态。线程使用等待函数阻塞其自身运行，只有当等待函数中指示的同步对象处于信号态时，等待函数才能返回。反之，当同步对象处于无信号态时，禁止等待函数返回。多个线程通过同一个对象，实现相互间的同步。我们采用事件(Event)来同步各线程，例如我们在软件中对视频线程的同步使用了采集缓冲区空(capBufEmpty)、采集缓冲区满(capBufFul1)、接收缓冲区空(recBufEmpty)和接收缓冲区满(recBufFul1)4个事件对象，使各线程同步，可视电话系统中视频的共享资源主要为采集缓冲区和接受缓冲区。主进程调用视频采集模块，将采集来的视频数据，使用DSP编码压缩后，存入采集缓冲区，为了在采集与发送之间留有一定的时间，我们将采集缓冲区设置为循环队列数据结构，当采集缓冲区有数据时，通过发送模块将采集缓冲区的内容发出去，发送完毕后，相应的采集缓冲区指针向前移动，于是采集模块又可以采集新的数据。当采集缓冲队列满时，则阻塞采集模块，当采集缓冲队列空时，则阻塞发送模块；当从网卡接受到数据时，我们将其存入接收缓冲区，当接收缓冲区有数据时，调用DSP解码收到的视频流，将解码后的数据发送给显示模块，然后接收缓冲区读写指针向前移动，接收缓冲区接收新的视频流，接收缓冲区同样采用循环队列数据结构。当接收缓冲队列满时，则丢失接收到的视频数据；当接收缓冲队列空时，则阻塞等待。

对于音频流数据，由于音频数据对实时性要求比较高，并且音频流的运算量比较小，我们编写两个线程来处理音频流，soundEncodeThx和soundDecodeThx，soundEncodeThx线程处理麦克风等设备的初始化，读取音频的原始数据并采用G.711A律算法编码音频数据，然后通过网络发送出去；soundDecodeThx线程处理扬声器等设备的初始化，读取网络发来的数据，采用G.711A律算法解码音频数据，然后驱动扬声器发出语音。

语音和视频编码算法确定后，信源编码对语音和视频信号的损伤成为常量，语音和视频数据流的抖动和数据丢失就成为影响通信质量的关键因素。提高实时通信质量的关键是在保证较小的延时的前提下减小数据流的抖动，故将语音和视频数据流的延时和抖动作为衡量通信质量的标准。如果从某个时间t₀开始语音解码并回放，每个数据包的语音回放时间长度为Δ，那么第i个语音数据包的回放时间，即期望到达时间为t₀+(i-1)×Δ，它的实际到达时间t_i与期望到达时间之差记为

τ_i＝t_i-t₀-(i-1)×Δ，可以选择合适的t₀k可以使得τ₁、τ₂...τ_N均值为0，用τ_i的标准差σ_τ来描述语音数据包的到达抖动。要使τ₁、τ₂...τ_N均值为0，则有

于是τ_i的标准差σ_τ为：

其中N₁为统计的语音帧总数。同理，定义d_i为视频各帧数据实际完整到达时间和期望到达时间的差值，d_i的标准差σ_d来描述视频数据流的抖动特性：

其中N₂为统计的视频帧总数。

方法流程：

基于网络电视机顶盒的可视电话系统实现方法通过对可视电话系统的功能划分，设计多线程并行执行，嵌入式微处理器ARM负责视频采集与显示、语音编解码与音唇同步、数据包的传输与控制、信令控制，数字信号处理器DSP负责视频编解码，完成与网络电视IPTV机顶盒平台的无缝结合；所述方法包含的步骤为：

步骤1.)进行需求分析，对可视电话系统需要完成的功能进行分析，并生成需求分析文档，

步骤2.)按照步骤1的分析文档设计功能模块，生成各个模块之间的逻辑关系和功能说明文档，

步骤3.)按照步骤2的功能说明文档，设计与实现主控制线程模块；主控线程负责创建自定义视频采集线程、自定义视频编解码线程、自定义视频显示线程、自定义音频采集与编码线程、自定义音频解码与回放线程、自定义数据发送与接收线程和自定义信令管理线程，对这些线程按需求分配以不同的优先权，并将其初始化，调用线程阻塞函数阻塞等待各个线程的运行；

步骤4.)按照步骤2的功能说明文档，设计与实现视频采集线程，它负责视频采集设备的初始化、参数设置以及从显卡驱动中获取摄像头采集的原始数据，将其发送给视频编解码线程；

步骤5.)按照步骤2的功能说明文档，设计与实现视频编解码模块视频编解码线程，它负责初始化数字信号处理DSP编解码调用应用程序编程接口API，将视频采集线程发来的原始数据调用DSP编码API，生成H.264视频帧，发送给数据发送与接收线程；将数据发送与接收线程发来的视频压缩标准H.264视频帧调用DSP解码API，生成原始的视频数据，发送给视频显示线程；

步骤6.)按照步骤2的功能说明文档，设计与实现视频显示模块视频显示线程，它负责视频显示设备的初始化，这主要是显卡的初始化和参数设置，将视频编解码线程发来的解码后的视频数据在电视机上显示出来；

步骤7.)按照步骤2的功能说明文档，设计与实现音频的采集与编码线程，它负责音频设备的初始化与参数设置，从设备目录中的DSP目录中采集原始的音频数据，采用语音间隙删除算法优化，然后调用音频编解码协议G.711A律算法编码压缩，将编码压缩后的语音数据发送给数据发送与接收线程；为了音唇同步，在发送给数据发送与接收线程之前，对压缩后的语音数据进行一定的缓冲；

步骤8.)按照步骤2的功能说明文档，设计与实现音频的解码与回放线程，它负责声卡设备的初始化与参数设置，将数据发送与接收线程发来的被呼叫方的语音数据，调用G.711A律解压算法，然后写入设备DSP目录，推动扬声器回放语音；

步骤9.)按照步骤2的功能说明文档，设计与实现网络通信模块数据发送与接收线程，它负责音视频数据的发送与接收、将音视频数据分别打包成实时传输协议RTP包，交由传输层的用户数据报协议UDP负责传输，将超过1400字节大小的视频帧在打包之前拆分，在接收的时候则按照时间戳，将被拆分的视频帧组合；

步骤10.)按照步骤2的功能说明文档，设计与实现信令管理模块信令管理线程，它负责可视电话系统用户界面、呼叫连接、连接管理、呼叫释放功能的实现，UI包括“呼叫”、“地址本”、“系统设置”、“挂机”；呼叫连接遵循呼叫信令协议H.225.0协议实现通话双方的连接，连接管理遵循多媒体通信控制协议H.245协议实现呼叫双方连接参数的协商与管理，呼叫释放遵循H.245协议实现会话结束后的链路拆除与释放。

步骤3.)中，采用多线程并发执行技术，对可视电话系统的功能划分成多个独立的子线程，即是视频采集线程、视频编解码线程、视频显示线程、音频采集与编码线程、音频解码与回放线程、数据发送与接收线程、信令管理线程，按需求给这些线程分别分配不同的优先级。

在步骤5)中，将视频的编解码工作交由DSP完成，而由于DSP使用的独占性，将其余的工作，包括视频的采集与显示、音频的采集、编码与解码、回放；网络通信、信令管理交由ARM完成，这有效地减轻了ARM的运算量，使得系统CPU的负载得到了极大地降低，并能够支持较高清晰度的视频压缩标准H.264。

有益效果：本发明提出了一种基于网络电视机顶盒的可视电话系统的实现方案，通过对可视电话系统的功能与需求进行详细的划分，采用模块化设计，提出并实现了本系统。技术的关键点是不仅满足了在机顶盒上实现可视电话功能的各项功能需求，还具有遵循标准化原则、音唇同步、清晰度可调、延迟小、丢包率低等特性。下面我们给出具体说明：

完善的功能：通过对可视电话系统的功能与需求的划分，我们将其划分成视频采集模块、视频编解码模块、视频显示模块、音频采集与编码模块、音频解码与回放模块、数据发送与接收模块、信令管理模块。按照合理分配和使用资源，提高CPU的利用率原则，采用多线程并行处理方式，对各个模块分别设计成线程模式，并分配以不同的优先级。由于本系统是基于IPTV机顶盒，所以我们充分利用了机顶盒平台已有的软硬件资源，比如该平台的H.264编解码库，采用DSP完成视频的编解码运算，在提高视频的清晰度情况下，有效地减少了ARM的运算量。

模块化设计：如前所述，按照功能需求将可视电话系统分成数个模块，模块之间分工明确，耦合性低，可复用性高，便于系统的升级和扩展。各个模块由独立的线程实现，线程之间采用事件(Event)机制实现同步与互斥。

良好的系统扩展性：由于系统是按照H.323标准实现的，因此具有标准化实现的一般好处。系统模块之间采用的是一种松耦合的设计，可以方便的添加新的功能。比如我们对语音编解码算法，除了G.711之外，还可以采用H.323标准支持的G.729、G.723.1算法，让系统遵循H.245协议，在连接控制的时候自动协商通话时的语音编解码算法。

高度的可靠性和稳定性：通过对可视电话系统的单元测试、与机顶盒系统集成后的系统测试表明该套系统运行状况良好，占用系统资源少，拥有良好的容错机制，能够根据网络状况动态调整编码帧的清晰度，适应不同级别网络速度。具有延迟小、丢包率低、音唇同步等优点。

附图说明

图1是可视电话系统的软硬件框图。在软件部分，采用多线程技术，并行处理各个任务，对每个任务编写独立的子线程。从图中我们可以看到可视电话系统分为七个模块，分别是：视频采集模块、视频编解码模块、视频显示模块、音频采集与编码模块、音频解码与回放模块、信令管理模块、网络通信模块；在硬件部分，除了机顶盒开发平台以为，我们还需要添置麦克风和摄像头设备，负责音频和视频的采集。

图2是可视电话系统在机顶盒中的工作流程。由图我们可以清晰地了解可视电话从响应红外线遥控事件，中断电视任务开始，到设备的初始化、音视频的采集、同步、网络发送以及根据网络的参数而对发送视频清晰度的调整等。

图3是可视电话系统中视频数据在内存中的流通，包括视频数据的发送和接收。由于可视电话系统里最主要部分是视频数据的发送与接收，我们这里主要强调循环缓冲队列数据结构的使用以及基于Event事件的线程互斥与同步机制。

图4是RTP打包与拆包的流程图。将数据采用RTP传送，是H.323标准的要求，同时采用RTP发送还可以基于RTCP对网络进行侦测，动态地调整视频数据的清晰度，保证服务质量。从图中我们可以看到在发送端，对大于1400字节的MPEG-4视频帧拆分打包发送。在接收端对于相同时间戳的RTP包合并接收。

具体实施方式

该部分详细说明发明内容各个模块的设计与实现，以及可视电话在机顶盒中的工作流程，如图2所示。

(1)主控线程模块

在IPTV机顶盒设备上，由于嵌入式平台运算的限制性，多种媒体业务并发时，各个线程之间将竞争有限的CPU资源。当线程得不到它所需要的CPU资源时，数据的处理将会被延误，从而加剧数据流的抖动。对于实时性要求高的业务，过长的延时和不连贯的音视频质量是无法容忍的。因此，如何合理地调度各个线程以高效率地利用CPU资源成为系统任务调度策略的研究重点。在本系统中，主控线程即是负责管理可视电话系统多个任务线程的分配与调度。它负责创建视频采集线程videoCaptureThx、视频编解码线程videoEndecodeThx、视频显示线程videoDisplayThx、音频采集与编码线程soundEncodeThx、音频解码与回放线程soundDecodeThx、数据发送与接收线程dataTranRecThx、信令管理线程signalManageThx。为了合理的占用CPU资源，使用sched_get_priority_max函数分配以不同的优先级，将videoCaptureThx、videoEndecodeThx、soundEncodeThx、dataTranRevThx设置为最高优先级，将videoDisplayThx、soundDecodeThx、signalManageThx线程置为次高优先级，最后将主线程置为控制线程，初始化所有系统资源，包括线程初始化、DSP资源调用初始化等，然后同步互斥所有线程。调用phtread_join函数阻塞等待各个线程的执行，当子线程返回时，主线程负责相应的清理工作。

(2)视频采集模块的实现

视频采集模块的主要工作就是videoCaptureThx线程的实现，而videoCaptureThx的主要功能就是TVP5146采集卡的初始化、视频数据的采集、采集卡的关闭三个部分。TVP5146采集卡的初始化使用initCaptureDevice函数实现，在该函数中，调用采集卡的驱动函数库V4L2执行open函数打开硬件设备/dev/video0、执行ioctl函数对硬件的参数设置(ioctl是设备驱动程序中对设备的I/O通道进行管理的函数)、分配存放视频捕获数据的缓冲队列，返回打开的文件描述符；采集卡的关闭使用cleanupCaptureDevice函数实现，调用ioctl函数、close函数关闭硬件，同时需要清理存放视频捕获数据的缓冲队列；然后编写videoCaptureThx函数，在该函数中首先调用initCaptureDevice函数初始化设备，从设备中读取视频帧，填充到刚才分配的缓冲队列中，然后将这些数据发送给videoEndecodeThx线程执行视频编码压缩工作。循环执行视频采集工作，直到执行完毕，调用cleanupCaptureDevice函数关闭设备。

(3)视频编解码模块的实现

视频编解码模块的主要工作就是videoEndecodeThx线程的实现，

videoEndecodeThx线程的包括两个主要部分，即是视频编码encodeVideoBuffer函数和视频解码decodeVideoBuffer函数。encodeVideobuffer将videoCaptureThx线程发来的原始视频帧编码压缩成H.264视频帧，存放到输出缓冲区中；decodeVideobuffer将从网络接收缓冲队列中取得的H.264视频帧解压成原始的视频帧，发送给显示videoDisplayThx线程。videoEnDecodeThx线程首先打开DSP引擎，使用videoEncodeAlgCreate函数创建DSP编码引擎，设置DSP编码的环境参数，包括编码算法、图像的大小、高宽、比特率等；使用videoDecodeAlgCreate函数创建DSP解码引擎，设置DSP解码的环境参数等。然后分配编码缓冲队列encodeBuffers[bufIdx]与videoCaptureThx线程交互，将编码后的H.264视频帧存入到编码缓冲区中，调用dataTranRevThx线程发送出去；分配解码缓冲队列encodeBuffers[bufIdx]与videoDisplayThx线程交互，将解码后的视频数据存入到解码缓冲区中，调用videoDisplayThx线程回放显示。

(4)视频显示模块的实现

视频显示模块的主要工作是将videoEndecodeThx线程解码的视频数据在电视机上显示，由videoDisplayThx线程负责实现。videoDisplayThx线程的主要功能就是显示卡的初始化、视频数据的显示、显示卡的关闭三个部分。显卡的初始化工作由initDisplayDevice函数实现，在该函数中，首先调用open函数打开/dev/fb/3显卡设备(/dev/fb/0负责OSD层显示、/dev/fb/2负责Framebuffer的属性设置)，然后使用ioctl函数设置显示图像的高、宽、分辨率等，然后使用mmap函数将显卡的缓存映射到用户空间；cleanupDisplayDevice函数负责关闭显卡设备，执行初始化的逆顺序，使用ioctl清除设置、munmap函数解除映射关系、close函数关闭设备。该模块的主要工作由videoDisplayThx函数负责实现，在该函数中，首先调用initDisplayDevice函数初始化设备，然后读取videoEndecodeThx线程解码后的视频帧数据，将其写入到显卡中，在电视机上显示。循环执行视频数据显示操作，待执行完毕后，调用cleanupDisplayDevice函数关闭设备。视频数据的收发流图，如图3所示，在图中，最主要的部分是循环缓冲队列数据结构的使用，以及线程之间互斥与同步的事件机制的使用。

(5)音频采集与编码模块

音频采集与编码模块包括音频采集模块、音频编码模块，其主要工作由soundEncodeThx线程完成，这包含音频采集卡AIC32的初始化，由initSoundDevice函数完成；立体声转换为单声道，由stereoToMono函数完成；音频数据的编码压缩，由encodeSpeechBuffer函数完成。在initSoundDevice函数中，需要使用open函数打开/dev/mixer、/dev/dsp两个设备，混频器/dev/mixer负责访问声卡中内置的mixer，调整音量大小，选择音源(麦克风输入或者线性输入)等，设置好后调用close关闭混频器；/dev/dsp，读这个设备就相当于录音，写这个设备就相当于放音，此时我们需要对其进行读操作(以只读方式O_RDONLY打开)，使用ioctl函数，设置/dev/dsp的采样格式(仅支持AFMT_S16_LE)、声道的数量、采样速率。encodeSpeechBuffer函数负责对采集来的原始数据(raw buffer)采用G.711A律算法编码压缩。然后编写soundEncodeThx函数，在该函数中，首先调用initSoundDevice函数初始化声卡采集设备，然后定义循环，在循环中，不断的读取声卡采集来的数据，调用silencesuppression算法，对采集到的数据静音检测，将有效的数据采用stereoToMono转换，然后使用encodeSpeechBuffer函数编码压缩原始数据为G.711A律制式的数据，将压缩后的数据，存入到输出缓冲区，为了使音唇同步，我们将音频数据缓冲至1/2个CIF视频帧的大小(CIF是常用的标准化图像格式(Common Intermediate Format)。在H.323协议簇中，规定了视频采集设备的标准采集分辨率。PAL制式的CIF＝352×288像素)，然后调用dataTranRevThx线程，由这个线程负责发送出去。

(6)音频解码与回放模块

音频解码与回放模块包括音频解码模块、音频回放模块，其主要工作由soundDecodeThx线程完成，这包括扬声器的初始化，由initSoundDevice函数完成；单声道转换为立体声，由monoToStereo函数完成；音频数据的解压缩，由decodeSpeechBuffer函数完成。在在initSoundDevice函数中，首先使用open函数打开/dev/mixer设备，此时仅需要使用ioctl函数设置混频器mixer的音量大小，设置好后调用close关闭；然后调用open函数以只写方式O_WRONLY打开/dev/dsp，使用ioctl函数，设置/dev/dsp的采样格式(仅支持AFMT_S16_LE)、声道的数量、采样速率。decodeSpeechBuffer函数将从网络接收来的G.711A律编码压缩的音频数据采用G.711A律算法解压。然后编写soundDecodeThx函数，在该函数中，首先调用initSoundDevice函数初始化声卡采集设备，然后定义循环，在循环中，将dataTranRevThx线程发来的数据调用decodeSpeechBuffer解压缩，将解压后的数据输出到缓冲区，然后将缓冲后的数据发送给声卡驱动，驱动扬声器回放声音。

(7)网络传输模块

根据H.323标准，在网络传输中使用RTP协议(Real-time Transport Protocol，实时传输协议)可以设定H.264的码流速率，清晰度也可在一定的范围内作相应的变化，这样便于用户根据自己对传输带宽和清晰度的不同要求进行不同的设置。由于在网络带宽比较小的时候，数据丢帧现象比较严重，这对图像质量有很大的影响。我们采用拆帧再发送的方法，来降低丢帧率。当接收端接收到数据后，把属于同一视频帧的数据组合起来。目前常用的以太网的MTU(最大传输单元)为1500字节，因此设置RTP包的有效负载上限为1400字节，我们知道RTP协议报头大小为固定的12字节，所以RTP包的大小为12字节-1412字节，这样就保证了RTP包在网络中传输尽可能的不被拆开，如图4所示。

我们基于JRTPLIB函数库，编写dataTranRevThx线程负责RTP包的发送与接收，使用RTPSession类的方法SendPacket函数创建dataSoundTran和dataVideoTran函数，分别负责将RTP打包后的音频和视频数据发送出去；从RTPSession类派生的自定义类dataRTPSession实现RTPSession的虚函数OnPollThreadStep，在该函数中循环调用函数GetNextPacket来接收RTP数据包，然后使用ProcessRTPPacket函数处理接收到的每一个RTP包，在ProcessRTPPacket函数中，先判断接收到的是视频数据还是音频数据，如果是视频数据，根据时间戳从所接收的数据包中提取H.264视频帧，将具有相同时间戳的RTP数据包中的负载数据提取出来合并还原成打包之前的H.264视频帧，发送给videoEndecodeThx线程。如果是音频数据，则将其发送给soundDecodeThx线程；创建dataRTCPMonitor函数，负责调解RTP包的发送，通过RTCPScheduler类的相关函数实现；获取RTCP(RTP Control Protocol)包的信息，通过RTCPRRPacket类的相关函数实现。

(8)信令管理模块

信令管理模块主要由signalManageThx线程负责主要工作，signalManageThx线程包括用户界面UI的实现，用于呼叫控制的H.225.0协议和用于媒体信道控制的H.245协议的实现，分别是dataVoipUI函数、dataCallCtrl函数和dataConnectCtrl函数。dataVoipUI函数主要是基于miniGUI函数库编写可视化的用户界面，修改并实现基于红外遥控的输入引擎，完成包括“呼叫”、“地址本”、“系统设置”、“挂机”。“呼叫”主要完成呼叫功能，通过在输入框内填入IP地址或在网守注册的id号来完成呼叫，也可以通过“地址本”中完成呼叫。“地址本”实现用户电话本功能，方便用户的记录、查询、删除以及快速呼叫。系统设置可以根据用户的要求完成基本的设置功能，包括“用户设置”“，IP设置”等；dataCallCtrl负责完成符合H.225.0协议的呼叫控制功能；dataConnectCtrl负责完成符合H.245协议的连接控制功能。然后编写signalManageThx函数，在该函数中，首先调用dataVoipUI函数完成可视电话界面的显示，按照用户的拨号选择，调用dataCallCtrl函数，根据公认的端口号建立起TCP连接，即可靠的呼叫信道。然后在此呼叫信道上发送H.225.0呼叫信令消息，直至建立起另外一条TCP信道——H.245控制信道，呼叫控制过程结束，连接控制过程开始。连接控制过程由H.245协议完成，连接控制最重要的过程为能力交换过程。建立后即开始音视频通话，signalManageThx线程转为后台运行。当通话的任意一方触发呼叫释放以后，发起终端首先停止在逻辑信道上传送信息，关闭所有逻辑信道。然后通过H.245控制信道向对方终端发送“结束会话”命令。对方终端接到上述消息之后，关闭所有逻辑信道，向发起终端回送“结束会话”命令消息。至此，整个通话过程结束。

在机顶盒端先启动可视电话系统的主进程，这个进程作为一个守护进程循环等待呼叫请求事件的到来，或者等待用户本身激活事件。在可视电话系统的UI界面上填写IP或名称，拨打网络电话，然后网络通信线程dataTranRevThx负责与被呼叫方进行呼叫连接，建立后，转入连接控制，协商音视频会话，或只是音频会话。待有一方触发会话结束事件，该线程再负责呼叫释放。具体实现方式如下：

1视频通话部分

视频通话部分包括视频数据的采集videoCaptureThx线程、视频数据的编解码videoEndecodeThx线程、视频数据的显示videoDisplayThx线程服务器进程、视频数据的发送与接收dataTranRevThx线程。当用户在连接管理dataConnectCtrl函数中协商执行视频通话，则激活videoCaptureThx、videoEndecodeThx、videoDisplayThx线程，videoCaptureThx线程负责采集原始的视频数据(raw data)，发送给videoEndecodeThx线程的编码压缩函数，videoEndecodeThx将编码压缩后的H.264视频帧发送给dataTranRevThx线程，由它发送给被呼叫方；同时，dataTranRevThx线程接收被呼叫方的H.264视频帧，将其发给videoEndecodeThx线程的解码函数，待解码后，发给videoDisplayThx线程，videoDisplayThx负责视频数据的显示。

2音频通话部分

音频通话部分包括音频数据的采集与编码soundEncodeThx线程、音频数据的解码与回放soundDecodeThx线程、音频数据的发送与接收dataTranRevThx线程。当用户在连接管理dataConnectCtrl函数中协商执行音频通话，则激活soundEncodeThx、soundDecodeThx线程，soundEncodeThx线程负责初始化麦克风设备，采集音频数据，对数据采用G.711A律编码压缩，发送给dataTranRevThx线程，由它发送给被呼叫方；同时，将dataTranRevThx线程接收到的被呼叫方的语音数据发送给soundDecodeThx线程，由它负责解码，并驱动扬声器回放语音数据。

3网络通信部分

网络通信dataTranRevThx线程包括语音数据的发送与接收、视频数据的发送与接收，这些主要是基于JRTPLIB函数库实现。按照H.323标准，将语音和视频数据分别采用RTP打包后，交由传输层UDP(UserDatagram Protocol，用户数据包协议)处理。同时还要处理RTCP数据，以检测网络状况和调节视频发送的清晰度。

4信令管理部分

信令管理signalManageThx线程包括UI界面、呼叫连接、连接管理、呼叫释放等模块。UI界面基于miniGUI函数库，实现可视电话的用户界面，包括“呼叫”、“地址本”、“系统设置”、“挂机”。用户可以用遥控器选择“呼叫”后，填写IP地址或用户名，也可以在“地址本”里选择需要呼叫的目的地址，当呼叫事件触发后，调用dataCallCtrl函数负责呼叫连接，调用dataConnectionCtl函数负责连接管理，然后将ARM控制权交给videoCaptureThx、videoEndecodeThx、videoDisplayThx、soundEncodeThx、soundDecodeThx等线程，通话结束后，signalManageThx线程调用dataReleaseCtl函数负责呼叫释放，这些分别遵循H.323标准的H.225.0和H.245协议。

Claims

1.一种基于网络电视机顶盒的可视电话系统实现方法，其特征在于通过对可视电话系统的功能划分，设计多线程并行执行，嵌入式微处理器ARM负责视频采集与显示、语音编解码与音唇同步、数据包的传输与控制、信令控制，数字信号处理器DSP负责视频编解码，完成与网络电视IPTV机顶盒平台的无缝结合；所述方法包含的步骤为：

2.根据权利要求1所述的一种基于网络电视机顶盒的可视电话系统的实现方法，其特征在于步骤3.)中，采用多线程并发执行技术，对可视电话系统的功能划分成多个独立的子线程，即是视频采集线程、视频编解码线程、视频显示线程、音频采集与编码线程、音频解码与回放线程、数据发送与接收线程、信令管理线程，按需求给这些线程分别分配不同的优先级。

3.根据权利要求1所述的一种基于网络电视机顶盒的可视电话系统的实现方法，其特征在于在步骤5)中，将视频的编解码工作交由DSP完成，而由于DSP使用的独占性，将其余的工作，包括视频的采集与显示、音频的采集、编码与解码、回放；网络通信、信令管理交由ARM完成，这有效地减轻了ARM的运算量，使得系统CPU的负载得到了极大地降低，并能够支持较高清晰度的视频压缩标准H.264。