ChatGPT는 프로그래머를 대체하거나 프로그래머에게 버프를 추가합니까?
지난 2주간 AI 소식이 잇따랐다. 또는 생활 속의 챗봇. 빠르면 일주일 전인 3월 15일 새벽, OpenAi는 GPT-3.5 출시 4개월 만에 업그레이드된 모델인 GPT-4를 출시했다. , 그리고 더 강한 쓰기 능력. 3월 16일 직후 Baidu는 문학 창작, 상업 카피라이팅 창작, 수학 논리 계산, 중국어 이해 및 다중 양식 생성의 5가지 기능을 가진 Wenxin Yiyan을 출시했습니다.
최근 주요 제조사들이 AI 제품을 잇달아 출시하면서 인공지능을 AI로 대체하자는 화두가 계속해서 나오고 있다. AI는 인간의 생산성을 크게 해방시킬까요, 아니면 많은 직업에 영향을 미칠까요?
현재 블로거들이 WebRTC 관련 기술 블로그를 출력하고 있으니 AI에게 어떤 인사이트를 가지고 있는지 물어보는 건 어떨까요?
대부분의 사람들과 마찬가지로 블로거는 아직 Bard 및 Wen Xinyiyan에 대한 내부 테스트 자격을 얻지 못했습니다. NewBing이 GPT-4 모델을 사용한다는 것을 알고 있으므로 GPT-3.5 및 Newbing(GPT-4) 에 WebRTC가 오디오 및 비디오 통화의 품질을 개선하기 위해 사용하는 QOS 기술에 대해 질문 하고 답변의 차이점을 살펴보겠습니다.
아래 그림과 같이 GPT-3.5 및 GPT-4는 기술 과학 문제로 인해 어려움을 겪을 수 없습니다. 계속해서 이 문제에 대해 더 깊이 파고들고 예를 들어달라고 요청할 것입니다.
뉴빙(GPT-4)
GPT-3.5에서 제공한 결과
NewBing(GPT-4)이 구체적인 운영 예시를 직접 제공
GPT-3.5에서 제공한 결과(다소 모호함)
GPT-4 및 GPT-3.5 비교 결론
실험을 통해 동일한 질문에 대한 두 가지 버전의 응답을 비교합니다. 일반적인 텍스트 처리에서 GPT-4와 GPT-3.5의 차이는 상대적으로 작을 수 있지만 문제가 충분히 구체적이고 복잡할 때 GPT-4는 GPT-3.5보다 더 정확하고 창의적이며 더 복잡한 문제를 처리할 수 있습니다. 사용자의 문제 미묘한 지침.
물론 이 글의 내용은 GPT-3.5와 GPT-4의 구체적인 차이점을 논의하는 것이 아니라 프로그래머가 ChatGPT를 사용하여 작업 효율성을 높이고 가장 강력한 Buff를 추가하는 방법입니다. 다음으로 저의 개인적인 개발 경험을 바탕으로 오디오 및 비디오 개발자를 위한 " WebRTC의 QOS가 오디오 및 비디오 품질을 향상시키는 방법"을 공유하겠습니다.
WebRTC 기술 개요
WebRTC는 패킷 손실 방지 전략(NACK, FEC), 혼잡 제어 전략(TWCC/REMB), SVC 또는 다중 트랙, 비디오 품질 적응 전략, Pacer, JitterBuffer와 같은 일련의 QOS 기술을 통해 오디오 및 비디오 통화 품질을 향상시킵니다. , 등.
전체 QOS 아키텍처는 아래 그림에 나와 있습니다.
그림 1
1 패킷 손실 복구 전략
1.1 NACK
ACK와 비교하여 NACK(Negative Acknowledgement)는 "미도달 확인"을 통해 선택적으로 재전송하는 메커니즘입니다. 기본 원리는 송신측은 데이터를 캐시하고 수신측은 도착하는 패킷의 연속성을 통해 패킷 손실을 감지하고 rtt 및 out-of-order 조건과 조합하여 적절한 시간에 송신측에 재전송 요청을 시작하는 것입니다. .
그림 2
그림에서와 같이 Receiver는 패킷 4를 수신한 후 패킷 2와 3이 도착하지 않았음을 확인하고 일시적으로 패킷 2와 3을 손실된 nack 목록에 넣습니다. 특정 비순차 임계값을 초과하는 경우(비순차 히스토그램으로 계산, 여기서 2라고 가정하면 패킷 4 수신은 패킷 2 손실로 간주될 수 있음) 또는 특정 지터 시간을 초과하는 경우(에 따라 계산됨) rtt), 보낸 사람에게 손실된 메시지 2, 3을 재전송하도록 요청합니다. 수신자의 요청은 RTP FB를 통해 발신자에게 전달되며 구체적인 NACK 요청 형식은 RFC4585를 참조하십시오. 보낸 사람은 NACK 요청을 받은 후 패킷 2와 3을 다시 보냅니다.
NACK 전략의 패킷 손실 복구 효과는 재전송 요청의 타이밍에 따라 달라진다는 점은 주목할 가치가 있습니다 . 하나는 rtt의 계산(webrtc의 기본 rtt는 100ms)이고 다른 하나는 out-of-order 임계값의 계산입니다. 재전송 요청 리듬을 제대로 제어하지 못하면 재전송 폭풍이 쉽게 발생하여 혼잡이 심화되고 스트리밍 지연이 발생할 수 있습니다.
참고: https://www.rfc-editor.org/rfc/rfc4585.html#page-34
1.2 FEC
FEC(Forward Error Correction), Forward Error Correction은 데이터 전송 및 저장에서 데이터 오류 수정에 일반적으로 사용됩니다. 이 기술은 패킷 손실 복구를 위해 WebRTC에서도 사용됩니다.
webrtc가 이 중복 기능을 구현하는 세 가지 방법이 있습니다.
1.2.1, 레드
이전 메시지를 새 패키지에 직접 넣고 수신 측에서 기본 패키지와 중복 패키지를 분석합니다.
이미지 3
그림에서와 같이 다음 패킷은 이전 패킷을 직접 포함하고 있으므로 패킷 중 하나가 손실되면 인접한 패킷을 통해 직접 복구할 수 있습니다. 이 방법의 단점은 연속 패킷 손실 방지 효과가 좋지 않지만 구현이 간단하다는 것입니다.
Opus In-band FEC는 오류 정정을 위해 이 방법을 사용합니다. 중요한 정보는 더 낮은 비트율로 다시 인코딩되어 후속 데이터 패킷에 추가되고 opsu 디코더는 현재 패킷에 포함된 중복성을 사용할지 여부를 결정합니다. 수신된 패킷 패킷이 손실 및 복구됩니다.
Opus 인밴드 FEC 상세 참조: RFC 6716 - Opus 오디오 코덱 정의
RED 상세 소개 참조: https://www.rfc-editor.org/rfc/rfc2198.html
1.2.2, ULPFEC
XOR은 이 중복 정보를 생성하고 필요한 경우 수신기에서 손실된 패킷을 복구할 수 있도록 여러 패킷 간에 사용됩니다. ULPFEC는 보호할 바이트 수를 선택하고 이전 패킷 수에 XOR을 적용하여 서로 다른 패킷에 대해 서로 다른 수준의 보호를 제공할 수 있습니다.
그림 4
그림과 같이 FEC 패킷 1은 L0 레벨 패킷 A와 B를 보호합니다. FEC 패킷 2는 레벨 L0의 A와 B를 보호하고 레벨 L1의 패킷 C와 D도 보호합니다.
참고: https://www.rfc-editor.org/rfc/rfc5109.html
1.2.3, 플렉스펙
ULPFEC와 비교할 때 FLEXFEC는 1D 행 XOR, 열 XOR 및 2D 행 및 열 XOR을 유연하게 선택하여 네트워크 패킷 손실 방지 기능을 높일 수 있습니다.
1차원 행 XOR 오류 수정
그림 5
1-D 열 XOR 오류 수정
그림 6
2차원 행-열 XOR 오류 수정
그림 7
FLEXFEC는 이전 두 개보다 복구 기능이 더 강하지만 그림 7의 (1, 2, 5, 6)과 같이 행과 열이 인터리브되면 손실로 인해 수정할 수 없는 오류가 발생합니다.
WebRTC에서 사용하는 FEC 전략의 전반적인 패킷 손실 복구 기능은 상대적으로 약합니다. 업계에서는 일반적으로 패킷 손실 복구를 위해 Reed-Solomon FEC를 사용합니다. Reed-Solomon FEC(K + N: K 데이터 패킷 N FEC 패킷)는 모든 것을 진정으로 복원할 수 있습니다. <=N 드롭된 패킷.
FLEXFEC의 자세한 구현은 https://www.rfc-editor.org/rfc/rfc8627.html 을 참조하십시오.
2 대역폭 평가 및 비트 전송률 제어
2.1 REMB-GCC
그림 8
그림 8은 REMB-GCC 아키텍처 다이어그램이며 기본 아이디어는 수신단을 통해 대역폭을 평가한 다음 RTCP REMB를 통해 송신단으로 대역폭을 피드백하는 것입니다. 송신자는 패킷 손실률과 RMEB 결과 Ar을 기반으로 대역폭 결과 As를 계산하고 min(As, Ar)을 최종 대역폭 결과로 취합니다.
2.2 센드사이드 BWE
그림 9
REMB-GCC 와 비교할 때 TFB-GCC의 주요 차이점은 대부분의 대역폭 계산이 원래 계산으로 전송되고 필터 구현이 더 이상 Kalman 필터링을 사용하지 않고 TrendLine 필터 가 된다는 것입니다 .
발신자가 보낸 패킷은 확장 헤더에 포함되어야 합니다. 전송 전체 시퀀스 번호.
수신 측은 메시지 도착 시간, 메시지 도착 시간, 메시지 형식 및 기타 정보를 포함하여 메시지 수신에 대한 정보를 발신 측과 수신 측에 알리기 위해 주기적으로 Transport-wide 피드백 메시지를 보냅니다. Transport-wide 피드백 메시지를 수신한 후 발신자는 메시지에 포함된 정보에 따라 지연 필터링 계산(Trandline)을 수행합니다.
전체 전송 피드백 메시지 형식 참조: https://datatracker.ietf.org/doc/html/draft-holmer-rmcat-transport-wide-cc-extensions-01
2.3 속도 제어
그림 10
그림 11
과부하 검출기에서 생성된 신호 s에 따라 그림 10과 같은 유한 상태 기계가 구동되어 부호율을 조정한다.
GCC 알고리즘 원리 상세 참조: https://c3lab.poliba.it/images/6/65/Gcc-analysis.pdf
3 SVC , 멀티트랙
3.1 SVC
SVC(Scalable Video Coding, Scalable Video Coding or Scalable Video Coding)는 전통적인 H.264/MPEG-4 AVC 코딩의 확장으로 코딩 유연성을 향상시킬 수 있으며 시간적 확장성, 공간적 적응성(Spatial Scalability) 및 품질 적응성(SNR/Quality/Fidelity Scalability).
WebRTC의 h264는 svc 인코딩을 지원하지 않으며 Vp8은 임시 확장성만 지원하고 VP9 및 AV1은 임시 확장성과 공간 확장성을 지원합니다.
그림 12
위는 시간 적응형 다이어그램입니다. 범례에 표시된 레이어가 30fps의 프레임 속도로 표시된다고 가정합니다. 모든 L2 이미지를 제거해도 나머지 레이어(L0 및 L1)는 여전히 성공적으로 디코딩되어 15fps 비디오를 생성할 수 있습니다. L1 이미지를 모두 삭제하면 나머지 L0 레이어는 여전히 디코딩되어 7.5fps 비디오를 생성할 수 있으므로 패킷 손실이 있더라도 확장 불가능한 인코딩에 비해 취약한 네트워크에서 비디오 유창성을 크게 향상시킬 수 있습니다.
그림 13
그림 12와 같이 L0 베이스 레이어는 최소 해상도로 인코딩된 데이터이며 레벨이 높을수록 해상도가 높아진다. 실제 응용 프로그램에서 더 낮은 해상도가 필요한 경우 디코딩을 위해 높은 수준의 데이터만 버려야 합니다.
대역폭 조건과 장치 성능이 다른 사용자는 해상도를 유연하게 조정할 수 있습니다.
SVC 확장 참조: http://ip.hhi.de/imagecom_G1/assets/pdfs/Overview_SVC_IEEE07.pdf
H264 참조와 결합된 SVC: https://www.itu.int/rec/T-REC-H.264-201704-I
3.2 멀티트랙
현재 주류 브라우저는 통합 계획 sdp를 지원합니다. SDP 협상 중에 여러 비디오 트랙을 추가할 수 있습니다. 두 개의 비디오 트랙을 추가하고(SVC의 공간 확장성과 유사) 동일한 DTLS 전송 채널을 재사용하는 것이 비즈니스에서 더 일반적입니다. .
그림 14
그림 12는 다중 트랙 기능에 대한 WebRTC의 지원을 사용하여 일반적으로 인코딩되는 하나의 스트림, 하나의 스트림 및 하나의 스트림, 하나의 스트림과 하나의 스트림의 프레임 출력에 대한 개략도입니다.
여러 비디오 트랙(대형 및 소형 스트림)을 지원하면 다운링크 대역폭이 제한될 때 수신 측에서 지원되는 해상도로 동적으로 전환할 수 있어 취약한 네트워크 경험을 개선할 수 있습니다.
멀티 뷰 트랙(크고 작은 스트림)은 네트워크 패킷 손실 및 대역폭 제한에 적응하는 데 SVC만큼 유연하지 않지만 멀티 뷰 트랙은 구현이 쉽고 인코딩 및 디코딩 성능 소모가 적기 때문에 널리 사용됩니다. 실제 비즈니스 시나리오에서 사용됩니다.
멀티트랙은 통합 계획 SDP 협상을 지원해야 합니다. WebRTC 관련 지침을 참조하십시오: https://webrtc.github.io/webrtc-org/web-apis/chrome/unified-plan/
4 비디오 품질 조정 전략
네트워크 전송 품질이 좋지 않은 경우(업링크 대역폭 부족), 높은 CPU 점유율, 높은 인코더 코딩 품질 QP 값 등의 경우 WebRTC는 화상 통화를 보장하기 위해 품질을 낮춥니다. 품질 감소 전략은 주로 프레임 속도 감소(즉, 명확한 우선 모드)와 해상도 감소(즉, 부드러운 우선 모드)로 나뉘며, 이는 MediaStreamTrack 콘텐츠 힌트를 통해 설정됩니다.
선명도 우선 모드 WebRTC는 인코딩 시 비디오 세부 사항에 더 많은 주의를 기울입니다.위에서 언급한 상황으로 인해 품질을 낮춰야 하는 경우 스트리밍 사용자의 주관적인 경험을 보장하기 위해 프레임 속도를 줄이고 해상도를 변경하지 않고 유지합니다. 스트리밍 측의 화면 공유 콘텐츠가 스트리밍 사용자를 위해 PPT 또는 대형 화면에 표시되는 비즈니스 시나리오에서 특히 중요합니다.
유창성 우선 모드: 스트리밍 터미널이 품질을 낮춰야 할 때 스트리밍 사용자의 원활한 경험을 보장하기 위해 먼저 해상도를 낮추고 특정 프레임 속도를 유지합니다.
대역폭 또는 CPU 리소스가 더 이상 제한되지 않으면 WebRTC는 품질 감소 기본 설정에 따라 비디오 품질을 역으로 향상시킵니다.
사용자는 자신의 비즈니스 시나리오에 따라 적절한 설정을 하여 극단적인 경우에도 주관적인 경험이 나쁘지 않도록 해야 합니다.
5 페이서
WebRTC의 Pacer 모듈은 주로 예상 네트워크 대역폭에 따라 각 전송 시간 창에서 패킷이 가능한 한 균등하게 분산되도록 하여 패킷을 원활하게 전송하고 네트워크 정체를 방지합니다.
5Mbps 및 30fps의 비디오 스트림이 있다고 가정합니다. 이상적으로 각 프레임은 크기가 약 21kB이고 18개의 RTP 패킷으로 압축됩니다. 1초 동안의 평균 비트 전송률은 5Mbps이지만 더 짧은 시간 동안에는 33밀리초마다 167Mbps의 버스트로 볼 수 있습니다. 또한 비디오 엔코더는 갑작스러운 움직임의 경우, 특히 대상 크기보다 10배 또는 100배 더 큰 프레임이 일반적인 화면 공유를 처리할 때 대상 프레임 속도를 초과할 수 있습니다. 이러한 패킷을 인코딩되자마자 전송하면 네트워크 정체, 버퍼 팽창, 심지어 패킷 손실과 같은 몇 가지 문제가 발생할 수 있습니다. 대부분의 세션에는 오디오 스트림, 비디오 스트림 및 데이터 스트림을 동시에 포함할 수 있는 둘 이상의 미디어 스트림이 있습니다. 하나의 전송 채널에서 한 번에 하나의 프레임을 전송하면 해당 패킷을 전송하는 데 100ms가 걸리므로 오디오 패킷이 제때 전송되지 않을 수 있습니다. Pacer는 버퍼를 사용하여 이 문제를 해결합니다. 미디어 패킷이 대기열에 들어간 다음 Leaky Bucket 알고리즘을 사용하여 네트워크에서 조정됩니다. 버퍼에는 모든 미디어 트랙에 대한 별도의 fifo 스트림이 포함되어 있습니다. 예를 들어 오디오는 비디오보다 우선 순위를 지정할 수 있습니다. 동일한 우선 순위의 스트림을 라운드 로빈 방식으로 전송하여 하나의 스트림이 다른 스트림을 차단하지 않도록 할 수 있습니다.
그림 15
6 지터버퍼
그림 16
WebRTC 수신 측이 RTP 패킷을 수신한 후 캐싱 및 정렬을 위해 PacketBuffer에 넣습니다. 위 그림과 같이 마크(프레임 끝) 플래그를 수신한 후 뒤에서 앞으로 프레이밍을 시작합니다. 프레임을 어셈블한 후 프레임이 위치한 GOP의 캐시에 넣고 프레임 간 참조 시퀀스에 따라 조정하고 프레임 간 참조 관계가 설정되면 디코더에 다음을 위해 넣습니다. 디코딩. Jitter는 주로 패킷 정렬, 프레임 정렬, GOP 정렬을 순차적으로 수행한다고 볼 수 있다. 일련의 작업을 하는 이유는 네트워크 자체에 일정량의 지터가 있고 심지어 패킷 손실이 있기 때문에 패킷 손실이 있으면 패킷 손실이 복구될 때까지 기다려야 합니다. 따라서 프레임 도착 시간과 전송 시간 사이에 일정량의 지터가 있습니다. 지터 버퍼의 존재는 이 문제에 대한 좋은 해결책이며 스트리밍 끝에서 디코딩된 데이터를 매끄럽게 하여 렌더링된 비디오가 부드럽고 매끄럽게 되도록 할 수 있습니다.
7 키 프레임 요청
비디오 스트림은 일반적으로 디코딩 및 표시를 위해 이전 프레임에 의존하는 1개의 키 프레임 + N 증분 프레임의 형태로 전송됩니다. 어떤 이유로 sps/pps 손실, 패킷 오류 등이 발생한 경우, 아무런 조치를 취하지 않으면 비디오 스트림 디코딩을 계속하기 어렵고 비디오는 다음 키 프레임까지 고정됩니다. 많은 경우 인코딩 안정성을 위해 GOP 설정이 매우 크며 이는 장시간 정지 또는 블랙 스크린을 의미합니다.
그림 17
그림에서와 같이 수신단은 패킷 손실로 인해 프레임 9번 프레임까지 실패하여 복구가 불가능하며, 프레이밍에 성공하더라도 복호가 불가능하므로 이때 I 프레임 디코딩을 요청해야 한다. 현재 비디오 스트림을 새로 고치기 위해 끝을 보냅니다.
WebRTC는 RTCP 메시지를 통해 발신자에게 키 프레임을 보내도록 요청합니다. 키 프레임 요청 RTCP 메시지 형식은 비교적 간단합니다. 두 가지 다른 키 프레임 요청 메시지 형식은 RFC5104(RTP/AVPF) 및RFC4585 현재 구현에서 WebRTC는 PLI 또는 FIR을 수신한 후 인코더에 키 프레임을 인코딩하고 출력하도록 요청한 다음 수신측으로 보냅니다.
PLI 메시지 형식 참조: https://www.rfc-editor.org/rfc/rfc4585.html#page-36
FIR 참조: https://www.rfc-editor.org/rfc/rfc5104.html
QOS 기술 요약:
이 기사에서는 다양한 각도에서 Qos 품질을 향상시키는 WebRTC에서 사용되는 Qos 기술을 간략하게 소개합니다. NACK 및 FEC 기술을 통한 패킷 손실 복구 및 패킷 손실로 인한 오디오 및 비디오 정지 해결을 포함합니다. 대역폭 평가 및 혼잡 제어 기술을 통해 인코딩 및 전송 비트 전송률을 조정하여 네트워크 대역폭의 변화에 자동으로 적응합니다 . SVC 및 멀티트랙 기술을 통해 서로 다른 네트워크 품질 스트리밍 사용자에게 서로 다른 비디오 품질을 보장할 수 있습니다. Pacer와 JitterBuffer는 송신측과 수신측에서 각각 오디오와 비디오의 부드러움과 유창함을 향상시킵니다 . 키프레임 요청은 극단적인 네트워크 지터 이후 빠른 비디오 복구에 중요한 역할을 합니다. WebRTC는 이러한 기술의 시너지 효과를 사용하여 전반적인 QoS 품질을 향상시킵니다.기술 세부 사항을 이해하는 가장 좋은 방법은 WebRTC 소스 코드를 읽는 것입니다.
WebRTC의 Qos 기술은 전반적인 오디오 및 비디오 품질 향상에 상당한 영향을 미치지만 이러한 WebRTC 기술에는 여전히 최적화할 여지가 많습니다. 오디오 및 비디오 제조업체 ZEGO의 자체 개발 WebRTC 게이트웨이는 자체 개발 대역폭 평가 알고리즘, NACK 알고리즘, 크고 작은 흐름을 포함하여 이러한 전략을 어느 정도 최적화했습니다.
따라서 비즈니스에 안정적이고 안정적인 오디오 및 비디오 서비스가 필요한 경우 실시간 오디오 및 비디오 RTC 서비스를 사용해 볼 수 있습니다.
WebRTC 모범 사례에 대해 자세히 알아보려면 클릭하여 ZEGO로 이동하여 실시간 오디오 및 비디오 서비스를 구축하세요 .