机顶盒和计算机之间跨平台可视电话系统的实现方法 【技术领域】
本发明是一种在PC(Personal Computer)机和机顶盒(Set Top Box)之间进行音视频聊天的可视电话系统，音频采用G.711编码算法，视频采用H.264编码算法，使用基于UDP(User Datagram Protocol)的socket来实现跨平台的数据通信，属于嵌入式系统和流媒体技术的交叉领域。
背景技术
可视电话业务是通过传统电话网、互联网或视讯专网的形式，对称、实时地实现语音、图像、数据等信息交流的多媒体通信业务。可视电话虽然已经出现了好几年，但是由于价格、性能等因素的影响，并未获得广泛的应用。但是近年来，随着图像编码技术的发展和宽带IP(Internet Protocol)网络的日益普及，可视电话技术越来越引起人们的关注，尤其是基于IP的可视电话，以其优良的影音品质和强大的功能，吸引了广大的消费者，倍受人们关注。
另一方面IP宽带网和宽带接入网的迅速发展，使得用户接入的速率不断提升，新的信息家电如机顶盒也得到了越来越广泛的应用。机顶盒是扩展电视机功能的一种新型家电，实质上IP机顶盒相当于一台自带嵌入式操作系统的计算机，它采用以太网接入，可将通过网络传输过来的流媒体数据转换成模拟音频和视频输出至电视。它具备了计算机的数据交换等基本功能，采用遥控器直接操作。如果分别将PC机和机顶盒作为视频聊天的终端，用户就可以通过自己的笔记本等个人电脑随时随地的与安装了机顶盒的家庭进行音视频通信，非常方便、快捷。
目前，国际上已投入使用的可视电话或会议电视系统有Microsoft的NetMeeting，3Com公司的Big Picture，国内有中兴ZXMVC系列和华为View Point系列可视产品。但是目前使用的可视电话基本上是基于PC的软件，通过IP的网络服务提供图像电话。这种解决方案中，进行通信的双方用户都要有电脑、宽带上网和一定的电脑操作知识等基本条件，因而在一定程度上局限了其拥有的用户群体。如果能实现个人计算机与机顶盒之间进行视频聊天，将可视电话作为数字电视的一个附加功能提供给用户，对数字电视的运营内容和增加机顶盒的功能都起到了一个积极地帮助，具有良好的市场前景。
本设计方案中使用的机顶盒是达芬奇数字平台(DaVinci)TMS320DM6446。TMS320DM6446是TI公司新提供的面向视频开发领域的平台，拥有ARM(AdvancedRISC Machines)和DSP(Digital Signal Processor)双CPU(Central Processing Unit)内核的高端嵌入式开发平台，主频高达720MHZ。该平台上拥有丰富的硬件接口如USB(Universal Serial Bus)、网卡、硬盘接口等等，因此可以在该平台上开发具有视频聊天功能的IP机顶盒。
【发明内容】
技术问题：本发明的目的是提供一种机顶盒和计算机之间跨平台可视电话系统的实现方法，在机顶盒和PC机之间进行可视聊天，实现远距离的面对面沟通，需要解决跨平台的数据交换、两个平台下的音视频编解码并使系统具有良好的实时性等问题，较之当前市场上流行的PC之间的可视电话软件而言，该系统具有新颖性、灵巧性、易扩展性和通用性等特点，具有很好的市场前景。
技术方案：本发明的方法采用了基于UDP协议的socket来实现跨平台的通信，在音视频编解码标准方面，采用了本机顶盒支持的G.711的音频编码算法和H.264的视频编码算法，并采用了多线程的设计，这样可以很好地保证系统对实时性的要求。该系统包括了音视频输入、音视频压缩、跨平台网络传输、音视频输出、和用户界面等部分。
该可视电话系统的实现步骤为：
步骤1).进行需求分析，对跨平台可视电话系统需要完成的功能进行分析，并生成需求分析文档，
步骤2).按照步骤1)地分析文档设计模块，生成各个模块之间的逻辑关系和功能说明文档，
步骤3).按照步骤2)的功能说明文档，设计用户界面，主界面上包括呼叫、挂断、通信录、设置四个按钮以及显示对方视频的窗口，
步骤4).确定音视频的编码标准并提供编解码函数的接口，采用G.711的音频编码算法和H.264的视频编码算法，在计算机平台下需要两种编码算法的函数库，然后找出编解码的函数接口提供给音视频线程，在机顶盒平台下，编码算法已经封装在了编/解码服务器中，编解码的函数接口可以从机顶盒本身的说明文档中获得，
步骤5).设计数据包结构：数据包的结构主要包括标志位flag和数据部分，命令包和音视频数据包主要是根据flag标志来区分，而且命令包比较特殊，它还必须有一个type位，type＝0代表着首次发送该命令，当接收方收到之后，会将type位置1，代表着对这个命令的确认，
步骤6).按照步骤2)的文档，实现网络通信模块，传输采用了用户数据报协议，并提供套接字的接口函数给音视频线程使用，在接收数据包时根据步骤5)中数据包的flag标志判断出是音频、视频或是命令数据包，然后再分别对其中的数据进行处理，
步骤7).按照步骤2)的文档，设计与实现可视电话系统的主线程，在主线程中进行初始化工作，并实现用户界面上各个按钮的功能，在机顶盒平台中的主线程最后转换为控制线程，控制用户通过遥控器输入的终端指令，然后调用步骤6)的网络通信接口发送给对方来实现双方的命令交互，
步骤8).按照步骤2)的文档，设计与实现与音频相关的线程来实现声音的获取、编码、解码和播放。计算机平台下调用应用程序编程接口来实现每个音频线程的功能，而机顶盒平台下各个音频线程的实现参考了机顶盒自身提供的示例程序；首先在音频输入线程中打开各种需要的音频设备，当采集到音频数据后先调用步骤4)提供的编码函数对原始音频数据进行编码，再调用步骤6)提供的网络通信函数接口将编码数据打包发送给对方，在音频输出线程中先对收到的数据进行解码，然后将解码后的数据写入到音频输出设备，
步骤9).按照步骤2)的文档，设计与实现与视频相关的线程来实现图像的获取、编码、解码和显示，实现过程与步骤8)类似，首先初始化视频捕捉设备，每采集一帧视频后调用步骤4)提供的编码函数对其进行编码，再调用步骤6)提供的网络通信函数接口将编码数据打包发送给对方，当对方接收到视频数据包后，对其进行解码，然后将解码后的数据发送到视频显示窗口进行显示，
步骤10).将步骤6)、步骤7)、步骤8)、步骤9)实现的功能分别作为单独的功能模块添加到工程中，计算机平台下编译、链接之后，运行程序；在机顶盒平台下进行交叉编译后，在机顶盒开发板上运行。
有益效果：使用该方案有如下优点：
1、良好的实时性：可视电话系统具有较高的实时性要求。实时性是要求系统能够在规定的时间内对外部事件给予响应。因此，为了提高本系统的实时性，我们采用了基于UDP的socket传输，因为视频电话系统中要求源主机以恒定的速率发送数据，并且允许在网络发生拥塞时丢失一些数据，但却不允许数据有太大的时延，UDP协议非常适合这种实时性应用的需要。此外，整个系统还采用了多线程的设计，音频的输入、压缩传输以及数据包的接收等都有单独的线程来处理，这样可以很好地保证系统对通信的及时响应。
2、高度的稳定性：因为机顶盒中安装的是嵌入式系统。嵌入式实时系统同时运行大量任务，不能保证系统永不出现问题，但通信任务不能受嵌入式设备本身任务的影响。因此，在设计中，把通信任务和实际的检测控制任务分离开了，用一个专门的任务处理通信事件，同时设立一个缓冲区保证通信数据能够被及时保存，因此系统具有很好的稳定性。
3、较强的通用性：嵌入式实时操作系统种类繁多，目前尚无一种操作系统在嵌入式领域占绝对优势。而socket通信具有与平台无关的特性，因此可以使得本嵌入式设备的跨平台通信能够适用于各种常见的实时操作系统。
4、良好的系统扩展性：由于系统模块之间采用的是独立模块化，功能并行层次化设计，系统模块之间的通信机制完全采用层次化的结构，因此可以方便的添加新的功能，也可以很容易的升级现有的功能。
5、美观易操作的人机界面：该系统采用了人性化设计，并且对界面进行了美化。PC端的界面美观、操作简单而且功能强大，机顶盒端使用遥控器操作，方便快捷，反应速度灵敏，使用遥控器按键可以实现IP地址的输入、呼叫等功能，具有较高的市场推广潜质和商业应用价值。
【附图说明】
图1是可视电话系统的整体流程图，
图2是PC端详细的程序流程图。
图3是机顶盒端的线程交互图。
图4是与视频有关的四个线程之间的交互过程。
图5描述了通信双方的连接建立过程。
【具体实施方式】
图1是可视电话系统的整体流程图。首先打开音视频设备，然后从设备中采集原始音视频数据，经过压缩编码后，封装成数据包发送出去，数据接收的过程与之大致相反，将接收到的数据解码后，分别进行音频的输出和视频的显示。
图2是PC端详细的程序流程图。首先要初始化音视频的编解码器并打开各种音视频的设备。然后对于音频而言，先创建与音频有关的线程(音频输入、输出等线程)并为录音分配好缓冲区。录音开始后，每采集一帧就调用编码函数进行压缩编码，然后发送出去。对于视频而言，采集到的视频帧存放在一个结构体中，然后在回调函数中对其进行压缩传送。Socket线程负责接收数据，根据数据包的标志判断出是命令包、音频数据包还是视频数据包，并分别对其进行相关的处理。
图3是机顶盒端的线程交互图。在机顶盒端用到的线程比较多，有主线程、控制线程、视频捕获线程、视频压缩传送线程、视频解码线程、视频显示线程、音频输入线程、音频输出线程、音频压缩传送线程和负责接收数据的socket线程。后面这些线程是在主线程成为控制线程之前由主线程创建的。
图4是与视频有关的四个线程之间的交互过程。主要是视频捕获线程和压缩传送线程之间、视频解码线程和显示线程之间的数据交互。
图5描述了通信双方的连接建立过程。连接的建立是通过一些命令的发送和确认实现的。每一个命令包中都有一个type标志位，type＝0代表着首次发送该命令，当接收方收到该命令之后，会将type位置1，代表着对这个命令的确认。当双方建立了连接后，就可以开始进行可视聊天了。
一、体系结构：
整个可视电话系统的组成包括音频输入、音频输出、视频输入、视频输出、音频编解码、视频编解码、用户界面和网络传输。网络传输部分是连接两个不同平台——PC机和机顶盒的桥梁，选择基于UDP的socket传输，并建立了两组socket，一组保证指令发送和接收的可靠传输，另一组提供音视频数据的不保证可靠地传送和接收。除了网络传输部分涉及到了两个终端，并需要进行交互之外，其余部分都是独立得分别处于PC端和机顶盒端之中。图1给出了系统的整体流程图。
虽然在PC端和机顶盒端都分为以上几个部分，但是在具体实现时略有不同。例如在音视频的采集和处理方面，Windows下有专门的API函数直接实现这些功能。在本机顶盒的嵌入式系统下，我们可以参考其自带的DEMO程序来完成这些功能。在网络通信方面，虽然都使用socket编程，但是一些函数和类型定义上也略有不同。此外，在Windows下，使用MFC可以方便地实现美观的用户界面，但是在机顶盒端，我们需要创建显示线程来实现图像等的显示并创建控制线程实现通信时的一些控制功能。
二、方法流程
该部分详细说明发明内容中各个部分的设计与实现，我们将网络传输作为单独的部分进行介绍，其它部分因为在PC端和机顶盒端实现上存在差别，所以分别进行介绍：
●PC机端
在PC端需要创建六个线程，分别为：主线程、音频输入线程、音频输出线程、音频压缩传送线程、视频压缩传送线程以及负责接收数据的socket线程。在次只为音频创建了独立的输入和输出线程，而没有为视频创建，这是考虑到音频的采样率为8000Hz，而视频仅为20左右，音频比视频的采样率高很多，所以从宏观上我们可以认为，音频是连续的，而视频是非连续的，这也就是无须为视频输入输出创建独立线程的原因。PC端的程序流程图如图2所示。
音频输入部分
可视电话系统中，需要直接对音频数据流进行处理，在WINDOWS下使用以waveIn开头的这组API就可以完成连续的录音功能。首先调用waveInOpen()来打开各种需要的音频设备，此时需要在该函数中指定一个回调函数，其作用是在一个数据缓冲区被录满后被调用，以对这些数据进行处理。初始化音频输入后，创建一个音频输入线程，该线程的作用是当缓冲区中有音频数据时，就从缓冲中取出一帧音频进行压缩编码。然后初始化音频数据块结构各成员变量，主要是将每个缓冲区指针赋给对应数据块结构WAVEHDR中的缓冲区指针变量lpData，这样当一个缓冲区填满后，通过消息机制就可以在消息函数中进行处理，调用waveInPrepareHeader()为一个即将在waveInAddBuffer()中调用的输入缓冲区准备头部，之后就调用waveInAddBuffer()添加一个输入用的数据缓冲区，并将缓冲区赋给输入设备驱动程序，通常会为录音分配一组缓冲区(例如分配10个缓冲区)，因为已经将分配的多个缓冲区和数据块结构赋给了音频设备驱动程序，至于把那个缓冲区填满，然后把哪个空缓冲区再赋给设备，是完全由Windows控制的。做好这些准备之后，就可以使用waveInStart()开始录音了。每当有采样数据填满数据块后，设备驱动程序就会发消息MM_WIM_DATA给用户窗口，相应的消息回调函数OnMmWimData()对数据块中的采样数据进行处理。当一个音频数据块播放完毕，设备驱动程序又会发出消息MM_WOM_DONE，相应的消息回调函数OnMmWomDone()记录音频数据并经必要准备后重新发送给输入设备，以准备接收后续的采样数据。这样，最初为输入设备准备的音频数据块就在消息的控制下循环使用，无需人为控制就可以实现实时音频数据的采集和处理。
当通话结束后要关闭音频输入设备，最好在waveInClose()之前调用一下waveInReset()，这样可以清掉尚在等待录音的缓冲区，然后再关闭各种设备。
音频输出部分
音频输出部分相对简单一点，使用以waveOut开头的这组API。首先调用waveOutOpen()来打开音频输出设备。我们同样为音频输出创建了单独的线程，即音频输出线程。当接收端接收到音频数据包时，会将其加入到音频输出线程的消息队列中，而该线程通过调用GetMessage来取得消息并对其进行处理(解码音频数据)。为了避免延迟过长，当累积的缓冲超过六块时将抛弃即将加入的数据包。当一块数据解码完成之后就对其进行播放，播放时我们将为解码后的音频数据重新分配一块内存(播放结束后将该内存释放)，将PCM音频数据以波形动态地显示出来。同音频的输入相似，函数waveOutPrepareHeader()和waveOutWrite()也是必需的。waveOutWrite()是填入输出缓冲区，为了避免间断，也应该保证某一时刻缓冲区队列中数目足够。
同音频输入一样，当通话结束后要调用waveOutClose()关闭音频输出设备。
视频输入部分
在视频电话系统中，视频的采样率很低，所以我们没有为视频创建单独的输入和输出线程。在视频输入方面使用数字视频软件包，通过cap函数族实现对视频进行捕获的。首先调用capCreateCaptureWindow()函数来创建视频预览窗口并设置视频捕捉参数，然后初始化视频捕捉设备InitCap()。在InitCap()函数中，函数capSetCallbackOnVideoStream(hCap，VideoStreamCallbackProc)设置了视频流回调函数，参数中的VideoStreamCallbackProc是回调函数。这个设置函数的作用是当采集视频发生时(调用capCaptureSequenceNoFile()捕获视频流)，每采集一帧之后都会调用回调函数，在回调函数里对每一帧图像进行处理。
回调函数的第二个参数lpVHdr是个VIDEOHDR的指针变量，lpVHdr-＞lpData就指向了原始的未经任何加工的图像数据。可以在该函数里对视频数据进行压缩处理，然后发送出去。当通信结束后，要断开与驱动程序的连接。
视频输出部分
视频输出部分相对简单，不过也是通过cap函数族实现视频输出。当接收端接收到视频数据包后，就直接对其进行解码，然后将数据发送到视频显示窗口进行显示，这样就可以看到对方的图像了。同视频输入一样，当通信结束之后，也要断开与驱动程序的连接。
●机顶盒端
开发机顶盒端的可视聊天功能，可以参考达芬奇数字平台本身提供的DEMO，程序中需要的算法实现了xDM接口并且封装在了编/译码服务器中，它们在DM6446DSP内核中执行。采集到的音视频数据利用编解码器和相关算法进行编码，然后发送给对方，同样接收到了数据也要利用编解码器和相关算法进行解码，然后分别进行播放和显示。图3描述了机顶盒端线程之间的交互。
主线程和控制线程的实现
主线程的流程比较简单，作用是进行一些初始化工作，设置好显示的对话框窗口，允许用户用遥控器输入对方的IP地址进行呼叫。当接受了对方的呼叫请求后，就立刻创建图xc中所示的线程，当全部线程被创建后，将调用控制线程的主函数ctrlThrFxn()，这样主线程将会成为控制线程。
控制线程主要负责用户界面，它使用msp430lib库去轮询控制IR接口的msp430处理器，查看是否有IR命令输入。一旦接收到一个新的IR命令，命令就能够被识别并且响应的动作会在keyAction中执行。例如在视频聊天的过程中，我想停止通话，那么可以按下遥控器的“停止”键，当控制线程识别出这个命令后，就进行相应的响应动作(例如释放内存、关闭音视频的设备以及销毁线程等)。
音频输入线程
音频输入线程的作用是从AIC33设备驱动中不断地读取采样的音频数据，将数据放到已经分配好的缓冲区中，具体步骤为：
(1)初始化AIC33声音设备驱动。首先配置声音设备(/dev/dsp)，AIC33声音设备驱动目前只支持2个信道、16位小字节序的样本，同时设置相关参数。因为音频算法使用8KHz的取样率，AIC33也设置成这个取样率。
(2)为原始的立体声(stereo)采样数据分配缓冲区，因为这个缓冲区不会涉及到DSP(stereo-to-mono的转换是由ARM实现的)，所以此处分配的缓冲区不要求一定是连续的，使用malloc()函数就可以了。
(3)调用read()函数不断从AIC33音频设备驱动中读取stereo采样数据，因为AIC33设备只支持立体声，因此要从两个信道上进行采样并放入输入缓冲区中。
音频压缩传送线程
该线程的作用是从缓冲区中读取一帧音频数据，然后使用音频编码器对其进行编码，并调用sendto()函数发送出去。当该线程完成了初始化之后，它将使用Rendezvous实用单元与其它线程进行同步。只有当其它线程都完成初始化后才会开始执行如下的循环过程。
(1)用Engine_open()创建一个编解码器引擎的实例，这个函数的返回值是一个句柄，所有使用相同编/解码器的线程需要各自的句柄；
(2)创建音频编码算法的实例，目前使用的是G.711算法；
(3)为编码数据分配连续的缓冲区，需要注意的是在这里不能使用malloc()进行内存的分配，因为编码由DSP实现，而DSP内核需要连续的内存才能工作，所以必须使用函数Memory_contigAlloc()；
(4)再为单采样(mono samples)数据分配连续的缓冲区，因为仍需用DSP处理，所以也要用函数Memory_contigAlloc()分配连续的缓冲；
(5)使用stereoToMono()将立体声采样数据转换成单采样数据；
(6)调用函数SPHENC_process()进行编码，该函数需要的参数有：输入缓冲，输出缓冲以及两个缓冲区的大小；
(7)调用sendto()函数发送编码好的数据。
回到第(5)步循环执行，直到控制线程收到退出应用程序的命令。
音频输出线程
该线程的作用是将收到的音频数据使用G.711的解码器进行解码，然后将结果写到AIC33设备驱动中。
(1)初始化编码文件加载器，并且读入一帧的编码数据。
(2)调用函数AUDDEC_process()对读入的编码数据进行解码。这是编/解码器的一个过程调用，它可以使用音频算法去解码缓冲区。
(3)使用UNIX标准的wtite()函数将解码后的数据写到AIC33设备驱动上。
(4)继续读入一帧编码的数据，然后回到第2步。
这个循环将会一直执行知道控制线程通知应用程序退出为止。
视频捕获线程
为了实现并行化的处理，我们创建了单独的视频捕获线程来不断的从视频设备(摄像头)中捕获视频帧。执行步骤为：
(1)首先使用函数initCaptureDevice()来初始化视频捕获设备，这个视频捕获设备驱动是V4L2(Video 4 Linux 2)设备驱动；
(2)自动检测电视标准是NTSC制式还是PAL制式；
(3)使用VIDIOC_REQBUFS为捕获的视频帧分配缓冲区，然后通过mmap()将这些缓冲区映射到用户空间应用程序中，最后调用VIDIOC_STREAMON ioctl开始从视频设备驱动中捕获视频帧。
视频压缩传送线程
该线程的作用是使用H.264的视频编码算法将视频捕获线程捕获的视频帧进行编码，然后将编码后的数据发送出去。
(1)用Engine_open()创建一个编解码器引擎的实例，这个函数的返回值是一个句柄，所有使用相同编/解码器的线程需要各自的句柄；
(2)创建音频编解码算法的实例，目前使用的是H.264算法。使用函数VIDDEC_create()中的静态参数来创建编/解码器的实例，然后用VIDDEC_control()来设置视频解码器的动态参数；
(3)由videoEncodeAlgCreate()创建视频编码器，支持H.264算法，其实例由VIDENC_create()中的静态参数创建，参数targetFrameRate和refFrameRate的设置取决于PAL制式还是NTSC制式，动态视频编码参数调用VIDENC_control()来设置；
(4)用函数Memory_contigAlloc()给编码数据分配连续的缓冲区；
(5)分配缓冲区(在DISPLAY_BUFFERS中设置)与显示线程进行交互；
当视频线程完成了初始化之后，它将使用Rendezvous实用单元与其它线程进行同步。只有当其它线程也完成了初始化后，视频线程的主循环才会开始执行。
视频显示线程
为了获得更可靠的性能，并且避免当多个视频帧同时要求解码时会出现丢帧的现象，所以单独创建一个显示线程用来执行视频帧的显示。如果将解码和显示等都放到一个线程中去执行，那么任何一个帧超过其生存时间(NTSC是33ms，PAL是40ms)后都会被丢弃。显示线程来负责将解码视频缓冲区复制到FBDev显示设备驱动的帧缓冲中。这使解码缓冲的复制与DSP的处理是同步的。这个线程的执行是从用函数initDisplayDevice()初始化FBDev显示设备驱动开始的。在这个函数中，
显示分辨率和每像素的比特数会FBIOPUT_VSCREENINFO ioctl来设置。
当显示线程完成了初始化之后，它将使用Rendezvous实用单元与其它线程进行同步。只有当其它线程也都完成了初始化之后，显示线程的主循环才会开始执行。图4显示了视频线程之间的交互。
●网络传输部分
网络传输是整个视频电话系统中非常重要的部分，我们选择使用socket来实现网络通信。因为socket不仅适用于同一台计算机上的进程间的通信，同时也适用于网络环境中的进程间通信。用socket进行网络通信程序设计，程序结构清晰，数据交换稳定、高效，并且具有与平台、语言无关的特点，这样为跨平台网络通信提供了一个很好放入途径。
常见的socket有流式socket、数据报socket和原始socket三种类型。流式socket可以提供可靠的、面向连接的通信流，它使用TCP协议，从而保证了数据传输的正确性和顺序性。数据报socket是一种无连接的数据服务，数据通过相互独立的报文进行无序传输，使用用户数据报协议UDP。原始socket虽然功能强大但是使用较复杂，主要用于一些协议的开发和测试工作。为了实现系统实时性的要求，我们采用了使用UDP协议的数据报socket。定义了有两组socket，一组用于保证指令的可靠发送和接受，另一组负责音频视频数据的传送和接受，但不保证其传送的可靠性。因为在PC端和机顶盒端使用socket进行数据交换的流程大体相同，因此下面我们可以不用区分两个不同平台地介绍网络传输的流程。
首先介绍双方通信连接的建立。图5说明了连接建立的过程。连接的建立是通过一些请求的发送和确认实现的(就是一些命令的发送)。上面提到过，命令的传送是可靠，这是通过定义了一个队列来实现的。命令包中有一个type标志位是与音视频数据包完全不同的地方，type＝0代表着首次发送该命令，当接收方收到之后，会将type位置1，代表着对这个命令的确认。当发送了一个命令后(此时type＝0)，就将其放入队列之中，当在规定时间内收到了对这个命令的确认时(type＝1的该命令包)，就将该命令从队列中删除，否则的话将该命令进行超时重发，这样就保证了命令的可靠传输。
双方数据的发送比较简单，当采集到的音频和视频数据编码完成之后，就调用sendto()函数发送给对方即可，这当然是在不同的线程中进行的。
至于数据的接收，我们创建了一个单独的线程进行处理，即接受数据的socket线程，这个线程也是非常重要的，它的作用是不断接收对方发送过来的数据包，然后根据包的标志分别进行处理。进行传输的共有三种数据包：音频数据包、视频数据包和命令包，每一中数据包都有自己的类型标志位flag，接受数据的socket线程就是通过这个标志位来判断收到的是哪种数据包的。如果是FLAG_CMD(命令包)，则调用命令解释函数进行命令的解析，看是哪种命令(如呼叫、接受、拒绝、取消等)，然后分别进行处理；如果是FLAG_AUDIO(音频数据包)，就将其所携带的音频数据放入音频输出线程的消息队列中，等待音频输入线程进行处理；如果是FLAG_VIDEO(视频数据包)，因为我们没有为视频创建单独的线程，所以直接将其携带的视频数据交给解码器进行解码即可。