미디어 서버를 이해해보자

Live & VOD Streaming Media server 구축 (1) - 미디어서버의 이해 (tistory.com)

Live & VOD Streaming Media server 구축 (1) - 미디어서버의 이해

라이브 스트리밍을 서비스 할 미디어서버를 구축하기 전, 미디어 서버에대해 알아보는 시간을 가져보도록하자.

 

미디어 서버

압축(인코딩)된 동영상 파일들이 미디어서버로 들어오면 해석(디코딩) 한 후 사용자(Client)가 볼 수 있게 재포장(압축)해서 사용자의 동영상 플레이어 형태에 맞게 보내주는 역할

 

라이브 스트리밍의 전체적인 흐름

원본영상 -> 인코더 -> 미디어서버 -> CDN(선택) -> 동영상 플레이어 -> 클라이언트

1. 원본 영상 → 라이브 인코더 > 영상 송출
2. 미디어 서버 → 전송 서버(CDN) > 영상 변환 및 전송
3. 동영상 플레이어→ 시청자 > 영상 재생

 

라이브 인코더

라이브 인코더는 원본 영상을 정해진 방식으로 압축(인코딩)하고, 압축한 컨텐츠를 미디어 서버로 전송하는 역할을 한다. 인코더에서 미디어 서버로 컨텐츠를 전송하는 것을 보통 송출이라고 한다.

인코더의 종류

• PC에 설치해서 사용할 수 있는 소프트웨어 인코더
• 박스 형태의 하드웨어 인코더
• 촬영하면서 송출까지 할 수 있는 모바일 앱 인코더

아울러 오픈소스인 ffmpeg를 이용하여 간단한 인코더를 구현할 수도 있다.

 

압축(인코딩)

카메라로 촬영한 원본 영상을 그대로 미디어 서버에 전송하기에는 데이터 용량이 너무 크기 때문에 압축하는 과정이 꼭 필요하다. 또한 미디어 서버에서 해석할 수 있는 압축방식(코덱, Codec)을 사용해야 한다.

인터넷 방송에는 H.264/AAC 코덱이 주로 쓰이며, 최근에는 더욱 압축 효율이 좋은 H.265 코덱을 사용하는 경우도 늘어나고 있다.

인코딩은 CPU를 많이 쓰는 작업이다. 인코딩 작업에 평균 CPU 사용률이 80%가 넘을 경우 출력 영상의 품질이 나빠질 수 있다. 만약 CPU 부하로 인해 송출 중인 영상이 계속 끊기거나 버벅인다면 출력 해상도나 비트레이트를 줄이는 것이 좋다. 소프트웨어 인코더를 사용할 경우 안정적인 방송을 위해서 쿼드코어 CPU가 탑재된 PC 사용을 권장한다.

 

송출

미디어 서버로 영상을 보낼 때는 인터넷 스트리밍에 최적화된 RTMP 프로토콜을 이용한다.

과거에는 UDP 기반의 RTSP 프로토콜을 많이 사용했으나 최근에는 RTMP 프로토콜이 거의 표준처럼 사용되고 있다. 안정적인 송출을 위해서는 충분한 인터넷 업로드 대역폭이 확보되어 있어야 한다.

가정이나 일반 사업장에서 사용하는 인터넷 품질은 상황에 따라 가변적일 수 있다. 절대 끊어지면 안되는 중요한 방송이라면, 별도 전용 회선을 설치해서 송출하는 것을 권장한다. 인터넷 업로드 대역폭은 출력 비트레이트의 두 배 이상 확보되는것이 안정적이며, 만약 송출중인 영상이 계속 끊기거나 버벅일경우 출력 해상도와 비트레이트를 낮춰주면 출력 품질 개선에 도움이 될 수 있다.

 

미디어 서버

미디어 서버는 다음과 같은 인터넷 라이브 방송의 핵심적인 역할을 담당한다.

• 인코더가 보내준 영상을 여러가지 화질 및 비트레이트로 변환(트랜스 코딩)
• 화질별로 변환된 영상을 다시 HLS 형식으로 변환(트랜스먹싱 혹은 패킷타이징이라고 함)

화질 및 비트레이트 변환

인터넷 방송 서비스는 사용자의 다양한 디바이스 크기, 네트워크 환경에 맞는 영상을 시청하도록 하는 것이 중요하다. 불필요한 데이터 사용과 배터리 소모를 방지하고 최적의 화질을 보장할 수 있기 때문인데, 이를 위해 미디어 서버에서 원본 영상을 여러 화질로 변환해주어야 한다.

이 작업은 앞서 설명한 라이브 인코더와 함께 동일하게 CPU를 많이 사용한다. 이유는 라이브 인코더가 압축해서 보내준 영상을 압축 해제(디코딩)하고 화질 변환 후 다시 압축(인코딩)하기 때문이다. 인코딩 작업에 GPU 가속을 이용하면 CPU의 인코딩 부하를 상당량 줄일 수 있다.

HLS 변환

HLS(HTTP Live Streaming)는 전 세계에서 가장 널리 사용되고 있는 실질적인 표준 HTTP 스트리밍 프로토콜이다.

M3U8 확장자의 재생목록 파일과 영상을 잘게 쪼갠 TS 청크 파일들을 전송하며, 이를 통해 모바일과 PC 등 다양한 디바이스에서 영상을 재생할 수 있다.

카메라가 촬영하는 시간과 그 영상이 시청자에게 표시되는 시간의 차이를 지연(Latency)라고 하는데, 시청자와 실시간 소통이 필요할수록 짧은 지연(Low Latency)이 필요하다. 과거에는 10~15초 분량의 TS 청크를 재생 목록에 3개씩 담아 사용하는 것이 일반적이였다. 즉 미디어 서버 입장에서 30~45초 정도 분량을 버퍼에 담아두었다가 전달하는 셈이다. 따라서 사용자 입장에서는 전송에 소요되는 시간까지 포함하여 최소 30초, 최대 1분에 달하는 지연이 발생하게 된다. 버퍼가 클수록 재생이 안정적이지만, 지연시간은 길어진다. 반대로 버퍼를 짧게 가져가면 지연은 적지만 네트워크 상황에 민감해져 재생 품질이 불안정해 질 수 있다.

최근에는 네트워크 환경이 좋아져 보다 공격적으로 튜닝하여 사용하는 경우가 많은데, 1~2초정도의 TS 청크를  사용한다면 지연시간을 10초 미만으로 줄일 수 있어 소위 말하는 Low Latency를 구현할 수 있다.

미디어 서버 솔루션

-Wowza Media Server (유료)

유료이지만 다양한 기능과 우수한 인코딩 성능을 가지고 있다.

- Nginx-rtmp(오픈소스)

nginx의 모듈로 동작하는 미디어 스트리밍 서버인데, RTMP 소스를 Pull 혹은 Push 방식으로 입력받을 수 있고, RTMP/HLS/MPEG-DASH 출력을 지원한다. 여기에 ffmpeg을 연동하면 트랜스코딩을 비롯하여 기타 다양한 기능들을 구현할 수 있어 유료 솔루션의 좋은 대안이 될 수 있다.

 

전송 서버(CDN)

미디어 서버에서 실시간으로 생성한 HLS 영상 조각 파일을 사용자에게 전달하려면 전송 서버가 있어야한다. 일반적으로 미디어 서버는 전송 서버의 역할까지 수행하는데, 동시시청자수가 많은 방송일수록 대규모 트래픽을 안정적으로 처리하기 위해 CDN을 사용하는것이 좋다.

CDN에서 캐싱을 하지 않으면 동시에 많은 시청자가 접속했을 때 미디어 원본 서버로 많은 요청이 들어갈 수 있다. 그렇다고 무작정 캐싱 시간을 늘려놓아도 안되는데, 위에서도 언급했지만 최근엔 영상의 지연을 최소화 하기 위해 TS 청크의 길이를 수초 단위로 사용하는 경우가 많다. 이 때 HLS 재생목록 파일이 TS 청크의 재생시간 내에 갱신되지 않으면 버퍼링이 발생하거나, 플레이어가 영상재생을 중단할 수 있다. 따라서 재생목록 파일은 TS 청크의 절반 정도 시간만 캐싱하고 갱신되도록 설정해두는 것이 좋다.