建設IP語音從零

Question

我一直想建立一個非常簡單的IP語音程序，我想過通過這個創建它：

我將錄製麥克風和每2秒（或者它應該是甚至1秒？）將它放入一個字符串（語音數據），通過套接字發送到另一側，另一側將自動播放sent'd字符串。

這是主要的想法，但我想我會改變一兩件事..

的主要問題是 - 將它足夠快？我不是在尋找一個像Skype這樣的超快速VOIP，而是一些不錯的東西......比如說2秒deley（例如我說話後，2秒鐘後另一個人會聽到我）或者類似的東西...

它會很糟糕嗎？也許我應該使用一個實現VOIP的開放庫？ 因爲我真的想做出點從我自己......

通過，我將使用C++的方式，當然使用UDP協議發送數據包...

那麼做您認爲 ？

Answer 1

我不認爲我會這樣做。簡單的事實是，在傳輸之前收集兩秒鐘（或甚至一秒）的語音數據會讓你失去很多並且什麼都不會讓你獲益。

與正常開放協議相比，您可以通過很多地方簡化協議。典型的協議有多種傳輸速率，存在檢測，NAT穿越，多種編解碼器等的各種選擇。這使得正常的語音聊天程序相對複雜。通過消除其中的大部分，只需預先選擇一組選項，就可以簡化代碼。

然而，每隔幾毫秒發送一次數據包的難度就是而不是。每隔幾秒發送一次數據包不會讓你的代碼更簡單。如果有的話，它可能會使代碼更復雜，因爲你必須處理存儲相當多的數據。在典型情況下，您一次只處理幾千字節的數據，因此存儲幾乎完全不成問題。如果在傳輸之前存儲大量數據，那麼存儲數據將會變成一個更爲重要的問題（儘管公平地說，它仍然不會非常困難）。我個人認爲我仍然會使用一些標準的編解碼器，所以如果你決定這麼做的話，代碼和協議將會很容易（或者更容易）擴展到更完整的東西。例如，如果我想讓事情儘可能簡單，那麼我可能會先使用G.711編解碼器。即使支持兩種形式的壓縮（mu-law和A-law），所以我可能會選擇其中一種（可能是A律），然後使用它。

使用它，實際的編解碼器（壓縮/擴展代碼）應該低於100行代碼（可能接近50行，具體取決於您更喜歡如何格式化代碼）。如果你願意，你可以從ITU下載參考實現G.191（注：G.191還包括許多其他編解碼器的代碼）。

這給你一定程度的壓縮幾乎是免費的。同樣重要的是，這意味着您需要構建代碼，以便在發送數據之前有一個地方調用編碼器對數據進行編碼，並在收到數據後解碼數據。如果你決定增強代碼，你最終會選擇一個不同的編碼器/解碼器，而不是試圖添加一個之前沒有的編碼器/解碼器（在這種情況下，你很可能需要完全重寫）。

G.711旨在一次對樣本緩衝區進行操作。支持的緩衝區大小爲40,80,160和320個樣本。如果你不關心延遲，320個樣本將是明顯的選擇。使用它，您可以從輸入（麥克風）中讀取320個樣本，將其發送到壓縮器，並將結果輸入到UDP數據包中，然後通過網絡發送。根據需要重複。您可能想要在UDP數據包中包含序列號，以便接收端可以按順序播放數據包。再次，我可能會遵循一個標準。 RTP是微不足道的，它可能只增加了幾十行代碼左右（甚至可能比這少）。

爲了儘可能簡化接收代碼，可能會最初忽略整個RTP頭，然後只接收一個數據包，解碼有效載荷，播放它並重復。之後，如果發現數據包丟失和重新排序是個問題，您可以添加代碼來查看序列號和/或時間戳，並據此採取相應措施。

這裏的重點是等待2秒（或其他）不會讓你的代碼更簡單。如果有的話，一次處理一個固定的（並且相當小）的樣本可能會使代碼更簡單。您可以預先分配一些您關心的大小的緩衝區，然後使用它們，而不是像處理動態分配那樣緩衝一次數據。

Answer 2

如果您在發送音頻之前等待2秒鐘，它將不會像對話一樣。如果延遲超過100毫秒，也許是200毫秒，那麼人們會很惱火。其次，VoIP應用通常意味着與其他人交談。直到你的應用程序實現了世界主導地位，它可能是一個很好的主意，以支持已建立的VoIP協議（H.323或SIP）之一，所以你可以與其他人交談。只是一個想法。