[Network] HTTP Video Streaming, DASH

📡 인터넷 비디오

개요

인터넷 비디오 트래픽은 요즘 인터넷 대역폭의 주요 소비자로 자리잡고 있다. 2020년 기준으로 넷플릭스, 유튜브, 아마존 프라임과 같은 서비스들이 주거용 ISP 트래픽의 약 80%를 차지한다.

 

이런 상황에서 몇십억 명에 달하는 사용자들에게 어떻게 서비스를 제공할지는 정말 중요한 도전 과제다.

 

하나의 메가 비디오 서버로는 이런 규모의 서비스를 제공할 수 없고, 사용자들의 다양한 기종도 도전 요소이다. 이러한 문제를 해결하기 위해 분산된 인프라 구축이 필요하다.

 

 

비디오 매체의 특성

비디오는 여러 장의 이미지(프레임)를 초당 수십 장씩 보여줘야 한다(ex: 24fps, 30fps). 각 이미지(프레임)는 픽셀들의 배열이고, 수 많은 데이터들로 구성되어 있다.

 

데이터를 줄이기 위해 인코딩이 적용된다.

• 공간적 중복 제거 (Spatial coding): 같은 색이 반복되면 하나로 줄이기
• 시간적 중복 제거 (Temporal coding): 앞 프레임과 큰 차이 없으면 변화된 부분만 전송

 

MPEG-1, MPEG-2, MPEG-4 등 다양한 인코딩 방식 존재한다(비트레이트 1.5Mbps ~ 12Mbps).

 

저장된 비디오 스트리밍

요즘 넷플릭스나 유튜브로 영상을 보는 건 일상이지만, 그 배경에는 굉장히 복잡한 기술이 숨어있다. 특히 저장된(stored) 비디오 스트리밍은, 서버에 미리 녹화되어 저장된 비디오를 사용자가 요청해서 보는 방식인데 단순해 보이지만 실제 구현은 쉽지 않다.

• 대역폭이 계속 바뀐다
  • 사용자의 네트워크 환경은 시간에 따라 계속 다르다. 집 안의 Wi-Fi 상태, 모바일망의 혼잡도, 서버와의 물리적 거리까지 모두 영향을 준다.
  • 이 말은 서버에서 일정하게 비디오를 보내도 중간에서 병목이 생길 수 있다는 뜻이다.
• 패킷 손실과 지연
  • 네트워크 혼잡으로 패킷이 늦게 오거나 아예 사라질 수도 있다.
  • 이러면 영상이 끊기거나 품질이 확 떨어질 수 있다.
• 연속 재생의 제약
  • 비디오는 정해진 시간 간격으로 프레임을 재생해야 자연스럽게 보인다.
  • 그런데 네트워크 지연(jitter)이 일정하지 않아서, 그냥 오는 대로 재생하면 뚝뚝 끊겨 보인다.
• 클라이언트의 상호작용
  • 사용자들은 일시정지, 빨리감기, 되감기 같은 동작을 기대한다.
  • 이를 위해 클라이언트는 영상 데이터 흐름을 더 유연하게 관리해야 한다.
• 재전송 필요성
  • 중요한 프레임이 손실되면, 재요청해서 받아야 할 수도 있다.

 

1. 서버에 비디오가 저장되어 있고 (예: 초당 30프레임으로 녹화)
2. 사용자가 요청하면, 서버가 프레임을 네트워크를 통해 전달하고
3. 클라이언트는 이걸 받아서 일정한 속도로 재생

문제는, 이 과정에서 네트워크가 완벽하지 않다는 것이다.

 

네트워크 지연이 가변적이라면, 클라이언트가 똑똑해져야 한다. 즉, 재생 전에 데이터를 조금 받아 두고(버퍼링) 그걸 기반으로 일정한 속도로 재생하면 끊김이 줄어든다.

• 서버는 일정한 비트레이트로 전송하고
• 클라이언트는 불규칙한 속도로 데이터 수신
• 하지만 결국 일정한 속도로 재생해야 하니까

중간에 ‘버퍼’라는 것이 필요하다.

 

비디오 스트리밍 플레이아웃 버퍼링

그래프에서 확인할 수 있듯이, 서버는 일정한 비트레이트로 비디오를 전송하지만(왼쪽 빨간색 그래프), 네트워크 지연의 변동성으로 인해 클라이언트의 실제 데이터 수신은 불규칙하게 이루어진다(중간 검은색 그래프). 이러한 상황에서도 사용자 경험을 위해 클라이언트는 일정한 비트레이트로 비디오를 재생해야 한다(오른쪽 파란색 그래프).

 

이를 위해 클라이언트는 재생을 시작하기 전에 적절한 양의 데이터를 버퍼에 미리 저장한다(client playout delay). 이 버퍼링된 데이터는 네트워크 지연 및 지터(jitter)로 인해 발생할 수 있는 데이터 수신 불규칙성을 보완해 사용자에게 끊기지 않고 일정하게 비디오가 재생될 수 있도록 한다.

 

📡 HTTP Streaming 및 DASH

기존 HTTP Streaming의 한계

비디오를 HTTP로 전송하는 방식은 생각보다 간단하게 시작했다. 서버에 비디오 파일을 그냥 저장해두고 클라이언트가 URL로 요청하면 TCP 연결을 통해 파일을 빠르게 내려받는 구조였다.

 

이때 클라이언트는 수신한 데이터를 재생 버퍼에 쌓아두고 일정량 이상 모이면 재생을 시작한다. 영상의 앞부분을 보는 동안 뒤쪽 프레임은 계속 다운로드되고 버퍼링된다. 이 방식은 간단하고 직관적이지만, 큰 문제가 하나 있다.

 

바로 모든 사용자에게 같은 화질의 비디오가 제공된다는 점이다. 누구는 광랜을 쓰고, 누구는 지하철에서 3G로 접속할 수도 있다. 그런데 이 둘 모두에게 동일한 1080p 화질의 영상을 전송하면 어떤 일이 벌어질까?

 

느린 네트워크에선 끊기고, 버퍼링이 반복되어 사용하기 어려워질 것이다. DASH는 이 문제를 해결하기 위해 고안된 방식이다.

 

DASH의 작동 방식

같은 비디오를 여러 화질로 미리 만들어 놓고, 클라이언트가 네트워크 상황에 따라 적절한 화질을 골라서 받는다.

• 서버는 비디오를 몇 초 단위로 잘게 쪼개서(청크 또는 세그먼트),
• 각 청크를 여러 품질(비트레이트)로 인코딩해서 저장한다.
• 그리고 이걸 한눈에 볼 수 있게 정리한 매니페스트 파일(.mpd)을 함께 제공한다.

 

스트리밍이 시작되면, 클라이언트는 먼저 매니페스트 파일을 받아서 가능한 품질들을 확인한다. 그리고 각 청크를 한 개씩 요청하면서, 매번 자신의 대역폭 상태를 체크한다.

• 네트워크가 빠르면 → 고화질 청크 요청
• 느려지면 → 저화질 청크로 전환

 

이 과정을 반복하면서 끊김 없이 적응형(adaptive) 스트리밍을 유지한다.