黑色好看版 - 傳送門

正文開始

之前的八篇文章中，我們已經理解完聲音與影像的採集與編碼原理，並且也簡單的進行 Web 方面的採集實作，接下來咱們就要開始進入網路的部份，而這部份最主要探討的主題為：

別人要如何聽的到我的聲音呢 ?

基本上這題的大約有三種思路，而這也是本篇文章的三個章節：

• 將聲音檔案直接丟給對方 ( 方法 1 )
• 將聲音檔案以串流的方式傳送給對方 ( 方法 2 )
• 像直播一樣即時的將聲音傳送給對方 ( 方法 3 )

備註

讓對方看的到影像的方法也與聲音相同，所以這裡就以聲音為例來進行說明。

將聲音檔案直接丟給對方 ( 方法 1 )

這個是最原始的一種方法，它就是將檔案丟給對方，然後等對方全部下載完後，才能聽到聲音，概念圖如下：

但是實作上的概念圖應該是如下圖，基本上在即時通訊軟體上，不太會是 client 與 client 進行 P2P 連線來直接丟聲音檔案，例如 line 之類的通訊軟體，因為它都要支援離線傳輸，因此架構實際上應該是會選擇將檔案丟到 server 然後再發送個通知給對方說有個檔案你可以下載。

這種作法基本一小段的聲音檔還行，但如果是要傳送一段很長的聲音或影像檔(ex 電影)，那基本上這個方法的缺點就會被放大，因為它要全部下載完你才可能看或聽，而且占空間，並且如果是音樂或電影，說不定還有版權的問題，因為這也代表你有音樂檔，可以分享給其它人。

這也是為什麼後來誕生了串流傳輸的技術囉。

將聲音檔案以串流的方式傳送給對方 ( 方法 2 )

串流用比較白話文一點的說話就是:

它是一種將資料一段一段的丟給去給你，而不會將所有的資料。

詳細的串流說明可以去筆者之前寫的文章『Node.js 的串流之旅之基本概念』

那這樣有什麼好處理 ?

基本上有以下幾個好處：

• 客戶端可以一邊下載一邊收聽。
• 不會花費客戶端的儲存空間，它會將一小段一小段的聲音傳送到客戶端的緩衝記憶體中，然後播放器會去記憶體中讀取後並播出，然後再捨棄掉。
• 由於客戶端沒有實際上儲放檔案，因此不會有一些音樂或影片版權的問題 (有檔案就可以傳來傳去)。

然後咱們這個方法的實作概念圖大概如下。

上面的簡易架構圖有一些東西咱們要來理解一下。

首先 (2) 要先將聲音檔案轉成『流容器』。

為什麼呢 ?

一般的音樂或影片檔案容器就如下圖一樣，由表頭與表身組成，然後基本上在所有的資料都傳輸完以後，你才可以根據他的表頭來知道這個音樂或影像是用什麼編碼，這樣你才可以解碼，然後才可以開始聽音樂。

而流容器你可以想成，它就是一個檔案中有很多塊表頭加表身，每一次傳輸資料時，都是一組表頭加表身過去( 如下圖 右邊的 A )，所以可以一邊傳送一邊的聽音樂或看影像。

咱們在之前的文章的『30-06之聲音與影像的封裝』文章中，已經有列出那些容器是屬於流器，就是裡面寫串流的那個就是流容器。

(4) (5) 要使用拉流傳輸協議。

先問為什麼呢要傳輸協議呢 ?

假設你將一個流容器檔案慢慢的傳輸給對方，那我想問問，你傳送的這個東西過來我要做什麼事情呢 ? 這就是為什麼我們需要協議，因為有了協議，對方才知道要做啥。

再來什麼是拉流呢 ?

它就是 server 在有媒體源時 (ex. 聲音 or 影片)，會透過流媒體傳輸協議來拉取媒體。接下來的章節會專門介紹這些傳輸協議。

像直播或網路電話一樣即時的將聲音傳送給對方 ( 方法 3 )

最後就是可以像直播或網路電話一樣，別人在說話時，你也同時能聽到對方的聲音。

基本上這裡的方法一樣也是需要使用串流傳輸，不過這裡還需要用到推流傳輸協議，為了將主播這裡的聲音或影像推送給 server，它的概念和上傳檔案不同，它是將聲音一小段一小段上傳，然後同時間用戶端可以一小段一小段的將聲音拉過來播放。

結論

本篇文章中，咱們學習了以下三種讓對方聽的到聲音的方法。

• 將聲音檔案直接丟給對方 ( 方法 1 )
• 將聲音檔案以串流的方式傳送給對方 ( 方法 2 )
• 像直播一樣即時的將聲音傳送給對方 ( 方法 3 )

要實現這三個方法最主要的事情就是協議，沒有協議完全無法就聲音傳送給對方，接下來的幾篇文章，咱們會將即時影音通訊世界中常使用的所有協議都完全的理一次。

參考資料

• 串流媒體(Stream Media))
• 百度-流媒體
• 流文件和媒体文件的不一样( flv和mp4,avi的区别)