用於高速音頻/視頻流的套接字和端口設置

我在服務器和客戶端之間建立了一對一的連接。該服務器正在流式傳輸實時音頻/視頻數據。用於高速音頻/視頻流的套接字和端口設置

我的問題聽起來很奇怪，但我應該使用多個端口/套接字還是隻有一個？使用多個端口速度更快還是單個端口性能更好？我應該只有一個端口用於消息，一個用於視頻，另一個用於音頻，或者將整個事件封裝在單個端口更簡單嗎？

我目前的一個問題是，我需要首先發送當前幀的大小，因爲大小 - 以字節爲單位 - 可能會從一幀改變到下一幀。我對網絡相當陌生，但我還沒有找到任何機制可以自動檢測正在傳輸的特定對象的正確範圍。例如，如果我發送一個2934字節長的數據包，我是否真的需要告訴接收方該數據包的大小？

我第一次嘗試打包幀的速度與它們進入時一樣快，但是我發現接收端有時候不會得到適當數量的字節。大多數情況下，它的讀取速度比我發送的速度快，只能獲得一個部分幀。儘可能快地獲得適當數量的字節的最佳方法是什麼？

還是我看起來太低，有一個更高級別的類/框架用於處理對象傳輸？

你應該做的最大的事情是完全忘記*數據包*。 TCP連接是**流**，因此任何數據描述都需要由*你*（協議）來處理。 –

另外，UDP *數據報*通常用於流式傳輸。 –

@JonathonReinhart：這可能是一個流，但我需要在數據包或幀中切斷它，否則客戶端將只處理垃圾 - 半幀或重疊幀。我根本不知道做這件事的最好或最有效的方法是什麼。顯然，我需要做的不僅僅是推動管道中的數據，並希望獲得最好的結果。 – LightStriker

我認爲使用對象機制並以交錯方式發送數據會更好。這種機制可能比多端口機制工作得更快。

例如：

類數據{ 數據類型， - （阿迪奧/視頻）尺寸， - （所述數據緩衝器的大小）數據緩衝器 - （數據取決於類型） }

'DataType'和'Size'的大小始終保持不變。在客戶端採用'DataType'和'Size'，然後讀取相應發送數據（Adio/Video）的指定大小。

2013-07-11 06:11:06

但是從一個幀到另一個幀的大小從來就不是恆定的。你是否在說我應該浪費帶寬來獲得恆定的對象大小？ – LightStriker

只是讓我的頭頂上的東西。推「包」像這樣沿着電線：

1 byte - packet type (audio or video) 
2 bytes - data length 
(whatever else you need) 
| 
| (raw data) 
|

所以每當你在另一端，這些包之一，你知道到底有多少數據讀取，以及下一個包的開始應該開始。

[430 byte audio L packet] 
[430 byte audio R packet] 
[1000 byte video packet] 
[20 byte control packet] 
[2000 byte video packet] 
...

但爲什麼重新發明輪子？有protocols已經做這些事情。

2013-07-11 06:14:56

RTSP聽起來像是我在搜索中缺少的東西。非常感謝我指出了這一點。 – LightStriker

回答