【正文】 播含有自己名字的 RTCP 接收報告。這個地址和端口的信息要發(fā)布給各個與會者。因此，在實際應(yīng)用中， RTP/RTCP/UDP 用于音頻、視頻媒體，而 TCP用于數(shù)據(jù)和控制信令的傳輸。 RTP 為交互式 音頻、視頻等具有實時特性的數(shù)據(jù)提供端到端的傳輸。通常 RTP 算法并不作為一個獨立的網(wǎng)絡(luò)層來實現(xiàn)，而是作為應(yīng)用程序代碼的一部分。 UDP 是一種面向無連接的數(shù)據(jù)報方式，當通信一旦開始，發(fā)送方就不斷地發(fā)送數(shù)據(jù)而不需要接收端做出確認信息。 （ 2） .TCP 的重傳機制 在 TCP/IP 協(xié)議中，當發(fā)送方收不到接收方發(fā)來的確認，并超過一定的時間，就認定該數(shù)據(jù)已丟失，這時它將重傳丟失的數(shù)據(jù)包。因此傳統(tǒng)的 TCP/IP 協(xié)議傳輸實時音頻、視頻數(shù)據(jù)的能力比較差。但是總的來說，國內(nèi)的研究 水平要遠遠落后于國外。會議使用的音頻傳輸軟件主要是 Vat（ Visual Audio Tool） ,它是由 LBNL（ Lawrence Berkeley National Laboratory）網(wǎng)絡(luò)研究小組開發(fā)的一個音頻會議工具，該小組還開發(fā)了視頻工具 vic和白板工具 wb。 第七章：總結(jié)與展望。這些都是實現(xiàn)實時語音通話應(yīng)達到的要求。 環(huán)境設(shè)備需求 ................................... 錯誤 !未定義書簽。 目的 ........................................... 錯誤 !未定義書簽。 簡介 [9] ....................................... 錯誤 !未定義書簽。 第二章 技術(shù)基礎(chǔ) ..................................................... 3 C/S 體系結(jié)構(gòu) ...................................................... 5 傳統(tǒng)的二層 C/S 體系結(jié)構(gòu) ......................... 錯誤 !未定義書簽。 網(wǎng)絡(luò)多媒體教學(xué)系統(tǒng)概述 ............................................ 2 通用網(wǎng)絡(luò)多媒體教學(xué)平臺基本概念 ................. 錯誤 !未定義書簽。本文首先介紹了實時傳輸協(xié)議的簡單應(yīng)用后，詳細分析了 RTP/RTCP 協(xié)議；接著介紹系統(tǒng)的具體實現(xiàn)，主要分三個部分：音頻數(shù)據(jù)的采集和播放，音頻數(shù)據(jù)的解碼和編碼以及音頻數(shù)據(jù)包的發(fā)送和接收。 當前 Inter 中流動的“比特”所代表的內(nèi)容已從原來的數(shù)據(jù)逐漸向?qū)崟r多媒體數(shù)據(jù)演變，它們的特點是對實時性要求非常高。 背景 ........................................... 錯誤 !未定義書簽。 提出的意義 ..................................... 錯誤 !未定義書簽。 B/S 體系結(jié)構(gòu) ...................................................... 6 B/S 三層體系結(jié)構(gòu) ............................... 錯誤 !未定義書簽。 Ajax 技術(shù) [12] .................................... 錯誤 !未定義書簽。 技術(shù)可行性 ..................................... 錯誤 !未定義書簽。 數(shù)據(jù)需求 ....................................... 錯誤 !未定義書簽。 論文的主要內(nèi)容如下： 第一章：引 言，主要介紹了實時多媒體數(shù)據(jù)傳輸?shù)陌l(fā)展，闡述了 TCP 不適合多媒體傳輸?shù)脑虿⒁肓?RTP. 第二章：根據(jù) RFC3550 官方文檔，詳細分析了 RTP/RTCP 協(xié)議。隨著IPv6， RSVP,RTP/RTCP 一系列協(xié)議的出現(xiàn)，在 Inter 上實現(xiàn)多媒體通信成為可能。還有其他大學(xué)，研究組織研究 開發(fā)出來的音頻工具 TAT（ Robust Audio Tool），會議目錄工具 SDR(session directory)，CUSeeMe 音頻會議工具等等。 實時多媒體數(shù)據(jù)傳輸?shù)奶攸c 實現(xiàn)多媒體數(shù)據(jù)傳輸?shù)暮诵氖锹暋⑽?、圖等多媒體信息的傳輸技術(shù)，它的一個顯著特點是數(shù)據(jù)量大，并且許多應(yīng)用對實時性都有比較高的要求，例如，一個多媒體會議系統(tǒng)，我們總是希望發(fā)言者的發(fā)言能夠盡早讓收聽者收聽到，也就是說時延盡量短 ；另外一個就是我們希望在收聽者收聽語音信息時，一句話平滑的，即中間沒有斷點，也就是等時性。但是在大多數(shù)情況下，我們需要再廣域網(wǎng)內(nèi)傳輸數(shù)據(jù)，在這種丟包率較高、網(wǎng)絡(luò)狀況不好的情況下，利用 TCP 協(xié)議進行視頻或音頻通信顯然不是很好的一個選擇。另一方面，音頻、視頻在特定的編碼方式下，產(chǎn)生的編碼數(shù)量是不可能突然改變的，例如，標準的 PCM音頻需要 64Kb/s，加上一些額外控制信息，它不能再低于這個帶寬要求的網(wǎng)絡(luò)上傳輸。所以本文在 IP網(wǎng)絡(luò)上建立的實時音頻傳輸系統(tǒng)采用面向無連接的 UDP 協(xié)議進行傳輸。它是 IETF 提出的一個標準，對應(yīng)的 RFC 文檔為 RFC3550（ RFC1889 為其過期版 本）。一般來說， RTP 是在傳輸層協(xié)議之上作為應(yīng)用程序的一部分加以實現(xiàn)的。如果底層網(wǎng)絡(luò)支持多點傳播的話， RTP 還支持使用多點傳播向多個目的 端點發(fā)送數(shù)據(jù)。 Ier 和其他報文網(wǎng)絡(luò)一樣，會有丟包，報文失序以及報文的不同時延問題。一個與會者離開會議時要發(fā)送 RTCP BYE 報文，以通知其它的參與者自己離開了。 RTP包頭提供了一個字段 CSRC，使混合器可以辨別混合報文的各個信源，這樣在接收端就可以正確獲知誰是發(fā)送者。 第三章 實時語音通信系統(tǒng)簡介 系統(tǒng)平臺 本系統(tǒng)是在 linux 下實現(xiàn)的，選 用 Ubuntu 作為軟件的實現(xiàn)平臺， vim 作為編寫工具，編程語言采用 C++。接收方則對網(wǎng)絡(luò)層傳來的數(shù)據(jù)包解封，并交由 RTP 提取音頻數(shù)據(jù)，然后進行音頻解壓縮，再經(jīng)揚聲器播放出來。采樣嘉應(yīng)學(xué)院畢業(yè)論文 (設(shè)計 ) 13 頻率的選擇應(yīng)該遵循奈奎斯特（ Harry Nyquist）采樣理論：如果對某一模擬信號進行采樣，則采樣后可還原的最高信號頻率只有采樣頻率的一半，或者說只要采樣頻率高于輸入信號最高頻率的兩倍，就能從采樣信號系列重構(gòu)原始信號。采集卡的位是指采集卡在采集和 播放聲音文件時所使用數(shù)字聲音信號的二進制位數(shù)。 出于對安全性方面的考慮， Linux 下的應(yīng)用程序無法直接對聲卡這類硬件設(shè)備進行操作，而是必須通過內(nèi)核提供的驅(qū)動程序才能完成。 OSS/Full 是由 4Front Technologies 開發(fā)并銷售的商業(yè)軟件。與此相反 OSS/Free 驅(qū)動在內(nèi)核層次調(diào)用，需要指定設(shè)備名和調(diào)用 ioctl。 public: void wav_play(int fd)。 //print the params of wav struct void set_pcm_params()。} snd_pcm_uframes_t get_period_size() const { return period_size。 //周期 WAVHeader_t *wav。如果設(shè)備打開成功， pcm_handle 便指向該設(shè)備句柄。 交錯模式 (interleaved)：是一種音頻數(shù)據(jù)的記錄方式，在交錯模式下，數(shù)據(jù)以連續(xù)嘉應(yīng)學(xué)院畢業(yè)論文 (設(shè)計 ) 17 楨的形式存放，即首先記錄完楨 1的左聲道樣本和右聲道樣本（假設(shè)為立體聲格式），再開始楨 2的記錄。 //設(shè)置為交錯模式 switch(bit_per_sample/8) //設(shè)置采樣位數(shù) { case 1:snd_pcm_hw_params_set_format(handle, hw_params, SND_PCM_FORMAT_U8)。 snd_pcm_hw_params_set_rate_near(handle, hw_params, amp。 period_time = buffer_time / 4。 snd_pcm_hw_params_get_period_size(hw_params, amp。 //計算幀大小 chunk_byte = (uint32_t)period_size * bit_per_frame / 8。amp。 } 嘉應(yīng)學(xué)院畢業(yè)論文 (設(shè)計 ) 20 if (r 0) { result += r。 /* EPIPE means underrun */ //perror(underrun occurred\n)。 if ((result = snd_mixer_open(amp。 } 嘉應(yīng)學(xué)院畢業(yè)論文 (設(shè)計 ) 21 } } 音量調(diào)整相關(guān)操作 初始 化麥克風(fēng)及本機音量調(diào)節(jié)器相關(guān)代碼： void CWavPlayer::set_pcm_mixer() { snd_mixer_t *mixer。 snd_pcm_t *handle = ()。 snd_pcm_prepare(handle)。 size_t count = period_size。 snd_pcm_hw_params_get_format(hw_params, amp。 } if (snd_pcm_hw_params_set_period_time_near(handle, hw_params, amp。 if (snd_pcm_hw_params_get_buffer_time_max(hw_params, amp。 case 3:snd_pcm_hw_params_set_format(handle, hw_params, SND_PCM_FORMAT_S24_LE)。 snd_pcm_hw_params_malloc(amp。 （ 2）通道數(shù) (channel)：該參數(shù)為 1 表示單聲道， 2則是立體聲。 if ((rc = snd_pcm_open(amp。 //聲道 uint32_t chunk_byte。operator=(CWavPlayer amp。 void open_pcm_devices(snd_pcm_stream_t mode = SND_PCM_STREAM_PLAYBACK)。 ALSA 音頻編程 ALSA 庫的安裝 在 linux 終端下執(zhí)行： $ sudo aptget install libasound2dev 安裝完畢！ 音頻數(shù)據(jù)的采集和播放的實現(xiàn) 一個典型的音頻程序應(yīng)該具有以下結(jié)構(gòu) ： （ 1）打開音頻設(shè)備 （ 2）為設(shè)備設(shè)置參數(shù)（主要參數(shù)有三個：采樣率、采樣位數(shù)、通道數(shù)） （ 3）向音頻設(shè)備讀 /寫音頻數(shù)據(jù) （ 4）關(guān)閉設(shè)備 Alsa 庫為我們實現(xiàn)這些操作提供了豐富的接口，我們利用 Alsa 接口把語音的采集和播放封裝成一個類 class CWavPlayer，下面是 class CWavPlayer 的部分代碼： class CWavPlayer { 嘉應(yīng)學(xué)院畢業(yè)論文 (設(shè)計 ) 15 public: CWavPlayer(uint32_t sample_rate = 8000, uint16_t bit_per_sample = 16, uint16_t channels = 2)。 ALSA 標準是一個先進的 linux 聲音體系。后來 Hannu 跑去開發(fā) Open Sound System（也就是上面所說的 OSS/Full）。 常用的采樣位數(shù)有 8位、 12 位和 16 位。這個數(shù)值越大，解析度就越高，錄制和回放的聲音就越真實。對于采樣過程中的每一個樣本來說，數(shù)字音頻系統(tǒng) 會分配一定存儲位來記錄聲波的振幅，一般稱之為采樣分辯率或者采樣精度，采樣精度越高，聲音還原時就會越細膩。目前 Linux 已經(jīng)得到了越來越多的應(yīng)用。比如視頻混合器，它可以將多路不同的視頻流的單個圖像混合成一路視頻流，模擬一個群體場景。盡管采用獨立的 RTP 會話，同源的音頻和視頻可以根據(jù) RTCP 的時間信息進行同步回放。 與會者在會議進行期間可能加入或退出，因此了解在某一 時刻有哪些人參加了會議，以及它們的語音數(shù)據(jù)接收情況是很有必要的。一個端口用于 RTP傳輸音頻數(shù)據(jù)，另一個端口用于傳輸 RTCP 控制包。再次，由于 UDP 的傳輸時延低于 TCP，能與音頻和視頻流很好匹配，保證了實時性的要求。 RTP 和 RTCP 配合使用，能以有效的反饋和最小的開銷使傳輸效率最佳化，所以特別適合傳輸實時數(shù)據(jù)。音頻和視頻編碼信數(shù)據(jù)均封裝在 RTP 協(xié)議數(shù)據(jù)包中， RTP 提供定時信息和數(shù)據(jù)報序號，供接收方重組數(shù)據(jù)包，但是 RTP本省并不能為按順序傳送數(shù)據(jù)包提供可靠的傳輸機制，也不提供流量控制或擁塞控制，它依靠 RTCP 提供這些服務(wù)。 RTP 的引入 基于上一節(jié)的分析，我們可以清楚的認識到 TCP 協(xié)議是不適合用來進行傳輸實時多媒體數(shù)據(jù)的，因此考慮選擇 UDP作為 RTP 的