WebRTC 가장 낮은 atency

Question

RAW H264 비디오 프레임을 사용하는 간단한 UDP 스트리밍 프로토콜이 있으며이 프로토콜을 사용하여 서버 측에서 클라이언트 측으로 즉시 전송합니다.이 프로토콜을 사용하여 네트워크 RTT 대기 시간 (패킷을 다시 보내지 않고 보내지 않음)을 얻을 수 있습니다 패킷 손실에 대한 관심), 그래서 만약 내가 클라이언트에서 20ms 대기 시간이 클라이언트에 (디코딩 준비가) 인코더 출력 준비가 될 수있는 비디오 프레임을 만들 수 있습니다 ..... 30ms 말할 수 있습니다.

제 질문은 : - 이러한 종류의 대기 시간을 줄일 수있는 WebRTC (UDP를 통한)입니까? 인코딩 및 디코딩 시간을 고려하지 않고 프로토콜 계층에 대해 WebRTC를 사용할 수있는 가장 낮은 대기 시간은 얼마입니까?

이런 종류의 대기 시간이 내 자신의 프로토콜을보다 심도 깊게 개발해야하는지 또는 모든 웹 브라우저에서 즉시 지원할 수 있도록 내 비디오 서버 개발을 위해 WebRTC와 같은 좀 더 일반적인 것으로 갈지는지 모르겠습니다.

안부,

Answer 1

WebRTC는 일반 SIP/RTP 스택과 동일한 대기 시간을 가질 수 있습니다. WebRTC 스택 공급 업체가 지연을 줄이기 위해 최선을 다하고 있습니다.

녹음 및 전송에 지연이 없습니다. 스택은 레코더 장치에서받은 패킷을 즉시 보내고 선택한 코덱으로 압축합니다. 일부 코덱 (및 일부 코덱 설정)은 FEC과 같은 일부 기능을 사용하기 위해 여기에 약간의 지연을 도입 할 수 있습니다.

수신 측 : 최적의 상황에서는 스택이 패킷 재생을 지연 시켜서 도착하자마자 바로 표시 할 수 없습니다. 그러나 (네트워크 지연 또는 패킷 손실과 함께) 최적 이하 환경에서는 스택에 jitter buffer이 도입됩니다. 네트워크 품질이 낮을수록 지터 버퍼 길이가 길어집니다.

그래서, 가장 낮은 지연을 달성하기 위해, 당신은 다음을 할 필요가 있습니다

• 는
• 은 FEC를 제거하고 추가 지연이 발생할 수있는 다른 설정을 사용하지 않도록 최소 처리 시간을 가진 코덱을 선택
• 지터 버퍼 제거 (대부분의 WebRTC 스택에는이 설정이 없으므로 코드를 직접 수정해야하지만 코드 일부만 비활성화하면되므로 쉽게 수정할 수 있습니다)

Answer 2

WebRTC가 일반 UDP에 비해 페이로드의 시작 부분에 단지 작은 추가 헤더가 기본 미디어 전송 등 RTP를 사용합니다. 이는 일반 UDP로 달성 한 것과 동등해야 함을 의미합니다. RTP는 실시간 오디오 및 비디오 (SIP, H.323, XMPP의 미디어 전송)와 같이 대기 시간이 중요한 환경에서 많이 사용되므로 대기 시간이이 용도로 충분할 것으로 기대할 수 있습니다.