오래된 SW 엔지니어의 평생 공부

Game Streaming 서비스 비교

Game Streaming 서비스가 다양해 지고 있다. [1]에는 최근 Game Streaming 서비스를 비교하고 있다. 이러한 서비스는 스마트 폰과 같은 수신기기에서 서버로 부터 게임 화면을 스트리밍 받아서 지원하는 기술이다. 실재로 WebRTC와 보다 더 짧은 Latency 요구 사항이 요구 된다. 이러한 기술은 대부분 서비스 별로 다르기 때문에 상세 내용이 공개 되어 있지 않다. 하지만, Parsec이라는 기술은 이 상세 내용에 대해서 약간의 정보를 제공하고 있으므로 이를 살펴 보고 특징을 이해할 수 있다.

Parsec 개요

Parsec은 Free Game Software이다. 위에서 설명한 것과 같이 Streaming 방식으로 할 수있게 해준다. 지원이 종료되었지만, 삼성의 PlayGalaxy라는 서비스도 이를 활용한 것이다. [2]에는 Android 및 iOS SDK가 제공된다. Source Code는 제공되지 않는다.

Parsec 기술 설명

Parsec에서는 20ms으로는 아주 훌륭한 게임 경험을 할 수 있지만 40ms만 되어도 사용할 수 없다고 한다. 이는 WebRTC가 1초 미만의 수백 ms의 요구 사항이었다고 보면 이 요구 사항은 이 보다 한단계 더 낮은 Latency를 요구하는 서비스라고 생각할 수 있다.

[3]에서는 Parsec이 동작하는 방식을 설명하고 있다. 

1. Capture raw desktop frames
2. Encode the raw frames
3. Send the encoded frames over the network
4. Decode the frames
5. Render the frames on the screen

1번에서는 Windows 8.1부터 빠른 캡춰를 가능하게 한다고 한다. 2의 경우는 nVidia와 같은 빠른 인코더를 사용해서 성능을 높이고 있다고 한다. 

Codec의 경우는 H.264의 60fps 설정이 저지연으로 동작한다고 한다. 또한 Codec의 인터페이스 사용을 직접하여 지연도 줄인다고 한다.

이렇게 처리된 데이터는 화면에 Rendering되게 되는데, 데이터를 GPU상에서 모두 처리하게 되면 지연이 준다고한다. Memory Copy와 Color coversion등이 효율화 항목 중 하나이다.

네트워크 성능도 중요한데, 아래 그림과 같이 Local에서 하는 것과 Cloud에서 하는것의 성능 차이가 상당히 있다. 5G Network의 Mobile Edge Computing(MEC)를 사용하는 것도 장점이 있을 것이다. 이러한 이유로 xCloud등이 모바일 사업자와 협력하는 것이 이유가 있다고 볼 수 있다.

아래 그림에서와 같이 nVidia와 AMD의 코덱 성능에는 차이가 상당히 있다. 그렇기 때문에 nVidia를 사용하는 것이 Game Streaming에 성능에 차이가 있을 수 있다. 그리고, Encoder쪽의 성능 차이가 중요한 부분일 수 있다고 생각된다.

성능 최적화

nVidia의 코덱을 사용하더라도 설정을 잘 못하면 성능의 차이가 나올 수 있다. [6]에서는 nVidia Codec의 목표에 따른 코덱 최적화 방법을 설명한다. 아래 표가 

상기 테이블의 내용 중 아래 옵션들은 관련된 주요 파라미터 설정에 대한 설명을 포함한다.

-bf set maximum number of B frames between Non B frames (default 0)

-rc-lookahead Number of frames to look ahead for frametype and ratecontrol

-b bitrate video bitrate (pelease use –b:v)

-bufsize set ratecontrol buffer size (in bits)

-g set the group of picture (GOP) size. 999999 is about 44h with 60fps

-maxrate Set maximum bitrate tolerance (in bits/s)

-tune zerolatency

특히, B frame의 사용 여부, bitrate할당 방법의 차이 그리고 GOP 크기등을 통해서 주요한 설정 방법에 대해서도 가늠해 볼 수 있다.

정리하며...

Game Streaming은 이야기 한데로, 표준이 아니면서도 극단적인 스트리밍 요구 사항이 포함되어 있어 매우 흥미롭지만 내용이 많은 내용이 공개 되어 있지 않은 문야이다. 점차 Client의 계산 능력으로는 충분하지 못하고 Cloud에서 힘을 빌려야 하는 응용이 늘어 날 수록 이 기술은 적용 범위가 확대 될 것이므로 기본적인 이해가 필요하다고 생각된다.

참고 자료

[1] Game Streaming 서비스 비교, https://www.clien.net/service/board/lecture/14562043

[2] Parsec SDK; https://github.com/parsec-cloud/parsec-sdk

[3] Parsec Description: https://blog.parsecgaming.com/description-of-parsec-technology-b2738dcc3842

[4] Parsec Introduction to Video Codec, https://blog.parsecgaming.com/an-introduction-to-video-compression-c5061a5d075e

[5] New Nvidia GPUs Outperform New AMD Cards On H.264 Compression Latency, https://blog.parsecgaming.com/new-nvidia-gpus-outperform-new-amd-cards-on-h-264-compression-latency-d32784464b94

[6] Turing H.264 Video Encoding Speed and Quality, https://devblogs.nvidia.com/turing-h264-video-encoding-speed-and-quality/

이 글은 오래전 Wowza에서 발간한 가이드 문서[1]를 살펴 보고 실시간 인터액티브 스트리밍의 구조 관련 내용을 정리하려고 한 것이다. 우선은 일반적인 실시간 연동이라고 하면, Live 방송을 해야 하고, 사용자에게 Interaction을 받아서 이를 처리하여야 한다. 그러므로, 일반적인 Pipeline을 설명하고, 관련된 비디오 스트리밍 프로토콜에 대해서 설명하려 한다.  사용자 인터액션에 대한 처리를 원할히 하기 위해서는 저지연, 즉 Low Latency까지 이야기 되어야 한다.

일반적인 Live Streaming 서비스 구조

우리가 YouTube 혹은 Facebook을 이용하여 라이브 방송하는 구조를 생각할 수 있다. 복잡한 장비를 사용하여 TV 방송 수준 품질의 방송을 하던, 아주 간단하게 휴대폰을 활용하던, 실재 Streaming을 위한 구조는 대동 소이하다.

Live Video Streaming의 경우는, 아래 그림과 같이 First Mile에서는 카메라에서 동영상을 비디오를 촬영하면 이를 전송 가능한 형태로 인코딩한다. 아직까지 일반적으로는 H.264를 많이 사용한다. 이를 처리하기 위한 서버로 전송하는데 아래 그림에서는 Processing 혹은 Ingestion이라고 한다. 이를 위해 전송하는 프로토콜은 RTMP, RTSP/RTP 혹은 SRT를 사용한다고 한다. 

위에서 이야기 한데로 YouTube 혹은 Facebook이 Live 기능을 제공하기 시작하면서 개인 방성 기술에 대해서 여러 접근 법이 있었다. 그리고, 주로 많이 사용되는 것은 한번 상용화가 되기 시작하니 우후 죽순 처럼 RTMP[1] 기술이 주류처럼 나왔지만, 정말 오래된 기술 중 하나인 RTSP/RTP도 사용되고 있다.

처리된 콘텐츠들은 서비스 특징에 따라 전송 방법들을 달리한다. 위의 그림은 YouTube와 같이 많은 사용자들이 볼 수 있는 형태인 DASH 혹은 HLS로 변환하여 Content Delivery Network (CDN)을 통해 배포 하는 사례를 보여 준다.

지연 요구 사항에 따른 Streaming Protocols

아래 그림은 다양한 지연 요구 사항에 따른 Last Mile 처리 Protocol의 사례를 보여 준다. 

처음 이야기 한 것과 같이 HLS, DASH는 일반적으로 많이 사용되고 있다. 많은 비디오 스트리밍 구성들이 캡춰에서 재생까지 30초 이상의 지연(Latency)을 가진다. 쉽게 말하면, YouTube에서 라이브로 보고 있는 내용들인 대부분 30초 전에 일어난 일이라는 것이다.

저지연이면서도 많은 사람들에게 전송하기 위한 Protocol Tuning을 하기 위해서 최적화 작업을 하는 업체들이 많다. 위에 그림에서 볼 수 있듯이 그렇다 하더라도 5초 이상의 지연을 가지게 된다.

이러한 노력에 추가하여, 프로토콜 표준상 최적화를 위해서 Low Latency HLS와 CMAF를 채용한 DASH가 제안되기도 했다. 기본 개념은 HLS/DASH에서 수신하는 작은 조각 (Fragment 혹은 Chunk)라고 불리는 것들을 작게 만들어 수 초대의 지연으로 만들어 일반 방송과 유사한 수준까지 만드는 것이다.

그렇다면, 이보다 낮은 방법은 없는 것인가? Wowza에서는 WebRTC를 제안하고 있다. 하지만, 이는 Peer-To-Peer 방식으로 콘텐트 소비자의 가까운 곳에 Computing Resource를 할당 하는 등 HLS/DASH 기반의 다른 방식에 비해서 비용이 높을 수 있다.

정리

위의 그림 하나로 모두 정리 된다고 볼 수 있지만, 사용자 인터렉션의 요구 사항이 높아지는 가운데, Low Latency HLS 혹은 CMAF를 이용한 DASH까지 가고 있지만, 실재로 서비스의 구성을 잘 고려하지 않으면 원하는 품질을 확보하기 어렵다. 이를 위해서는 실재 컨텐츠의 해상도 품질과 지연 요구 사항을 잘 고려하여 서비스를 고민해야 한다.

참고 문서

[1] Wowza media systems, "Real-Tme Interactive Apps: A Best Practices Guide With The Wowza Streaming Cloud Service", (링크 깨짐) https://www.wowza.com/uploads/images/Real-Time-Interactive-Apps-WSC-2019.pdf

다른 링크

[2] Streaming Protocols: Everything You Need to Know, www.wowza.com/blog/streaming-protocols

[3] 2019 Video Streaming Latency Report, https://www.wowza.com/blog/2019-video-streaming-latency-report