에픽게임즈는 Google이 WebRTC 버전에서 공개한 취약성을 알고 있으며, EOS SDK에 미치는 영향과 향후 단계에 대해 조사하고 있습니다. 자세한 내용은 여기를 참고하세요.
픽셀 스트리밍의 디폴트 환경설정은 스트리밍이 인터넷에서 디플로이되고 이를 사용자가 다양한 네트워크 조건에서 소비한다는 가정하에 스트리밍의 이미지 퀄리티와 지연시간, 탄력성의 균형을 유지할 수 있도록 만들어져 있습니다. 이 가정에 해당하는 상황에서는 픽셀 스트리밍 환경설정을 변경하지 않아도 됩니다. 하지만 픽셀 스트리밍은 유연한 기술로, 그 밖의 상황에서도 사용할 수 있습니다. 이 가이드에서는 픽셀 스트리밍에서 퀄리티, 지연시간, 탄력성을 유지하는 방법을 설명하고 이미지 퀄리티, 지연시간, 탄력성을 위한 최적화가 균형 잡힌 스트리밍보다 중요한 경우에 대한 가이드를 제공합니다.
WebRTC
픽셀 스트리밍에서 이미지 퀄리티, 지연시간, 탄력성 사이의 균형을 맞추는 과정은 대체로 WebRTC라는 기술을 통해 이루어집니다. WebRTC는 Facebook Messenger, Discord, Amazon Chime, Google Stadia 등 화상 회의와 실시간 스트리밍에 널리 사용되고 있습니다. WebRTC는 낮은 지연시간, 문제 방지, 멀티미디어 및 다수의 참여자 간 데이터 전송을 위해 설계된 기술입니다.
픽셀 스트리밍에서 WebRTC 참여자로는 픽셀 스트리밍을 사용하는 언리얼 엔진 애플리케이션과 WebRTC를 사용할 수 있는 일부 클라이언트, 대표적으로 웹 브라우저가 있습니다. WebRTC는 사용 사례의 폭이 넓기 때문에 사례별로 정해진 환경설정이나 모드가 없습니다. 대신 WebRTC는 네트워크 조건과 리소스 제약을 바탕으로 퀄리티, 지연시간, 탄력성의 균형을 맞추려고 시도합니다.
하지만 특정한 요구사항을 가진 사용자의 경우 이미지 퀄리티, 지연시간, 탄력성 중 하나를 우선시할 수 있도록 몇몇 파라미터가 노출되어 있습니다.
세 조건 중 하나를 우선시하면 다른 두 조건이 영향을 받습니다. 이 방법이 적절한지는 사용 사례에 따라 결정하시기 바랍니다. 아래 섹션에서는 다음과 같은 작업의 가이드를 제공합니다.
이미지 퀄리티
비디오 스트리밍의 이미지 퀄리티를 결정하는 것은 결국 언리얼 엔진 이미지가 WebRTC에 의해 전송되기 전에 인코딩되는 과정에서 얼마나 압축되는지입니다. 이 압축은 픽셀 스트리밍 애플리케이션 내부에서 이루어지며, 기본적으로 WebRTC가 완전히 제어합니다.
WebRTC 인코더 비트레이트 적응
WebRTC는 반복적으로 픽셀 스트리밍 애플리케이션과 WebRTC 클라이언트 사이에서 가용 네트워크 대역폭을 결정하고, 적절한 비트레이트 값을 계산하여 비디오 스트리밍 인코더에 최신 비트레이트 추정치를 업데이트합니다. 그러면 비디오 스트리밍 인코더는 이 비트레이트를 상한선으로 사용하여, 이를 초과하지 않는 인코딩된 이미지만 생성합니다.
이 시스템에서는 네트워크 조건이 나쁘면 블록이나 픽셀이 보일 정도로 많이 압축된 이미지가 만들어지고, 네트워크 조건상 고퀄리티 비디오 스트리밍을 재생할 수 있을 때는 덜 압축된 이미지가 만들어집니다. 즉, 이 시스템은 네트워크 조건에 적응하여 비디오 스트리밍의 압축을 조절합니다.
네트워크 조건과 무관하게 이미지 퀄리티 유지하기
이미지 퀄리티 유지를 위해서는 -PixelStreamingEncoderMaxQP=N 을 사용합니다. N은 1부터 51까지의 정수입니다.
QP의 의미와 이 파라미터의 영향은 아래에서 설명합니다.
비디오 스트리밍의 이미지 퀄리티를 실제로 결정하는 유일한 요인은 비디오 스트리밍 인코더의 압축입니다. 주어진 프레임의 압축은 '양자화 파라미터(quantization parameter, QP)'라는 지표를 사용하여 측정합니다. 픽셀 스트리밍에서 사용되는 인코더의 QP는 1~51입니다.
- 1: 퀄리티가 가장 높은/압축률이 가장 낮은 인코딩
- 51: 퀄리티가 가장 낮은/압축률이 가장 높은 인코딩
기본적으로 이 QP 범위에는 제한이 없으므로, 비디오 스트리밍 인코더는 WebRTC가 전달해 준 목표 비트레이트를 바탕으로 적절한 QP를 선택할 수 있습니다. 하지만 고품질 제품 컨피규레이터처럼 절대 퀄리티가 낮은 이미지를 생성해서는 안 되는 경우에는 인코더가 사용할 수 있는 QP 범위를 제한하고 싶을 수도 있습니다.
MaxQP의 제한으로 생성된 비트레이트가 네트워크 조건이나 -PixelStreamingWebRTCMaxBitrate를 초과한다면 프레임 드롭이 발생하며 스트리밍되는 프레임 레이트가 줄어듭니다.
픽셀 스트리밍 비디오 인코더 QP는 다음을 사용하여 실행 인자로 제어할 수 있습니다.
-PixelStreamingEncoderMinQP=-PixelStreamingEncoderMaxQP=
보통 이미지 퀄리티를 바운드할 때는 MaxQP만 변경하면 됩니다. 특히 움직임이 있을 때는 애플리케이션 시각 요소를 얼마나 압축할 수 있는지에 따라 애플리케이션에 맞는 MaxQP가 달라지므로 실험을 통해 적절한 MaxQP를 찾아야 합니다. 하지만 경험상 압축률에 상한선을 적용하고자 하는 대부분의 사용자에게는 20 정도의 MaxQP가 적절했습니다.
전송되는 비트레이트와 QP는 픽셀 스트리밍과 함께 제공되는 페이지 내 세팅"/"통계 패널 또는 Chromium 기반 브라우저의 chrome://webrtc-internals, Firefox의 about:webrtc에서 추적할 수 있습니다.
아래 이미지는 QP가 이미지 퀄리티와 비트레이트에 미치는 영향을 나타낸 것입니다.
QP impact on image quality and bitrate
QP와 비트레이트는 로그 관계로 이루어져 있습니다. 즉, QP가 4에서 5로 바뀌면 20에서 21로 바뀌었을 때보다 비트레이트에서 더 큰 차이가 나타납니다.
지연시간
픽셀 스트리밍의 지연시간는 여러 요인에 의해 좌우됩니다. 어떤 요인은 제어할 수 있지만, 그렇지 않은 요인도 있습니다. 최종 사용자의 디바이스 하드웨어, 공용 인터넷, 빛의 속도는 제어할 수 없지만, 픽셀 스트리밍의 지연시간에 영향을 미치는 그 밖의 몇 가지 요인은 제어할 수 있습니다. 다음 섹션에서는 제어 가능한 요인을 집중조명합니다.
가능한 최소 지연시간 달성
지연시간을 최소화하려면 다음과 같은 요인을 조정해야 하지만, 경우에 따라 조정 시 스트리밍 퀄리티와 탄력성이 영향을 받을 수 있다는 점을 명심하세요.
| 지연시간 요인 | 가이드 |
|---|---|
| 선택된 비디오 인코더입니다. | 실험 단계의 VP8/VP9 소프트웨어는 하드웨어 가속 H.264 인코더보다 높은 지연시간을 유발하므로 사용하지 않습니다. |
| 애플리케이션의 지리적 위치입니다. | 가급적 타깃 사용자와 지리적으로 가까운 곳에서 픽셀 스트리밍 애플리케이션을 호스트합니다. 여러 지역에서 호스팅이 필요할 수 있습니다. |
| 애플리케이션 호스트에 사용하는 하드웨어 | GPU에서 하드웨어 가속 H.264 인코딩을 지원하는 하드웨어를 권장합니다. 또한, WebRTC 전송 스레드에 스톨이 발생할 수 있으므로 사용이 100%가 되지 않도록 타깃 CPU의 애플리케이션을 프로파일링하는 것을 권장합니다. |
| 최대 비트레이트 및 해상도입니다. | 해상도와 최대 비트레이트를 낮추면 데이터 전송량과 인코딩 복잡도가 낮아져 인코딩, 패킷화, 디코딩이 빨라집니다. 이 방법을 통한 지연시간 감소는 보통 퀄리티를 포기할 정도로 크지 않습니다. |
| 오디오 및 비디오 동기화입니다. | 오디오/비주얼 비동기화를 감수할 수 있다면 오디오와 비디오를 별도의 스트림으로 전송하는 -PixelStreamingWebRTCDisableAudioSync 로 지연시간을 향상할 수 있습니다. |
| 오디오를 비활성화합니다. | 오디오가 필요하지 않다면 -PixelStreamingWebRTCDisableReceiveAudio 및 -PixelStreamingWebRTCDisableTransmitAudio 로 오디오 전송을 비활성화하여 대역폭을 절약합니다. |
| 모션 블러 또는 씬 복잡도를 비활성화합니다. | 어떤 씬에서는 모션 블러처럼 비주얼 복잡도를 높이는 이펙트를 비활성화하면 인코딩 복잡도를 크게 줄여 비트레이트를 낮출 수 있습니다. |
일반적으로 지연시간을 가장 크게 줄일 수 있는 방법은 지리적 근접성을 확보하고 픽셀 스트리밍 애플리케이션과 사용자 사이의 네트워크 퀄리티를 높이는 것입니다.
탄력성
여기서 탄력성은 패킷 손실, 네트워크 지터, 데이터 손상이 존재할 때 스트리밍의 안정성을 뜻합니다. WebRTC는 스트리밍 탄력성 관리를 위해 동적으로 조정되는 여러 내부 메커니즘을 사용하고 있습니다. 예를 들어, WebRTC는 수신한 패킷을 저장할 때 사용하는 '지터 버퍼'의 크기를 높여 지연시간을 희생하는 대신 네트워크 딜레이와 재전송을 보완할 수 있습니다. 지터 버퍼는 직접 제어할 수 없지만, 그 외에도 데이터 중복을 통해 스트리밍 탄력성을 높일 수 있도록 비디오 스트리밍 인코딩 과정에서 제어할 수 있는 요인들이 있습니다.
네트워크 악조건에도 탄력적인 스트리밍 만들기
픽셀 스트리밍의 비디오 스트리밍 탄력성은 아래 요인을 조정하여 높일 수 있습니다.
| 탄력성 요인 | 가이드 |
|---|---|
| 인코더 키프레임 간격 | 키프레임 전송 시 큰 데이터 손실 이후 스트리밍과 디코더의 복구가 가능합니다. 키프레임을 전송하는 간격은 키프레임은 정상 프레임 이상의 대역폭을 필요로 하지 않으므로 네트워크 포화로 인한 패킷 손실의 경우 전송 키프레임을 늘려도 도움이 되지 않을 수 있습니다. |
| 인코더 프레임 간 새로 고침 | 비디오 스트리밍 복구 정보를 여러 프레임 슬라이스에 걸쳐 인코딩할 수 있습니다. 이 정보는 데이터 손실 시 스트리밍 탄력성을 높이는 데 도움이 되지만, 스트리밍 내내 더 많은 대역폭을 소모하게 되고 스트리밍 복구가 이루어질 때 스캔라인형 아티팩트가 발생합니다. 이 옵션은 현재 NVIDIA GPU에서만 사용할 수 있으며, 픽셀 스트리밍에서 |
일반적으로 스트리밍 탄력성에 가장 큰 영향을 주는 요인은 네트워크 퀄리티와 전송되는 데이터의 양입니다. 따라서 탄력성을 높이기 위해 픽셀 스트리밍 애플리케이션이 퀄리티를 희생해도 괜찮다면 QP 범위 제한을 없애 전송되는 데이터의 양을 줄이거나 애플리케이션 해상도를 줄이는 것도 방법입니다.
픽셀 스트리밍을 위해 애플리케이션 최적화하기
다음은 픽셀 스트리밍을 위해 애플리케이션을 최적화하기 위한 추가 권장 사항입니다.
-
씬에 필름 그레인을 사용하는 포스트 프로세스를 추가하면 컬러 밴딩 아티팩트를 크게 줄일 수 있지만 대역폭이 증가합니다.
-
지연시간 증가를 감수할 수 있고 픽셀 스트리밍 애플리케이션당 여러 피어를 지원하지 않는다면
-PixelStreamingEncoder=를 사용해 H.264와 동일한 비트레이트로 더 나은 퀄리티의 인코딩을 제공하는 실험 단계의 VP8/VP9 소프트웨어 인코더를 사용할 수 있습니다. - 하나의 GPU로 여러 픽셀 스트리밍 애플리케이션을 구동하는 멀티 테넌시(multi-tenancy)를 사용하려면 애플리케이션을 무겁게 프로파일하거나 프레임 레이트/해상도 하락을 감수해야 할 수 있습니다.
- 클라우드로 애플리케이션을 광범위하게 구동하려는 경우, Kubernetes와 같은 기술에서 훨씬 폭넓게 지원되는 Linux에 맞춰 언리얼 애플리케이션을 빌드하는 것이 간단하고 저렴합니다.