语音视频

前言：想要写出一篇令人眼前一亮的文章吗？我们特意为您整理了5篇语音视频范文，相信会为您的写作带来帮助，发现更多的写作思路和灵感。

语音视频范文第1篇

文章结合我校大学英语网络教学改革已进行到中期阶段的背景，依据相关的外语习得及教学理论，结合课题的研究内容与目标，对我校正在开发的大学英语音视频资源库进行详细论述及深入探讨。以资源的准确性、实用性、完整性、可扩展性为标准，对教学资源科学分类整合，构建音视频资源库平台，服务于学生的自主学习，提升学生英语学习的兴趣与效率，强化他们的自主学习能力。并对后续存在的问题进行了探究，提出可行的解决方案。

关键词

教学改革；自主学习；资源库；开发；应用

0引言

我校在过去10年推行了大学英语网络化教学改革，投入数百万元建成了13个网络型语音室，构建了完善的英语自主学习环境，硬件设施在省内遥遥领先，但在软件资源建设及后续投入上却乏力。仅创建了网络英语学习平台主页，链接了外教社的新理念学习平台，但网站里内容不够充实，大多是一些外链资源，缺乏实用性和自主性，对学生没有吸引力。为了构建完善的大学英语自主学习与教学网络资源库，进一步推进大学英语教学改革进程，课题组成员拟用两年时间完成大学英语音视频资源库的开发和建设，根据师生应用中的反馈意见，积极改进各项功能，完善资源库。

1资源库开发的理论基础

自主学习是以学生作为学习的主体，通过学生独立地分析、探索、实践、质疑、创造等方法来实现学习目标，培养学生搜集和处理信息的能力、获取新知识的能力、分析和解决问题的能力以及交流与合作的能力。基于这一观点，笔者认为大学英语的自主学习应是给予每个学习者理想的外语学习环境，通过教师的引导，充分调动每个学习者的主动性，最终达成英语学习的目标。而理想的外语学习环境，就目前我校大学英语教学改革的现状，首要任务就是完善自主学习中心，开发建设大学英语音视频资源库。美国著名语言教育家克拉申（Krashen）认为：只有当习得者接触到“可理解的语言输入”（comprehensiveinput），即略高于他现有语言技能水平的第二语言输入，而他又能把注意力集中于对意义或对信息的理解而不是对形式的理解时，才能产生习得，理想的语言输入应具备可理解性、有趣又相关、足够的输入量等特点。大学英语音视频资源库的建立正是为了最大限度地为我校学生提供英语语言学习材料和实践机会，接触真正的西方社会与文化，使他们能广泛而有效地获取英语语言知识、从而提高语言习得能力，真正实现“有效地输出”。

2资源库开发的重要性

2.1发展自主学习中心的需要

目前国内各高校自主学习平台主要由两种路径形成。一是从出版社直接购买的学习平台，另一个则是各高校自建的资源库。前者可以通过学校资金和人力的投入，短期内则可以投入使用，形成效果。但校本音视频资源库的建设是一个长期的过程，需要课题组的持续努力。通过建设有特色的自主学习资源库，才能为学生的自主学习创造更好的条件，适应网络化、个性化英语教学的需要。

2.2有利于提升英语学习兴趣、提高学习效率

外语教学的最终目的是培养应用语言进行有效交流的能力。英语音视频资源辅助教学及应用于自主学习，不仅有利于语言习得的发展，而且为学生提供大量运用语言的机会，实现跨文化交流，音视频是了解西方文化的最好媒介。

2.3丰富教学方式，实现教学创新，提升教师的教育技术水平

互联网+风潮要求我们教师既要更新教学观念，又要在课堂教学模式、教学内容上进行创新。建设英语音视频资源库过程中可以充分调动老师们的积极性，形成良好的教学创新氛围；通过自学等途径提升了现代教育技术水平，丰富了教学方式。

3建设大学英语音视频资源库的方法与途径

资源库的建设管理是一项持久而庞大的工程，需要课题组成员通过各种渠道搜集各类资源，进行分类整理，同时需要不断提升现代教育技术水平。在学院领导及相关部门的大力支持下，赣南师范大学的英语音视频资源库已基本建设完成，并投入使用一年多，在师生中产生了非常好的反响。我们主要通过以下方法与途径进行资源库的开发与建设：（1）数字化各类英语教材。各类教材是英语教学的主要教学资源，它们也是英语学习者的首选材料，具备较好的权威性及广泛性。数字化英语教材，就是把各类英语教材附带的光盘、磁带转换成能在计算机上保存的音视频文件，存贮在服务器上，从而实现网络化共享。在数字这些素材时，既要考虑到教材的完整性，也要充分考虑到学生自主学习时的易用性，根据用途及层次对听力材料进行分层管理，文件命名均采用见名知义的命名方法，使师生在调用时简单易懂，实现快捷访问、高效利用。（2）自主开发点播系统，入库优质资源。视频资源比音频资源更加直观、形象，是学生首选的学习素材。在我校现代外语教育技术应用与研究中心的指导帮助下，我们自主设计开发了英语视频点播系统，内容涵盖：①各种英语视频课程：如学校自建的精品视频公开课和师生的英语教学竞赛视频，全球知名大学的视频公开课。②流行英语学习课程：如“走遍美国”、“空中英语教室”等。③主流英语媒体节目，如中央电视台英语频道，ABC美国广播公司，CNN广播公司等节目源。④英语演讲视频：如CCTV杯英语风采大赛，TED演讲集、经典演讲视频等。⑤影视资源：我们搜集整理了各类影视经典资源，包括奥斯卡历年最佳影片、IMDB最佳影片top250等优质影视资源。从实际应用情况来看，该资源是学生点击率最高的版块，可见其受欢迎程度。（3）购买适合教学与自主学习的音视频资源目前教育资源市场上针对英语学习方面的资源库是越来越多，为了与硬件设设相配套，完善我校英语网络教学与自主学习环境，我校近些年加大了对软件建设的投入，购买了一些重点资源库，涵盖英语学习、考试及出国留学等音视频资源，主要包括外语自主学习资源库、新东方多媒体学习库、环球英语网络、Fif外语学习资源库和部分试用资源库，极大地丰富了英语教学与自主学习资源，完善了英语网络学习环境。（4）制作音视频资源导航页，从互联网上下载相关打包资源。互联网是英语学习、教学的宝藏，里面有非常丰富、完整的各类英语音视频学习、教学资源等待我们去挖掘整理，如乔丹NBA经典比赛视频合辑、经典足球比赛欣赏、伦敦奥运会开幕式、老鹰乐队澳大利亚告别演唱会等经典高清英语资源，由于视频格式和播放器的局限性，我们通过迅雷等下载工具直接打包下载到服务器上，然后再制作资源导航页，让学生通过下载到本地的方式进行欣赏，这样既减轻了服务器的压力，也使学生有更多时间去慢慢领会其中所包含的文化价值意义。

4资源库的应用

有了英语音视频资源库，教师可以直接调用资源库中的教学资料进行课堂教学，有了英语音视频资源库和其它配套的学习系统，教师可以根据不同专业学生特点，采取灵活多样的教学，选择与其专业相符的教学内容，实行因材施教，把专业学习与英语学习有机结合起来，实现共赢。基于这些丰富、完整的数字化资源，学生们可以根据自己兴趣爱好和专业特点，在网络型语音室或寝室在线自主学习，选择合适的学习内容，按照自己的进度安排学习，实现高效利用时间，最终使学生具备较强的自主学习能力，养成良好的自主学习习惯。

5结束语

通过教学实践证明，有了基于本校实际的大学英语音视频资源库，给老师与学生带来非常大的学习能动性。教师可以充分利用起网络语音室的各项功能，进行教学改革创新，施行因生、因材施教，提高课堂教学效率，最大化地转化学习效果。同时，基于校园网的学生在线自主学习，通过选择与自己水平、兴趣相当的学习素材，真正实现自己学习、主动学习，充分激发了学生的求知欲望，打破课堂局限，通过网络互动有利地建设了第二课堂，使学习延伸到课外生活中去，从而使学生真正具备较强的自主学习能力，实现培养目标。但我们的研究也存在一些需要改进的问题。比如随着智能手机在学生中的普及，需要我们将资源进行转换，以适应安卓、苹果手机上的使用，这对我们的技术提出了新的挑战；另外，老师和学生才是资源的真正使用者，对如何选材、使用效果及如何改进等方面最有发言权，课题组应及时与他们进行沟通、问卷调查，进一步完善资源库，实现更广的社会传播价值。

作者：赖艺 刘忠平 单位：赣南师范大学外国语学院

参考文献

[2]零月秀,李波.大学英语听说教学数字化资源库的建设[J].通化师范学院学报,2004.25(1):106-108.

[3]莫锦国.大学英语自主式教学资源库开发初探[J].外语电化教学,2005(102):36-39.

[4]教育部高等教育司.大学英语课程教学要求[M].北京:清华大学出版社,2007:18-25.

[5]门斌.大学英语多媒体网络教学资源库的建设[J].电化教育研究,2009(7):68-72.

[6]甘玲玲.大学英语自主学习：校本网络资源库的开发[J].百色学院学报,2009.22(6):104-107.

[7]海霞.新疆大学英语教学网络资源库建设调查报告[J].新疆广播电视大学学报,2011(3):54-56.

[8]郭继荣,戴炜栋.大学生英语自主学习评价实证研究[J].外语界,2011(6):79-87:

语音视频范文第2篇

关键词：H323；MCU；混合器；视频会议系统

1 引言

会议是人类社会政治经济生活中不可缺少的一部分。随着ITU制定出第一个H.320标准和H.323标准，视频会议获得了长足的发展。视频会议作为一种先进的多媒体通信手段，已逐步被众多政府部门和跨地区企事业单位所接受和采用[1]。然而相对于Internet有限的带宽，图像通信所需要的带宽太大，视频会议无法承载原始视频的多路通信。因此，多点控制单元（MCU）对于音视频的多路通信起着重要的作用[2]。文章主要针对视频会议中的主要部分MCU，研究分析H.323视频会议中如何利用有限的带宽实现音视频的混合于传输。

2 H323协议简介

H.323协议是ITU第15研究组SG-15于1996年通过的在不保证服务质量（QoS）的分组交换网络（PBN：Packet based networks）上传递信息的多媒体通信协议。从整体上来说，H.323是一个框架性协议，它涉及到终端设备、视频、音频和数据传输、通信控制、网络接口方面的内容，还包括了组成多点会议的多点控制单元（MCU）、多点控制器（MC）、多点处理器（MP）、网关以及关守等。H.323为基于网络的通信系统定义了四个主要的组件：终端（Terminal）、网关（Gateway）、网守（Gatekeeper）、多点控制单元（MCU）。所有终端都必须支持语音通信，视频和数据通信可选.H.323规定了不同的音频、视频或数据终端协同工作所需的操作模式[3]。H.323终端的组成中。在发送端，从输入设备获取的视频和音频信号，经编码器压缩编码后，按照协议规定的格式打包，通过网络发送出去.在接收端，来自网络的数据包首先被解包，获得的视频、音频压缩数据经解码后送入输出设备，用户数据和控制数据也得到了相应的处理。

3 混合器的功能分析

在视频会议过程中，每个终端以点对点方式在控制信道上与MCU信令通信，并在用户数据包协议（UDP：User Datagram Protocol）信道上与之进行音频，视频和数据通信。在此过程中，MCU融合了多点控制器（MC）和多点处理器（MP）两个功能。MCU可以使用分布式多点音频和集中式多点视频。在此模式中，MCU对音视频的操作是不同的，例如当音频信号来到时，MCP将之从所属音频通道直接拷贝到其他每个会议成员的音频通道中；而当视频信号来到时，MCU先将其存入缓存，等所有成员的帧数据全部存入缓存后，分别发送至每个会议终端，从而达到视频混合的目的[6]。

3.1 MCU对视频的标识

在对视频的转发过程中对视频的标识显得特别重要。当多路视频组合为一路发送往各终端时，需要将各视频与终端联系起来，从而使每个终端都能清楚它们的对应关系。另外为了满足视频会议中各成员之间的单独交互，在终端得到会议成员列表也是必不可少的。

3.2 MCU对多会议室的支持

当MCU中包含多个会议室时，情况有所复杂。我们为每一个会议室分配一个“房间”（room）；由于不在同一会议室，不同房间中的成员不能接收到其他房间中音视频信息，这样MCU就需要为每个房间增加一个标识，以便区别各会议室的音视频信息。

4 混合器的设计实现

Openh323封装了视频会议通信的整个过程，利用它暴露的接口类，我们可以很容易地实现MCU的混合器功能。

4.1 H323终端

H323EndPoint类管理H323终端（endpoint），一个终端可能有0个或者多个侦听线程来负责关于呼入的连接，终端也可能有0或者多个通过MakeCall（）初始化呼出的连接，一旦一个连接存在，该连接就被此类的实例管理。此类最主要的内容是包含终端应用程序的能力，也就是终端可以处理的协议和多媒体数字信号编解码器（codec），大多数应用程序通常都会创建一个H323Endpoint类的派生类，也会创建一个H323Connection类的派生类并重载CreateConnection（）函数。

4.2 音频转发的实现

音频信号的转发有些复杂，因为它涉及到混频，当有终端发送的音频到达MCU时，MCU执行以下操作：

（1） 调用相应的解码函数对通道中接受的音频信号进行解码，并将解码后的音频信号写入IncomingAudio channel通道。

（2） IncomingAudio函数将数据发送至缓存，并将数据从缓存依次复制到其他所有通道的缓存中。这样，MCU完成了对接收音频的处理.，随后MCU开始发送音频信号。

（3） 依次对所有与MCU连接的终端调用OutgoingAudio函数将所有连接（不包括即将发送音频的连接）缓存中的音频信号进行混频。

（4） 音频编码器将混频后的信号经由与MCU连接的通道发送往各终端，完成音频的转发功能。

4.3 视频转发的实现

由于不用进行过多处理，视频信号的转发相对简单。MCU中有一个缓存VideoBuffer专门用于视频转发，当视频信号到达时，视频解码器（Video Codec）对之进行解码并将结果视频写入IncomingVideo channel通道，MCU调用WriteVideo将解码后的视频帧写入缓存的指定位置（例如左上角）；一旦所有视频帧都被写入缓存， MCU便调用ReadVideo将缓存中的组合视频帧（一般是分块）写入各通道，最后由编码器编码后发送至各终端。另外，由于视频大小的限制，原始视频需要经过抽样。

4.4 会议成员列表

Openh323中没有给出相关的功能接口，因此这项功能需要我们来扩展，终端要从MCU得到会议成员列表，即通过H323EndPoint向每个终端发送包含成员列表的文本消息。当有终端与MCU建立连接时，MCU会将成员列表以字符串的形式封装，并发送至每个终端；终端相应地增加消息处理函数来接收MCU方发送来的成员列表，并在界面中显示。

4.5 对多会议室的支持

当用户与MCU建立连接时，需要为连接指定一个会议标识（默认为room1）。这样，在MCU中便存在多个房间，当会议开始后，每一个终端的音视频到达MCU后都会根据其终端所属的会议标识进行分别处理。例如，当room1房间的成员有视频信号到达MCU时，MCU先判断其所属会议标识，这里是room1；然后便将其视频按前面所述的方法存入room1的视频缓存中。最后，当room1所有成员的视频信号都到达后，再将其缓存中的视频数据分别发送至room1的各成员终端，以完成room1会议的视频转发过程。对于其他的房间也执行相同的处理，而且各房间之间的音视频转发互不干扰。

5 测试实验与结果分析

为了验证文章提出的设计方案的可行性和有效性，基于Openh323 Library实现了一套H323视频会议的原型系统。以下，对我们实现的视频会议原型系统进行测试实验。

本实验的运行环境为实验室局域网，测试对象为基于IP的网络视频会议系统，实验设备包括：局域网，多台电脑（带视频头和音频采集器）。

实验结果：当用户Terminal1加入会议室room1时，MCU会立即刷新room1的成员列表，并将Terminal1的音视频进行处理后连同其他音视频按照既定方法发送至各终端；Terminal1的加入对room2中的各成员终端没有任何影响，而且音视频的转发照常进行。

6 结束语

H323协议使基于IP的网络视频会议成为可能，但带宽的限制使多媒体的传输成为会议的瓶颈。文章介绍了一种在Openh323基础上，通过MCU将音视频混合并转发的方法，使音视频能够在基于IP的网络上正常传输，成功实现了多媒体会议的视频控制与传输。但仍有问题尚待进一步解决，由于MCU方将视频混合后发送网各端点，这就造成了视频质量的下降，因此有必要对视频进行插值放大或帧速率上转换等后处理。

参考文献

[1]Runsheng Wang， Xiaorui Hu. “VoIP Development in China，” Computer[J].2004，37（9）： 30～37.

[2]黄东军， 陈松乔. 基于源根组播的多点视频会议系统模型及其实现[J].电子学报， 2005，33（1）： 47～51.

[3]张明德，王永东. 视频会议系统原理与应用[M]. 北京：希望电子出版社，1999.

[4]BUR GOODE.Voice Over Internet Protocol （VoIP）. Proceedings of The IEEE[J]，2002， 90（9）： 1495～1517

[5]蔡胜， 苏应飚. VoIP 网关中H323 协议栈的实现. 计算机与现代化 [J]，2002，3： 19～21

语音视频范文第3篇

    在本系统中总部指挥中心的核心配置是1台音视频综合通信主机,该主机集语音处理单元、视频处理单元和调度控制单元构成的综合型交换处理设备,即音视频综合通信主机;同时,该主机的语音处理单元、视频处理单元及控制单元均支持扩展功能,是完全能够满足总部指挥中心对多个下级语音调度和内部通信的要求。总部指挥中心配置可供调度人员切换和控制的调度席,供指挥人员指挥的指挥席;调度席为指挥席提供中心到各分站调度语音、视频(包括切换及控制)的链路建立。同时,调度席可以电话、语音的形式,接收指挥席的指令要求,对前端的记者进行语音调度和视频监视。指挥席与前方分站建立通信连接后,实现双向语音通话,双向视频,以及对前端监控单元进行控制。整个系统支持多分站之间的连接,建立连接后中心、多个分站之间可以实现电话会议、视频会议等业务,便于中心调度指令。

    现场指挥中心设计

    现场指挥中心的核心配置是1台音视频综合通信分机,该分机集语音处理单元、视频处理单元和调度控制单元构成的综合型交换处理设备,即音视频综合通信分机;同时,该分机的语音处理单元、视频处理单元及控制单元均支持扩展功能,完全能够满足现场指挥中心对前端信息的接入和调度。现场指挥中心音视频综合通信分机针对本地现场提供多路有、无线通话接口;并通过地面的IP网络或卫星链路实现与总部指挥中心、其他分现场指挥中心的通话互联。现场指挥中心音视频综合通信分机可通过有、无线调度系统对现场采集人员提供多路连接方式,每个无线终端设备之间可实现点对点通信,并支持功能扩展;同时,总部指挥中心通过现场指挥中心中继后可直接对前端记者进行语音调度,所有操作均实时完成。音视频综合通信分机提供多路串口控制,通过地面IP网络或卫星链路将控制信号传到调度终端,总部指挥中心就可直接对前端设备进行远程控制。音视频综合通信分机提供多路视频的处理能力,可为现场指挥中心提供现场多路视频接入,至少提供1路的视频编解码能力,为总部指挥中心提供现场的视频监控,同时,支持视频接入的扩展。

语音视频范文第4篇

关键词：流媒体；音频；实时传输；自适应；嵌入式；Android

中图分类号：TP309文献标识码：A文章编号：1009-3044(2011)04-0890-05

Audio Real-time Adaptive Transmission Technology Based on Android

SONG Ran-xin1,2, XIE Wei-bo1,2

(1.College of Computer Science & Technology, Huaqiao University, Quanzhou 362021,China; 2.Laboratory of Embedded Technology, Xiamen Software Park, Huaqiao University, Xiamen 361008, China)

Abstract: With the development of the wireless and the mobile networks, the streaming media technology on embedded platform has drawn the attention of most developers. The transmission of the high-quality audio as an important branch is also developing, however, most applications are on the PC platform. With the continuous development of the embedded platform, streaming media applications are also progressing towards embedded systems, This article will present a solution on high-quality real-time adaptive transmission based on Android.

Key words: streaming media; audio; real-time transmission; adaptive; embedded; android

近年来，移动网络的发展已进入一个空前活跃的时期，尤其是2009年，国内3G网络的开放大大加速了无线网络的应用和普及。随着网络的迅速发展，网络中的实时的高质量音频（Audio）传输已日益引起各方的关注，尤其是在嵌入式平台上。本文将就Android平台下如何实现高质量音频的实时自适应传输提出一种解决方案。

1 Android平台简介

1.1 Android 简介

Android是Google于2007年11月05日宣布的基于Linux平台的开源手机操作系统的名称，该平台由操作系统、中间件、用户界面和应用软件组成。它采用软件堆层（Software Stack，又名软件叠层）的架构，主要分为三部分。底层以Linux内核工作为基础，由C语言开发，只提供基本功能；中间层包括函数库Library和虚拟机Virtual Machine，由C++开发。最上层是各种应用软件，包括通话程序，短信程序等，应用软件则由各公司自行开发，以Java作为编写程序的主要语言。目前，Android已经进入了自己预定的和谐的发展轨道，逐渐地发展壮大起来，成为了移动及嵌入式平台中一颗璀璨的新星。

1.2 Android 平台应用程序架构

图1为Android 平台应用程序架构。

Linux Kernel: 是Linux Kernel在移动平台的一个移植，它隐藏了硬件、网络等相关的细节，为上层提供了一个相对纯洁的统一接口。

Libraries: 是一些核心的和扩展的类库，它们都是原生的C++实现。在这一层，包含众多开源项目，如SQLite、WebKit、OpenGL 等。如果，该层类库需要被上层函数调用，就必须要通过JNI导出相应的接口函数，否则就只能在层次内部之间调用。

在此层中，还有为上层Java程序服务的运行库。Dalvik虚拟机，是Android的Java虚拟机，之所以不采用 J2ME的虚拟机，一方面是因为J2ME的设计是为了低端机器而优化，而Dalvik则是为了高端一些的机器进行优化，提供更好的性能。另一方面，从商业角度来看，必须绕开J2ME虚拟机，Android才能彻底开源。

Application Framework：框架层，这里包含所有开发所用的SDK类库，另外还有一些未公开接口的类库和实现，它们是整个Android平台核心机制的体现。

Application： 应用层，系统的一些应用和第三方开发的所有应用都是位于这个层次上。

大多数情况下，开发者可以依靠框架层提供的SDK使用Java语言进行应用程序设计，但是在某些特殊情况下，比如性能优化或者平台移植，这种编程方式便不能满足开发需要。除了SDK，Android还提供了NDK（Native Development Kit），NDK的出现意味着，最上面应用层的内容，可以穿越Java部署的框架层，直接和底层暴露出来的，或者自行开发的C++库直接对话，当然在这些库中需要包含JNI（Java Native Interface）的接口。

那么Android为什么不直接用C++进行应用开发呢？纯C++应用，在Android中是无法被接受的。因为在Android中，大量的核心机制部署在框架层，它们都是用Java实现的，比如控件库，Activity的调度之类的，没了界面，就没了调度，因此，C++的程序作为类库比较合适。

1.3 JNI技术

Java本地接口（Java Native Interface （JNI））允许运行在Java虚拟机（Java Virtual Machine （JVM））上的代码调用本地程序和类库，或者被它们调用，这些程序和类库可以是其它语言编写的，比如C、C++或者汇编语言。

当一个程序无法完全使用Java编写时，开发者可以通过JNI来编写本地方法，比如标准Java类库并不支持的依赖于平台的特色或者程序库。 JNI还可以用于修改现有的使用其它语言编写的程序，使它们可以通过Java编写的程序来访问。

很多基本类库都依赖JNI来为开发者和用户提供服务，比如文件的输入/输出和音频功能。在基本类库中包含的对于性能和平台敏感的API可以允许 所有的Java程序以安全和平台无关的方式来使用这些功能。

2 程序的构架设计与具体实现

2.1 需要解决的问题

2.1.1 程序的基本框架

考虑到Android平台的构架特点，程序将采用Java和嵌入式C混合编程，由于Java语言的虚拟机机制，使其在多媒体编解码运算时无法充分发挥硬件性能，导致运算性能偏低，所以在程序的编解码部分将通过嵌入式C编写库来实现。程序包含网络传输在内的其他部分将有Java语言完成。最后通过JNI（Java Native Interface）将C库与Java进行衔接。

2.1.2 音频质量与编码算法

为确保音频的高质量传输，在编码的选择上，传统的语音音频采用 Speech Code 如（G.711, G.723, G.726 , G.729, ILBC, QCELP）这些编码格式虽然小巧，但是采样率大多都只有8KHz，处理后对音频损失较大，为实现高质量的语音，可采用 Audio Code 如 （AAC, OGG, MP3, WMA, SBC 等）。同时，为了方便针对嵌入式平台运行的调整和优化，在选择编码的时候尽量选择开源项目。

在经过各种测试后，程序决定采用MP3算法作为音频的编解码。测试过的MP3编解码库主要有以下几个：

编码库：

Shine：是一款专为ARM优化的MP3定点编码库，在保证音质可以接受的情况下尽量简化MP3的编码算法。故它的编码运算速度较快，音质从测试看来也在可接受的范围内。

BladeEnc：一款跨平台的免费MP3编码库，遵循LGPL，速度快，但不支持定点运算。

Comprec：是Shine针对某移动设备的优化修改版，编码更加简化速度也更快。

解码库:

MAD（libmad）：是一个开源的高精度 MPEG 音频解码库，支持 MPEG-1（Layer I, Layer II 和 LayerIII（MP3）。libmad 提供 24-bit 的 PCM 输出，完全是定点计算。未经优化的libmad音质还原很好，但是解码速度稍慢。因此需针对平台优化后使用。

Real： 为32位定点处理器提供高性能的MP3解码支持（仅支持MP3，对MP2和MP1不支持），并且为多种处理器和平台提供了优化配置方案，如（ARM，x86等）。

FFmpeg：开源的跨平台音视频编解码库，为多种平台提供配置编译支持，但由于支持格式众多，需自行分离及编译优化。

根据硬件设备及开发环境，可按需要选取合适的编解码库。

2.1.3 传输的实时性

多媒体流的实时传输对带宽和延迟比较敏感，要求有一定服务质量保证（QoS），传统的互联协议只能提供尽力而为的服务，对于具有实时性、连续性、交互性的流媒体服务已无法满足需要。因此，拟采用RTP（Real-time Transpot Protocol）实时流媒体传输协议进行音频的传输。RTP报文用来做实时传输时，可以灵活改变速率、防止乱序。同时辅以RTCP（Real-time Transpot Control Protocol）协议，其报文在传输过程中可以为RTP数据提供网络状况和服务质量的反馈。

利用RTP/RTCP的反馈结果，设计合适的网络自适应算法计算网络的拥塞程度。

由于Android本身并没有提供对RTP协议的支持，因此，Java中实现RTP协议传输可以使用开源的Jlibrtp库，Jlibrtp为Java编写的sourceforge开源项目，提供了RTP数据包定义，RTP传输，及RTCP反馈等符合RTP协议传输规范的大多功能。

2.1.4 自适应传输原理与算法

考虑到嵌入式设备的性能，网络拥塞算法不应过于复杂，可将网络拥塞算法和音频编码算法相结合，动态调整音频的编码和发送，已达到较为流畅的媒体流，下面为自适应算法原理及简单描述：

由于RTP/RTCP是运行在UDP协议之上的，而UDP是不可靠的协议，它没有TCP的流量控制等能力，因此常用的算法是基于已丢失报文的评估算法。

数据包丢失率是监控器估计网络信道状况的指标，但不能直接利用丢失率判断网络信道状况并据此调整音频的发送，因为会使发送数据变动得过于频繁，也使接收端的音频产生波动，质量不稳定。在利用数据包丢失率估计网络信道状况之前，先对其作平滑处理。[2]

根据平滑后的数据包丢失率与事先确定的阈值的关系，可以判断网络上的负载情况，依此将网络状态分为若干类：

假定暂分为三类（轻载，满载和阻塞），网络状态的分类算法：设定2 个阈值k1、k2(测试给定值)，平滑后RTP 数据包的丢失率为t(n)。音频编码算法为A(i)，其中i为调整编码的系数，i越大，压缩比越高，对应于三种状态的i值分别为i1 < i2 < i3。（i值由实验统计得出），D为网络常规传输速率。

1) 当t(n) < k1 时，视为轻载；

2) 当t(n) > k1 且t(n) < k2 时，视为满载；

3) 当t(n) > k2 时，视为阻塞。

则自适应算法描述为：

if ( t(n) < k1 )

A(i1) ;AIMD(D);

else if ( k1 < t(n) < k2 )

A(i2) ;D;

else

A(i3) ;AIMD(D);

算法中D的增减由 AIMD（加性增乘性减）的算法或其优化算法控制。其算法表述为：

其中a,b均为常数, a>=0; 0

2.2 程序整体架构与实现

程序主要包含三个模块，程序界面，网络收发模块及音频编解码模块。如图2。

2.2.1 开发环境

开发平台：Windows 7企业版；开发工具：Eclipse + ADT；开发环境：Java 2 SDK ver.1.6，Android SDK v2.1，Android NDK v1.6，Cygwin（其中Cygwin和NDK用来构建C/C++的交叉编译环境）

2.2.2 程序的设计与实现

1）MP3编解码库的优化：

嵌入式平台MP3编码库算法的优化根据平台和需求不同，需要做的调整也不一样，一般主要都包含以下几个方面:

① 浮点运算改为定点运算：嵌入式平台多数CPU对浮点运算的支持较差或者不支持，因此，如果选择的编码是浮点的，需要对此部分进行定点改写，否则运算效率将非常低

② 对常用的运算函数用ARM汇编语言重写：对部分底层常用函数如加减乘除基本运算，用汇编语言改写可提高程序执行效率。

③ 添加JNI接口，使其可以在Java中调用：自行编写的C或C++库在执行时位于系统库中，不能直接使用，因此在编写优化完库后，需对其添加JNI接口，以供应用程序穿过框架层直接进行调用。

C库中的JNI接口设计与调用：

在Android 的NDK中提供了完善的JNI支持，使得在应用程序中，可以使用Java方便的调用Linux的基础C库，但是首先要对C库进行改写，提供JNI的接入支持。

C库中添加JNI接口：

JNIEXPORT jint JNICALL

Java_com_codec_mp3dec_Mp3dec_write(JNIEnv* env,jobject thiz,

jobject inputStream,

jint len)

{unsigned char* input= (unsigned char*)

((*env)->GetDirectBufferAddress(env,inputStream));

memcpy(readBuf + bytesLeft,input,len);

bytesLeft += len;

fillSize = READBUF_SIZE - bytesLeft;

return fillSize;}

Java中通过JNI调用：

static

{System.loadLibrary("mp3dec");}

while(getFillSize()>1024) {

buffOut=buffList.take();

nRead = buffOut.length;

inputBuffer.clear();

inputBuffer.put(buffOut);

write(inputBuffer,nRead);} /* 调用上面C库中定义的write方法*/

2）程序实现的关键类与部分代码示例

图3 程序模块结构图

AudioRecord和AudioTrack类是Android获取和播放音频流的重要类,放置在android.media包中。该包中还包含 MediaRecorder和MediaPlayer类，这几个类都可实现音频的录制与回放，不同的是AudioRecord和AudioTrack类在获取和播放音频数据流时无需通过文件保存和文件读取，可以动态地直接获取和播放音频流，减少了媒体对于磁盘的读写，因此非常适合用来实时处理音频数据流。下面是创建两个类的对象的具体代码：

AudioRecord类:

audio_in_buff_size = AudioRecord.getMinBufferSize(8000,

AudioFormat.CHANNEL_CONFIGURATION_MONO,

AudioFormat.ENCODING_PCM_16BIT);

audio_in_rec = new AudioRecord(MediaRecorder.AudioSource.MIC,8000,

AudioFormat.CHANNEL_CONFIGURATION_MONO,

AudioFormat.ENCODING_PCM_16BIT,

audio_in_buff_size) ;

AudioTrack类:

audio_out_buff_size = android.media.AudioTrack.getMinBufferSize(8000,

AudioFormat.CHANNEL_CONFIGURATION_MONO,

AudioFormat.ENCODING_PCM_16BIT);

audio_out_trk = new AudioTrack(AudioManager.STREAM_MUSIC, 8000,

AudioFormat.CHANNEL_CONFIGURATION_MONO,

AudioFormat.ENCODING_PCM_16BIT,

audio_out_buf_size,AudioTrack.MODE_STREAM);

音频回放与RTP传输模块示例：

public LiveMP3Play(int rtpPort, int rtcpPort){

try {

rtpSocket = new DatagramSocket(rtpPort);

rtcpSocket = new DatagramSocket(rtcpPort);

} catch (Exception e) {

System.out.println(e.toString());}

rtpSession = new RTPSession(rtpSocket, rtcpSocket);

rtpSession.naivePktReception(true);

rtpSession.RTPSessionRegister(this,null, null);

Participant p = new Participant("10.0.2.2", 16386, 16387);

rtpSession.addParticipant(p); }; /*用jlibrtp中的类创建RTP连接*/

public void run() {

if ( aAudioTrack02 != null ) {

aAudioTrack02.release();

aAudioTrack02 = null;}

int iMinBufSize = AudioTrack.getMinBufferSize(44100,

AudioFormat.CHANNEL_CONFIGURATION_STEREO,

AudioFormat.ENCODING_PCM_16BIT);

if ( iMinBufSize == AudioTrack.ERROR_BAD_VALUE||

iMinBufSize == AudioTrack.ERROR ) {

return;}/*构建AudioTrack对象*/

try {

aAudioTrack02 = new AudioTrack(AudioManager.STREAM_MUSIC, 44100,AudioFormat.CHANNEL_CONFIGURATION_STEREO, AudioFormat.ENCODING_PCM_16BIT, iMinBufSize,AudioTrack.MODE_STREAM);

} catch (IllegalArgumentException iae) {

myTextView.setText("new AudioTrack Exceeption:" + iae.toString());

iae.printStackTrace();}

try {

while(!stopLive) {

Message msPackCount = new Message();

msPackCount.what = Mp3dec.GUI_NOTIFIER_PACK; Mp3dec.this.myMessageHandler.sendMessage(msPackCount);

if(pktCount>20)

{ int nRead = 0,rec = 0;

while(getFillSize()>1024) {

buffOut=buffList.take();

nRead = buffOut.length;

inputBuffer.clear();

inputBuffer.put(buffOut);

write(inputBuffer,nRead);} /*将MP3数据写入解码缓冲区*/

rec = read(outputBuffer); /*解码MP3音频并输出到缓冲区*/

outputBuffer.flip();

outputBuffer.limit(rec);

outputBuffer.get(outputByte);

outputBuffer.clear();

aAudioTrack02.write(outputByte, 0, outputByte.length);

aAudioTrack02.play();}}} /*回放解码后的音频数据*/

catch (InterruptedException e) {

System.out.println("Error Taked !!!!");

e.printStackTrace();}

rtpSession.endSession();

rtpSocket.close();

rtcpSocket.close();}};

3 结束语

Android系统以其自由的开放性及良好的应用程序构架正稳健而迅速地发展着，短短几年时间中运行其上的应用程序已达十万以上，然而在流媒体实时传输方面的应用程序却不多见，随着移动网络的不断发展，流媒体在手机及平板电脑等移动设备上的应用前景显而易见，本文针对Android 平台的特点，提出了一种高质量音频的实时传输的解决方案，旨在抛砖引玉，共同完善和丰富Android 这个开放性平台上的软件应用。

参考文献：

[1] 葛艳红,李文锋,刘旭光.基于RTP流媒体实时传输的Java实现[J].计算机与现代化,2007,2:59-61.

语音视频范文第5篇

【关键词】 SIP 融合通信客户端 软件体系架构

一、引言

目前，现代电力企业员工日常办公活动中，沟通交流越来越重要。而随着技术的发展，利用先进的技术打破当前通信手段（如电话、短信、电子邮件和多媒体会议等）中以设备和网络为中心的限制，实现只要通过最常使用的通信工具和应用，就可以便捷高效地与上级、同事、客户及合作伙伴保持联系，这是人们一直以来期望的目标，而移动性和统一通信的结合可以达成这个目标。本文将结合移动设备自有的特性，讨论统一通信移动终端的融合技术。

二、融合通信移动终端设计架构

2.1 融合通信移动终端概述

融合通信通常是指把计算机技术与传统通信技术融合一体的新通信模式，融合计算机网络与传统通信网络在一个网络平台上，实现电话、传真、数据传输、音视频会议、呼叫中心、即时通信等众多应用服务。随着移动互联的快速发展，特别是是近几年iPhone、Android等智能手机的快速普及，越来越多的移动设备开始进入企业IT环境当中。

2.2 融合通信移动终端面临的问题

融合通信移动终端设计的目标是要实现在任何地方、利用任何设备，与任何通信实体进行跨平台、跨地域、跨设备的透明通信，且能够保证网络安全通畅，这使得客户端设计面临以下的主要问题：（1）统一通信平台的多样化，如市场上拥有成熟统一通信产品的就有思科、华为、中兴、西门子、微软、IBM等等，如何保证客户端都能够和这些厂商产品兼容；（2）终端系统种类和运行环境多样化，如市面常见的就有iOS、Android和Windows Phone等；（3）移动网络多样性和复杂性，而企业出于安全性考虑，使得移动客户端接入需要考虑的问题变得复杂化；（4）业务功能的可靠性。如语音、视频等实时性业务对IP承载网的网络质量要求很高，而移动设备的网络一般都没有达到这么高的带宽，如何保证音频/视频业务质量。

2.3 融合通信移动终端总体架构

2.3.1 功能架构

结合融合通信的功能要求和所面临的问题，我们设计的功能框架图如图1所示：

移动终端：融合通信平台的用户侧最终呈现的应用。该客户端安装在企业工作人员或者顾客的手机上。

管道侧：用来为平台侧与终端侧传输数据。

服务端：平台侧依据SOA框架搭建，包括框架管理界面、逻辑处理层、接口层和数据层。平台侧为终端上的服务能力提供支持，其服务能力能够利用接口进行添加和扩展。

2.3.2 设计体系架构

为了解决移动终端开发所面临的问题，我们提出了基于中间件的开发模式，即把所有除实时音视频业务外的所有其他业务统一封装整合（如基于SOAP协议的Webservice），而对于实时性的音视频业务，采用通用的SIP协议和RTP/RTSP协议结合的方式处理。结构图如图 2所示：

实现原理：（1）所有非实时音视频业务全部通过中间件适配形成统一的WebService接口提供给客户端；这样可解决多种统一通信平台接入、多种业务系统接入的问题；所有协议使用Https协议进行传输，内容通过3DES加密和GZIP压缩，保证传输的安全性；（2）而所有实时音视频业务则通过SIP会话进行控制，具体协商通过SDP实现，所有业务添加对Qos质量控制支持，确保业务功能的可靠性；（3）实时音视频业务会话协商完成后，音视频数据流通过RTP/SRTP协议直接与统一通信对应的音视频服务器进行对接，确保通用性。

三、移动终端统一通信融合的关键技术

3.1 SIP协议

SIP由IETF RFC定义，用于多方多媒体通信。按照IETFRFC2543的定义，SIP是一个基于文本的应用层控制协议，独立于底层传输协议TCP/UDP/SCTP，用于建立、修改和终止IP网上的双方或多方多媒体会话。SIP协议借鉴了HTTP、SMTP等协议，支持、重定向及登记定位用户等功能，支持用户移动。通过与RTP/RTCP、SDP、RTSP等协议及DNS配合，SIP支持语音、视频、数据、E-mail、状态、IM、聊天、游戏等。SIP协议可在TCP或UDP之上传送，由于SIP本身具有握手机制，可首选UDP。

3.2 视频编解码

因为视频内容传输需要消耗大量的网络带宽资源，采用合适的视频编码技术也是系统的关键。根据已有的编码标准来看，能够适合码流在1M到2M，同时又能保证高清的图像质量，比较好的标准有MPEG-4、 H.264、VC-1和AVS几种。H.264属于下一代编码技术标准，是所有压缩技术里面压缩率最高的，在支持实时标清电视节目时只需要1.5Mbit/s带宽、点播电视只需要1.2Mbit/s带宽，其画质就可以达到DVD效果，这显然有利于未来通信与娱乐、有线与无线的业务开展。因此，从技术的演进来看， H.264视频编码标准被认为是下一阶段的必然选择。因此，本系统优先实现编码H.264。

3.3 业务质量控制

语音、视频等实时性业务对IP承载网的网络质量要求很高，为了保障语音、视频业务QoS质量，在局域网中将语音、视频业务与OA等信息数据业务采取不同的VLAN进行隔离，要求在交换机上作配置相应QoS策略，实现对语音、视频等实时业务媒体流优先转发。

四、结果展示

通过以上的技术研究，搭建起一台中间件服务器，作为与即时消息服务器、UC服务器和信息系统服务器进行数据传输的中间平台，使用这些服务器提供的开发开发接口开发所需要的功能。

同时，在苹果iOS系统上开发完成了“融合通信移动客户端”，主要功能包括以下功能：（1）移动应用门户：融合门户、OA等信息系统，形成统一的移动应用门户；（2）SSO单点登录：为所有移动化信息系统提供统一的认证功能；（3）通讯功能：个人通讯录、企业通讯录、群组、短信群发、智能搜索、快速定位、点击拨号、一号通、语音会议等业务功能；（4）即时消息：融合腾讯通即时消息功能，可与腾讯通PC版进行互通。