2009-05-17 74 views
5

我正在製作能夠播放目標廣告的流媒體服務器。基本上聽衆聽到的是同樣的音樂,但是每隔30分鐘就會有一塊廣告,每個聽衆都有自己的音樂。實現這樣的流媒體服務器帶來了各種問題,這個問題是關於其中之一的。如何無縫連接MP3流?

服務器將以類似於Icecast的方式工作,即它將從某個流生成器通過網絡讀取流並將其中繼給每個聽衆。當需要廣播廣告時,服務器會停止從生成器中獲取流,從文件中讀取廣告並將其插入每個聽衆的緩衝區,然後傳輸它們並從發生器中繼流繼續。

當服務器從中繼流切換到廣播廣告時,它必須連接兩個MP3流(我們用MP3播放)。我擔心的是,簡單地將一段數據附加在一起可能會產生一些可聽到的文物。它可以無縫地完成嗎?

我已經想通了: - 我可以讓服務器知道MP3幀以避免同步錯誤。 - 我正在考慮在流中的MP3幀之後從廣告文件中追加MP3幀。 - 由於廣告是從正確編碼的MP3文件加載的,因此我避免了字節庫的問題,因爲文件的第一幀無法使用它。

但我關心的是MDCT的工作方式。聽衆不知道我的服務器會做什麼,所以他們的MP3解碼器可能會產生一些文物,因爲不正確的MDCT數據將被一個接一個地放在他們下載的流中。在廣告文件的開頭將零填充補償這一點嗎?

您是否知道任何可以無縫連接兩個MP3文件而無需解壓縮的庫/工具(如果可能,開放源碼)?

你能指出任何描述MP3格式的好資源嗎?我搜索了很多互聯網,發現了很多信息,但我仍然想念整個畫面。

也許你知道,如果我使用另一個像OGG/Vorbis,AAC這樣的編解碼器,這會更容易些。

PS。這個問題不是What is the best way to merge mp3 files?的重複。 mp3wrap和工具都不是我的選擇。

回答

0

如果您使用的是Windows,則可能需要使用Microsoft DirectShow API。你應該發現它能夠以靜態和流媒體的方式處理各種格式的音頻和視頻(你只需要必要的編解碼器,而且接口幾乎相同)。這麼說,DirectShow不幸的是設計錯綜複雜,而且學習曲線陡峭,但如果您要在Windows上進行音頻/視頻處理,它提供的功能是不平行的。然而,有很多關於如何使用它的示例和教程,所以最終可能不會那麼痛苦。另外,如果您使用.NET Framework,則會有一個名爲DirectShow.NET的託管。無論你做什麼,這都不是一件容易的事,除非我沒有意識到的東西。無論如何,祝你好運!

+0

這樣的API可能計算起來太昂貴了。我工作的電臺已經有5萬用戶/服務器的高峯流量。即使只有一秒鐘的音樂,我必須爲每個聽衆處理,這是超過一小時的音樂解壓縮/壓縮在任何時間... – Jasiu 2009-05-17 20:46:07

+0

我不知道它肯定會...你應該真的做一些更深入的調查,因爲DirectShow是*在Windows上用於媒體內容的方式。 – Noldorin 2009-05-17 20:59:40

2

我相信MP3可以通過簡單連接文件進行合併。在一些快速測試(cat file1.mp3 file2.mp3 > merged.mp3; mplayer merged.mp3)它似乎按預期工作。從Web服務器流式傳輸可能也會起作用。

你打算如何處理切換當前輸入文件?您可以簡單地將廣告視爲短軌道來播放。

+0

是的,這就是我想要去的方式,但是您確定它的工作原理,並且在任何情況下都不會產生聽覺故障? – Jasiu 2009-05-17 20:43:43

0

我走近一個非常類似的問題,並要求在各種渠道正確的問題後,提出了以下...

,直到達到一個有效的幀頭任何值得解碼器將跳過「壞」數據。這是ID3v2依賴於將附加信息注入mp3數據的內容。在服務器上,我會分析源MP3文件,只提供有效的MP3幀。如果您提供了一些靜音幀(大約7幀應該​​這樣做),那麼解碼器在加載下一個加載的(未關聯的)MP3數據之前應該有時間解決,避免在連接來自不同編碼的幀時您(正確地)假設的假象會話。

更大的問題是在一幀到下一幀之間可能會切換MP3屬性(1/2通道,輸出採樣率等)。有些解碼器遇到這樣的流時會很煩躁,導致1/2速播放等。所以,你需要確保你所有的源材料都被編碼爲相同的輸出屬性,否則你可能會被剝離。

您可能已經看到了這一點,但如果沒有:

http://www.devhood.com/tutorials/tutorial_details.aspx?tutorial_id=79&printer=t

0

我不明白你爲什麼會想連接的文件。你爲什麼不使用某種播放列表系統,只是改變你發送的文件。我認爲這樣可以在長期內實現更大的靈活性,而且不會產生大量的MP3文件。

2

你應該能夠連接CBR和VBR格式的MP3文件。 MP3文件沒有主標題(不考慮ID3和Xing)。音頻數據以塊的形式存儲,其中每個塊都包含它自己的頭。頭部包含用於解碼該塊中的音頻數據的必要信息(比特率,採樣頻率,立體聲等)。

這是難以確定mp3文件的持續時間的原因之一。

查看它的另一種方法是,如果將CBR MP3文件與VBR文件連接起來,則最終結果與具有恆定比特率的第一段音頻的一個長VBR文件相同。

問題是,一些MP3播放器可能是嚴格的,並期望一個VBR MP3文件邢頭。然而,這從來不是MP3格式的規範,但現在假定它是真實的。