使用HTTP進行實時音頻流傳輸-選擇協議和Java實現

Question

我正在嘗試為實時音頻（在Java中）實現簡單的HTTP服務器。 假設有一個網站，您可以在其中看到一首又一首播放的歌曲列表。 當客戶端連接到服務器時-在歌曲的中間說-我正在考慮使用“ Range” HTTP標頭，並從歌曲的該部分開始發送數據范圍。 但是，如果在下載過程中連接暫時丟失（歌曲已完成）-服務器應該發送先前的歌曲部分並完成它-還是服務器應該發送當時正在播放的那些歌曲部分？ 什么是最佳做法/原則？

PS-我不是在尋找音頻流的第三方軟件。

編輯：
現在，在對可用的實時流技術進行了一些研究之后，我看到了以下目標：
1.為簡單的實時音頻流選擇協議
2. Java中的協議實現（服務器端）

Answer 1

您不能隨意剪切媒體並期望播放器能夠播放它。 這適用於裸露的MPEG流，但是其他容器和編解碼器可能會遇到麻煩。 因此，除非客戶端已經擁有其余文件，否則不要發送部分文件。

您還遇到了當歌曲結束並轉到下一首時該怎么辦的問題。

有兩種方法可以實現此目的。 一種方法是讓客戶端可以使用靜態媒體，然后在音頻客戶端尋求正確的時間。

我選擇的方式是真正創建一個互聯網廣播流，使每個人都在同一時間聽到同一件事，因為您實際上擁有一個公共緩沖區，該緩沖區大約在同一時間從所有客戶端復制並發送給所有客戶端。 現在，如果您執行此操作，則將需要使用支持任意拼接（MP3或AAC）的編解碼器/容器，或者在將流發送到客戶端時用容器重新包裝流。 這是一個復雜的問題，所以最好使用像Icecast這樣的現成的東西來做。 我知道您說您不是在尋找第三方解決方案，但這是最好的方法。 如果您想自己完成所有操作，則必須重新實現所有功能，或者僅支持MPEG流。

編輯：從您的評論：

您能否解釋一下有關數據流格式的更多信息，即[24,576字節的流] [元塊] [24,576字節的流] [元塊]等。如何分離塊，元塊的內容是什么？

如果願意，可以將SHOUTcast樣式的元數據混入流中。 並非所有客戶都支持。 如果這樣做，他們將在請求中向您發送以下標頭：

Icy-MetaData: 1

如果看到該標頭和值，則可以選擇在流中包括元數據。 元數據僅在流數據的每個塊之后注入。 要包含元數據，首先需要確定流塊的大小。 相距太遠，元數據無法與流很好地對齊。 兩者之間的距離太近，從理論上講您正在浪費帶寬（但不會浪費太多，因為不變的元數據塊只有一個字節長）。 我通常堅持使用8KB。 看到16KB有時是32KB的情況並不少見。 在響應頭中輸出該塊大小（元數據間隔）：

Icy-MetaInt: 8192

首先，將8192字節（8KB）的音頻流數據發送到客戶端。

現在是時候使用元數據塊了。 以字符串開頭，如下所示：

StreamTitle='This is my stream title';StreamUrl='';

您可以傳入StreamUrl甚至其他字段，但是這些天客戶實際上只使用StreamTitle。 （ StreamUrl曾經能夠通過大寫一些字母或某物來彈出瀏覽器，我不敢肯定會記得觸發器是什么。不再使用它。）然后將此字符串轉換為緩沖區並填充空字節（ 0x00 ）到最接近的等分的16塊。也就是說，如果元數據塊的字符串版本長51字節，則您需要將其長64字節，因此將添加13字節的NUL填充。

關於字符集的快速注釋。 許多客戶端在其元數據中支持UTF-8。 有些沒有。 另外，如果必須在元數據中使用撇號' ，則需要對其進行轉義。 不幸的是，似乎沒有真正的標准方法來做到這一點。 反斜杠有時會起作用。 有時重復角色是可行的。 不同的玩家有不同的工作方式。 試用Winamp並查看其喜歡之處，因為這可能與您獲得的“官方”內容差不多。 其他一切可能只是一個壞客戶。 （如果您想變得非常狡猾，則可以從User-Agent請求標頭中確定客戶端，並相應地調整轉義。）

現在您已經有了元數據塊，您只需要在它的前面添加一個字節，指示它的長度，除以16 。 因此，如果現在擁有64字節的元數據，則將字節0x04添加到它的前面，這表明我們的元數據長度為64字節。 這總共提供了一個65字節的元數據塊，我們現在將其發送給客戶端。 發送。

從這里開始，我們再次進入循環，在插入元數據之前發送另外8KB的流數據。 但這一次，因為我們不想更改元數據，所以我們只發送0x00作為我們的元數據塊。 同樣，由於第一個字節指示塊的長度，並且我們不更新標題，所以請告訴客戶端該長度為0 。 我們僅在發生變化時才發送字符串。