고속 오디오/비디오 스트리밍을위한 소켓 및 포트 설정

Question

서버와 클라이언트 사이에 일대일 연결이 있습니다. 서버가 실시간 오디오/비디오 데이터를 스트리밍합니다.

내 질문에 이상하게 들릴 수 있지만 여러 포트/소켓 또는 하나만 사용해야합니까? 여러 개의 포트를 사용하는 것이 더 빠르지 않습니까? 아니면 하나가 더 나은 성능을 제공합니까? 메시지 용 포트, 비디오 용 포트 및 오디오 용 포트가 있어야합니까? 아니면 모든 포트를 단일 포트에 패키지하는 것이 더 간단합니까?

현재의 문제 중 하나는 크기 (바이트)가 한 프레임에서 다음 프레임으로 변경 될 수 있으므로 현재 프레임의 크기를 먼저 보내야한다는 것입니다. 나는 Networking에 상당히 익숙하지만, 전송되는 특정 객체에 대한 정확한 범위를 자동으로 탐지하는 메커니즘을 발견하지 못했습니다. 예를 들어 2934 바이트의 긴 패킷을 보내면 실제로 그 패킷의 크기를 수신기에 알려야합니까?

처음에는 들어오는 프레임을 최대한 빨리 포장하려고했지만 수신 측에서 적절한 바이트 수를 얻지 못하는 것으로 나타났습니다. 대부분의 경우, 내가 보낸 것보다 더 빨리 읽을 것이고 부분적인 프레임 만 얻습니다. 바이트 수를 가능한 한 빨리 얻는 가장 좋은 방법은 무엇입니까?

너무 낮 으면서 객체 전송을 처리하는 데 사용되는 상위 클래스/프레임 워크가 있습니까?

Answer 1

개체 메커니즘을 사용하고 인터리브 된 방식으로 데이터를 보내는 것이 더 좋습니다. 이 메커니즘은 여러 포트 메커니즘보다 빠르게 작동합니다.

예 :

수준의 데이터 { 데이터 형식, - (ADIO/비디오) 크기, - (데이터 버퍼의 크기) 데이터 버퍼 - (데이터 유형에 따라 다름) }

'데이터 유형'과 '크기'는 항상 일정한 크기입니다. 클라이언트 측에서는 'DataType'과 'Size'를 가져 와서 해당 전송 데이터 (Adio/Video)의 지정된 크기를 읽습니다.

Answer 2

그냥 내 머리 꼭대기에서 뭔가를 만들어. 당신이 다른 쪽 끝에서이 패킷 중 하나 얻을 때마다

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이 있습니다.