에픽게임즈는 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가 이미지 퀄리티와 비트레이트에 미치는 영향
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에 맞춰 언리얼 애플리케이션을 빌드하는 것이 훨씬 간단하고 저렴합니다.
일대일 스트리밍에서 최적의 퍼포먼스 달성하기
일대일 사용 사례는 픽셀 스트리밍의 가장 간단하면서 일반적인 형태로, 한 명의 사용자가 하나의 픽셀 스트리밍 인스턴스에 연결합니다. 픽셀 스트리밍 환경설정에 대한 자세한 내용은 호스팅 및 네트워킹 가이드를 참조하세요.
일대일 스트리밍에서 최적의 설정을 논의하기 전에 최상의 픽셀 스트리밍 경험을 만들 때 고려할 지표를 정의해야 합니다. 가장 중요한 지표는 다음과 같습니다.
- (사용자와 스트리밍 경험 사이의) 지연시간
- (사용자가 수신하는) 비디오 퀄리티
- 다양한 네트워크 조건에 따른 스트리밍 안정성(빠르게 손실된 패킷 일부를 처리하고 복구할 수 있는지 여부).
지연시간
최적의 지연시간을 달성하려면 다음 아키텍처를 사용해야 합니다. 직접 피어 투 피어 (SFU 또는 미디어 서버 없음), 그리고 픽셀 스트리밍 인스턴스는 가능한 한 사용자와 지리적으로 가까워야 합니다.

위 다이어그램은 낮은 지연시간에서 최적의 픽셀 스트리밍 환경설정을 보여줍니다. 최종 사용자는 UDP를 통해 픽셀 스트리밍 인스턴스에 직접 연결됩니다.
고려 사항
- UDP에서 퍼블릭 인터넷을 통해 UE 인스턴스에 연결할 수 있어야 합니다.
- 최종 사용자의 네트워크 환경설정에서 알 수 없는 IP 주소를 사용하여 UDP를 통해 통신할 수 있어야 합니다. WebRTC 측면에서 NAT가 극복할 수 있고 퍼블릭 IP가 교환될 수 있도록 두 컴퓨터 사이에 STUN 서버가 있어야 합니다.
- 이를 수행할 수 없는 사용자의 경우 TURN(릴레이) 서버를 사용할 수 있지만 지연시간이 P2P 사용자보다 좋지 않게 됩니다.
- 이 환경설정은 다수의 WebRTC 피어가 다양한 퀄리티에서 동일한 스트림을 봐야 하는 경우 효과적이지 않습니다 (자세한 내용은 SFU 환경설정 관련 문서 참조).
비디오 퀄리티
픽셀 스트리밍과 같은 비디오 우선 WebRTC 경험에서 비디오 퀄리티는 가장 강력한 조정 파라미터일 수 있습니다. 누구도 블록이나 픽셀이 보이는 경험을 원치 않지만 다양한 네트워크의 광범위한 사용자에게 일관되고 안정적인 경험을 제공하고자 합니다. 이를 위해 다음 사항을 고려해야 합니다.
- 허용 가능한 최소 해상도는 무엇인가요?
- 이 해상도에서 허용 가능한 최소 비트레이트는 무엇인가요?
- 비주얼 퀄리티, 안정성 또는 지연시간이 더 중요한가요?
비디오 퀄리티가 증가하면 경험에 필요한 비트레이트가 증가하여, 적지만 중대한 재전송 패킷을 처리하기 위해 지터 버퍼가 증가함에 따라 패킷이 손실되거나 대기 시간이 늘어나게 되면 경험의 안정성이 떨어지고 멈춤 현상에 취약해집니다.
따라서 성공적인 경험을 위해 최소 비디오 퀄리티를 신중하게 고려해야 합니다. 추가로 이 최소 퀄리티가 결정되면 사용자를 대상으로 신중하게 현장 시험을 실시한 경우를 제외하면 스트리밍 퀄리티가 이 상한을 초과하지 않도록 해야 합니다.
사용자를 대상으로 한 몇 차례의 실험과 패킷 손실, 지터, 버퍼 지연 및 비트레이트 같은 주요 지표 측정을 기반으로 하는 데이터에 따라 결정을 내리는 것이 중요합니다.
하지만 데이터가 없는 경우 다음을 시작 지점으로 삼을 수 있습니다.
- 1080p 비디오 스트림( -ResX=1920, -ResY=1080, -ForceRes, -Windowed )
- 10메가비트/초 최대 인코딩 퀄리티( -PixelStreamingWebRTCMaxBitrate=10000000 )
- 필요한 경우에만 키 프레임 전송( PixelStreamingEncoderKeyframeInterval=0 )
안정성
비디오 스트림 안정성은 다음 기술을 통해 높일 수 있습니다.
- 최대 비트레이트 감소
- 인코딩 도중 중복 정보 추가(
-PixelStreamingEncoderIntraRefreshPeriodFrames=300 -PixelStreamingEncoderIntraRefreshCountFrames=5
) - 협상된 제안/해답에 Flex-FEC 포함(예: Chrome, Firefox)
경험에서 안정성이 얼마나 중요한지와 사용자가 멈춤 현상과 지터 버퍼를 얼마나 자주 경험하는지에 따라 이러한 지표를 미세하게 조정할 수 있습니다.
일반 속도 권장 사항
속도 권장 사항은 경험을 어떻게 조정하느냐에 따라 다르지만 1080p에서 H.264 비디오 스트림에 대한 일반적인 가이드라인은 다음과 같습니다.
사용자 네트워크 연결:
- 10~20메가비트/초: 좋은 비주얼 퀄리티 경험
- 1.5~10메가비트/초: 저사양의 경우 네트워크 변동에 따라 사용자가 비주얼 퀄리티에서 인식할 수 있을 정도의 변화를 경험할 수 있음(예: 움직임 중에는 보이던 픽셀화가 비디오 정지 시에는 사라짐)
- 0.5~1.5메가비트/초: 사용자가 픽셀화를 경험
- 0~0.5메가비트/초: 사용할 수 없을 가능성이 높음.
이는 비디오 퀄리티, 지연시간 및 안정성 관련 목표에 따라 다릅니다.
스트림 퀄리티를 떨어뜨리는 요인
몇 가지 요인으로 인해 스트림 퀄리티가 떨어지게 될 수 있습니다. 하지만 가장 일반적인 요인은 다음과 같습니다.
- 사용자 측에서 달성 가능한 최대 네트워크 속도가 목표 비디오 퀄리티에 비해 너무 느림
- 사용자 네트워크 상태가 좋지 않고 간헐적/단발성으로 패킷 손실이 발생함
- 스트리밍 인스턴스와의 지리적 근접성(추가 지연시간으로 인해 패킷 손실 가능성이 높아질 수 있고, 이로 인해 WebRTC에서 비트레이트를 줄여 스트리밍 경험 안정화를 시도할 때 스트림 퀄리티가 떨어질 수 있음)
- 경험의 디폴트 비디오 퀄리티가 사용자 네트워크 연결에 비해 너무 높고, 패킷이 손실되면서 지터 버퍼가 증가해 초기에 스트림 적응 기간 동안 비트레이트가 감소함
- TURN/릴레이 서버에서 지연시간과 추가 패킷 손실 지점(UDP) 또는 패킷 재전송(TCP)이 발생
- 미디어 서버/SFU에서 지연시간과 추가 패킷 손실 지점 발생
- 잘못 구성된 미디어 서버/SFU로 인해 비트레이트 추상화와 픽셀 스트리밍으로 전달되지 않는 제어 메시지 발생. 따라서 스트리밍 소스에서 연결된 피어의 사용 가능한 상태로 경험을 조정하는 데 필요한 피드백이 업데이트되지 않습니다.
WebRTC 최적화 삼각형

일부 스트리밍 시나리오에서는 원하는 결과를 달성하기 위해 스트림 세팅을 최적화해야 할 수 있습니다.
지연시간, 비디오 퀄리티 및 스트림 안정성은 스트림 제공자가 필요에 따라 스트림을 조정하기 위해 최적화할 수 있는 세 가지 중요 파라미터입니다. 네트워크 제한으로 인해 서로 연결되어 있기 때문에 다른 파라미터 하나 또는 두 가지를 줄여야 하는 경우가 있습니다.
기본적으로 픽셀 스트리밍은 이러한 환경설정에서 최적의 균형을 제공하려고 하며, 위 그림과 같이 사용자의 연결에 맞춰 조정합니다.
퀄리티와 안정성을 대가로 짧은 지연시간 최적화하기

VCam 픽셀 스트리밍과 같은 로컬 스트리밍의 경우, 짧은 지연시간에 맞춰 스트림을 최적화하고 안정성과 비디오 퀄리티를 낮추는 게 더 이득이 될 수 있습니다. 이는 다음과 같은 파라미터로 달성할 수 있습니다.
-PixelStreamingEncoderTargetBitrate=10000000
-PixelStreamingWebRTCDisableFrameDropper
-PixelStreamingWebRTCVideoPacingFactor=100
이 예시에서는 네트워크 조건에도 불구하고 비트레이트를 목표치인 10메가비트/초로 고정하고, 네트워크 정체가 발생하더라도 프레임 드롭을 비활성화하여 항상 프레임을 전송하며, 비디오 페이서의 값을 관대하게 설정하여 대량의 패킷을 수락합니다. 이를 통해 네트워크 조건과 무관하게 지연 없이 패킷을 전송할 수 있어 지연시간이 최소화됩니다. 이 환경설정은 네트워크 속도 제한이 더 강한 인터넷에서는 권장되지 않으며, 프레임 드롭과 패킷 페이싱은 다양한 네트워크 조건에서 원활한 경험을 달성하는 데 도움이 됩니다.
지연시간과 안정성을 대가로 퀄리티 최적화하기

또 다른 스트리밍 시나리오, 예를 들어 스트림 제공자가 고급 제품 컨피규레이터에 대해 특정 비주얼 퀄리티를 목표로 하는 경우 지연시간과 안정성을 떨어뜨리는 대신 퀄리티를 최적화하는 게 유리할 수 있습니다. 이는 다음 환경설정을 사용하여 달성할 수 있습니다.
-PixelStreaming.Encoder.MaxQP=20
이 환경설정은 인코더의 최대 압축을 제한하여(값이 낮으면 이미지 압축이 떨어짐) 최소 비디오 퀄리티가 직접적으로 보장됩니다. 하지만 사용자의 네트워크 연결에서 이 비트레이트를 처리할 수 없는 경우 멈춤 현상과 지연시간 증가가 발생합니다.