前言：想要寫出一篇令人眼前一亮的文章嗎？我們特意為您整理了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版進行互通。