Video streaming and content distribution networks

상위 문서: Application Layer

개요

사전 녹화된 비디오 스트리밍은 현재 북미의 주거용 ISP 트래픽 대부분을 차지한다. 특히, 넷플릭스(Netflix) 와 유튜브(YouTube) 만으로도 2015년 기준 각각 37%와 16%의 트래픽을 소비했다. 이는 넷플릭스와 유튜브가 2015년 기준 약 7500만명, 10억명의 이용자 수를 가지고 있기 때문이다. 또한 많은 사용자 수는 heterogeneity라는 문제를 발생시키는데, 이는 사용자가 모두 다른 환경을 가지고 있기 때문에 모든 사용자에게 동일한 품질을 제공할 수 없어 생기는 문제이다. 해당 문서에서는 현재 인터넷에서 널리 사용되는 비디오 스트리밍 서비스가 어떻게 구현되는지에 대해 설명하는 것을 목표로 한다.

Vedio

비디오는 일련의 이미지이며, 초당 24~30프레임의 일정한 속도로 표시된다. 이때 디지털 이미지 하나는 픽셀 배열로 이루어져 있고, 각 픽셀은 밝기(luminance) 와 색상(color) 정보를 표현하는 비트들로 인코딩된다.

비디오의 가장 중요한 특성 중 하나는 압축 가능하다는 것이다. 압축을 통해 비디오 품질과 비트레이트(bit rate) 사이의 절충이 가능하며, 비트레이트가 높을수록 영상 품질이 더 좋아진다. 이때 압축된 비디오는 보통 100kbps~3Mbps 정도를 요구하는데, 비디오가 끊김없이 재생되기 위해서는 average end-to-end throughput이 압축된 비디오의 bit rate보다 더 높아야 한다. 이 때문에 사용자는 자신의 네트워크 상태에 맞는 비디오 버전을 선택하여 재생할 수 있어야 한다.

HTTP streaming

HTTP streaming에서는 비디오가 일반 파일처럼 HTTP 서버에 저장되고, 고유한 URL을 갖는다. 사용자가 재생하려고 하면, 클라이언트는 서버에 TCP 연결을 맺고 해당 URL로 HTTP GET 요청을 보낸다. 그리고 서버는 HTTP 응답 메시지에 비디오 파일을 담아 전송한다.
클라이언트 측에서는 수신된 바이트가 애플리케이션 버퍼에 쌓이고, 버퍼가 일정 임계치를 넘으면, 재생을 시작한다. 이후 프레임을 주기적으로 가져와 압축 해제하고, 화면에 출력하는 방식으로 비디오를 재생한다. 즉 비디오를 받으면서 동시에 재생하는 구조이다.

하지만 이는 모든 사용자에게 동일한 비디오 인코딩이 재공된다는 단점이 있다. 사용자마다 네트워크 환경이 크게 다르고, 같은 사용자도 시간에 따라 네트워크 상태가 변동하기 때문에 이를 반영할 새로운 메커니즘이 필요하다.

Dynamic Adaptive Streaming over HTTP

DASH (Dynamic Adaptive Streaming over HTTP)는 위의 HTTP 스트리밍의 문제를 해결한 방식이다.

DASH 작동원리

server는 비디오를 서로 다른 bit rate의 여러 버전으로 인코딩하고, 해당 비디오 파일들은 여러 개의 청크(chunk) 단위로 나누어 저장된다. 클라이언트는 비디오 URL을 통해 서버에 접근하여 먼저 manifest file을 요청한다. menifest file은 각 버전의 비디오 파일들의 URL과 bit rate 정보를 가지고 있다. 클라이언트는 서버로부터 menifest file을 받아 현재 자신의 네트워크 상태에 맞는 bit rate 버전을 판단하고 이에 대한 URL을 선택해서 서버에 요청한다. 이후로도 클라이언트는 주기적으로 server-to-client bandwidth를 측정하여 현재 속도에서 감당 가능한 최대 품질의 청크를 로드한다. 이 과정은 매 청크마다 반복된다. 이는 유동적으로 변화하는 네트워크 상황에서도 고화질, 혹은 저화질 영상을 전환하며, 안정적인 비디오 스트리밍 서비스를 제공하도록 한다.

DASH 특징

DASH는 사용자의 단말기가 지능적으로 작동하여 'Dynamic, Adaptive Streaming'을 가능케한다. 사용자의 단말기는 menifest file을 바탕으로 아래의 세 가지를 스스로 판단한다.

1. when to request chunk?
   • 너무 일찍 요청하면 버퍼가 넘칠 수 있고, 너무 늦게 요청하면 버퍼가 비어서 재생이 끊길 수 있다.
     즉, 클라이언트는 현재 버퍼 상태를 고려해 적절한 시점에 청크를 요청한다.
2. what encoding rate to request?
   • 네트워크가 빠르면 high bit rate 청크를 선택하고 느리면 low bit rate 청크를 선택하여 품질을 조정해야 한다.
3. where to request chunk?
   • 하나의 비디오가 여러 서버(CDN 노드)에 분산되어 있을 수 있어, 클라이언트는 가까운 서버, 또는 가용 대역폭이 넉넉한 서버를 선택해야 한다.