출처: http://helloworld.naver.com/helloworld/7122

NHN P2P서비스개발팀 윤병조

라이브 스트리밍을 위한 전통적인 프로토콜로인 RTSP는 도입 비용이 높고 방화벽 환경에서 서비스가 원활하게 이루어지지 않는 단점이 있습니다. 이러한 단점을 해결하는 방법으로 HTTP를 라이브 스트리밍을 위한 프로토콜로 사용하는 방법이 나오게 되었습니다. 이 글에서는 HTTP를 이용해 원활한 스트리밍 서비스를 제공하고 방화벽 문제 등을 해결하려는 노력 중에 하나인, Apple이 만든 HLS(HTTP Live Streaming)에 대해 살펴보겠습니다.

HTTP를 사용하는 라이브 스트리밍

동영상 라이브 스트리밍(Live Streaming)이란 텔레비전 생방송처럼 촬영한 정보를 실시간으로 사용자의 동영상 플레이어로 보내 재생하도록 하는 방식을 말한다. 온 디맨드 스트리밍(On-Demand Streaming)에서는 촬영과 편집을 거쳐 동영상 파일을 제작한 다음 사용자의 요구가 있을 때 동영상을 재생할 수 있도록 하지만, 라이브 스트리밍에서는 비디오와 오디오를 실시간으로 인코딩해 많은 사용자에게 동시에 보낼 수 있어야 한다.

라이브 스트리밍을 위한 전통적인 프로토콜로는 RTSP(Real-Time Streaming Protocol)/RTP(Real-time Transport Protocol), RTMP(Real-Time Messaging Protocol) 등이 있다. 이 프로토콜을 사용하는 스트리밍 서버는 영상 데이터의 전송뿐만 아니라, 동영상에 대한 정보 분석이나 전송 규격에 맞도록 동영상 파일을 읽어서 변형하는 기능도 갖춰야 한다. 기능이 많은 만큼 웹 서버에 비해 도입 비용이 상대적으로 높다.

고가의 도입 비용 이외에도 결정적인 단점이 있다. 현재 가장 많이 사용하는 RTSP/RTP의 경우, RTSP와 RTP가 서로 다른 네트워크 연결을 통해 데이터를 교환하기 때문에 방화벽이나 NAT(Network Address Translator)를 많이 쓰고 있는 환경에서는 서비스가 원활하지 않은 문제가 있다.

그래서 대안으로 나온 것이 HTTP를 전송 채널로 사용하는 것이다. HTTP는 양방(full-duplex) 방식이 아니기 때문에 라이브 스트리밍을 위해서는 단점을 극복할 별도의 방식이 필요하지만, 방화벽에서 HTTP 서버로의 요청만 통과시키면 되기 때문에 방화벽의 설정이 단순해진다. 요청과 응답이 1:1로 대응되므로 NAT 환경에서도 서버와 통신하는 것이 쉽다. 비단 방화벽 문제때문이 아니라, 웹 서비스를 위한 캐시 구조를 그대로 사용할 수 있고, 기존에 구축되어 있는 CDN(Content Delivery Network)도 특별히 변경하지 않고 그대로 이용할 수 있다는 것이 장점이다.

HTTP Live Streaming

HLS(HTTP Live Streaming)는 Apple에서 iOS 3.0과 QuickTime X를 위해 2009년에 내놓은 프로토콜이다. 이 프로토콜에서는 스트리밍 데이터를 MPEG-2 Transport Stream에 담아 시간 단위로 잘게 쪼개서 전송한다. 그리고 어떤 파일을 재생해야 하는 지에 대한 정보는 m3u8 파일을 이용하여 플레이어에 전달한다.

HLS는 iPhone과 iPad의 사용자 수가 늘어남으로써 자연스럽게 그 수요가 늘어나게 되었다. 또한, 규격 자체의 단순함과 IETF(Internet Engineering Task Force)를 통한 표준화 작업 등을 통해 다른 업체들도 쉽게 HLS를 지원할 수 있게 했다.

그 결과로, Adobe는 Flash Media Server 4.0에서, Microsoft는 IIS Media Server 4.0에서 HLS를 정식으로 지원하며, 모바일 운영체제에서 상대 진영이라 할 수 있는 Google의 Android에서도 3.0 버전인 Honeycomb부터 HLS를 지원하기 시작했다.

HLS와 기존 라이브 스트리밍 방식과의 비교

HLS와 기존 라이브 스트리밍 방식 모두 동영상을 끊김 없이 사용자의 동영상 플레이어에 전달한다는 점에서는 동일한 구조이다. 그림 1의 Server 부분과 그림 2의 Live H.264/AAC 부분의 역할은 같다. 카메라로 촬영한 영상을 코덱을 이용해 압축해서 서버로 보내는 것이다.

HLS와 기존 방식의 차이는 크게 두 가지이다. 하나는 '동영상 정보를 전달하는 방식'이고, 다른 하나는 HLS에서 만든 스트림 세그멘트(stream segment)이다.

그림 1 Apple 의 HLS 구성(원본 출처: http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/Introduction/Introduction.html)

그림 2 기존 스트리밍 서버를 이용한 스트리밍 서비스 구성

HLS에서 서버는 HTTP로 요청을 받아서 플레이어에 응답을 주는 역할만 한다. 요청받은 파일을 읽어서 어떠한 변형도 하지 않고, 읽은 그대로 응답에 포함해 보내기만 한다. 즉 저장되어 있는 파일을 읽어서 HTTP 응답에 데이터를 실어서 보낼 수 있는 웹 서버면 어떤 웹 서버든 사용할 수 있다.

하지만 기존 스트리밍 서버는 플레이어가 스트리밍 서버에 연결한 스트리밍 규격에 맞게 다시 데이터를 변형해 보내는 작업을 해야 한다. 경우에 따라서는 특정 스트리밍 방식을 위해 해당 회사의 제품을 구매해야 할 때도 있다. 웹 서버에 비하여 처리 과정이 더 많기 때문에 서버 한 대당 처리할 수 있는 클라이언트의 수도 웹 서버보다 적다.

스트림 세그먼터(Stream Segmenter)는 일정한 시간 간격마다 입력받은 미디어 데이터를 분할해 파일을 만들고, 그 분할한 파일에 접근할 수 있는 메타데이터(m3u8)를 생성하는 일을 한다. HTTP는 양방향 방식이 아니기 때문에, 클라이언트에서 반드시 서버에 요청을 해야 그에 맞는 응답을 받을 수 있다. 즉, 잘게 쪼갠 동영상과 다음에 볼 동영상 정보를 함께 클라이언트에 전달하고 동영상이 끊김 없이 때에 맞춰 다음 동영상 정보를 요청한다.

스트림 세그먼터에서는 동영상 데이터를 변형하지 않으므로 기능이 복잡하지 않다. 기존의 스트리밍 서비스 구조의 "원본 > 인코더 > 스트리밍 서버 > 플레이어"라는 데이터 흐름에서 "원본 > 인코더 > 스트림 세그먼터 > 웹 서버 > 플레이어"라는 흐름으로 단계가 더 많아졌다. 하지만 대규모 서비스를 위해 부하 분산을 고려할 때 기존 라이브 스트리밍 방식은 매우 복잡한 구조를 사용했지만, HLS는 일반 웹 서비스의 구조와 같은 방식을 사용하기 때문에 전체적으로 볼 때 단순해졌다고 할 수 있다.

동영상 압축

널리 쓰고 있는 색 표현법에 RGB를 이용하는 표현법이 있다. 빛의 삼원색인 빨강, 초록, 파랑의 밝기 값을 각각 0~255의 숫자로 표현하는 방법이다. 0~255의 숫자를 컴퓨터에서 이용하는 이진 데이터로 만들면 8비트의 저장 공간이 필요하다. 따라서 RGB 방식으로 색을 표현할 때는 3바이트가 필요하다.

하지만 3바이트로는 픽셀이라고 부르는 1개 화소의 색만 표현할 수 있다. 전체 화면에 대한 정보를 보내려면 화면 크기만큼 화소의 색깔 정보가 있어야 한다. 해상도가 VGA(640x480)인 영상의 경우에는 30만 7천2백 개의 화소가 있으므로 데이터는 총 921,600바이트가 된다.

움직이는 화면에서 초당 약 30개의 화면을 보낸다고 하면 초당 27MB라는 어마어마한 데이터를 보내야 한다. 해상도가 더 높은 영상은 당연히 데이터의 양이 더 많아지므로 동영상 압축이 필요하다.

m3u8 포맷

그림 3 m3u8 파일과 ts 파일

m3u8 포맷을 이해하기 전에 m3u 포맷을 먼저 알아야 한다.

m3u 포맷은 연속으로 재생할 MP3 파일 목록을 가진 플레이 리스트 파일이다. 각 줄마다 재생할 파일의 경로를 적는 매우 단순한 구조이다. 하지만 m3u에는 Latin-1 문자 집합만 적을 수 있다. 그리고 단순히 파일 목록을 나열할 뿐이므로 재생할 파일에 대한 정보를 재생하기 전에 미리 알 수 없다.

그래서 나온 확장 규격이 m3u8 포맷이다. m3u8 포맷에서는 UTF-8 문자 집합을 사용할 수 있고, 여러 가지 지시어로 재생할 파일에 대한 추가적인 정보를 제공할 수도 있다.

HTTP Live Streaming에서 m3u8 포맷을 사용하려면 몇 가지 규칙을 따라야 한다.

우선 m3u8 파일의 가장 첫 줄은 #EXTM3U로 시작해야 한다. #EXTM3U라는 지시어로 이 파일은 m3u8 포맷을 사용한다는 것을 플레이어에게 알려 준다.

둘째로 모든 m3u8 포맷의 지시어는 줄 맨 앞을 #EXT로 시작해야 한다. #EXT로 시작하지 않으면 # 이후의 문자열을 주석으로 간주한다.

m3u8 포맷의 주요 지시어에는 다음과 같은 것이 있다.

표 1 m3u8 포맷의 지시어

MPEG-2 TS (Transport Stream)

MPEG-2 TS는 MPEG-2 Part 1, Systems (ISO/IEC 13818-1 또는 ITU-T H.222.0)로 오디오나 비디오, 방송의 채널 정보 등을 전송하거나 저장하기 위해 정의한 규격이다. MPEG-2의 Elementary Stream(MPEG에서 오디오나 비디오 각각의 데이터 집합)을 패킷(Packet)으로 만들 때 에러 정정 및 동기화 정보 등을 같이 포함할 수 있도록 하는 컨테이너(container) 포맷이다. 실제로 TS로 데이터를 전송하는 경우 하나의 연결 내에 동시에 여러 개의 채널 정보를 담아서 전송할 수 있다.

TS에서 주로 사용하는 개념으로 프로그램(Program)이 있다. 프로그램은 간단하게 말하면 Elementary Stream의 집합이다. 조금 쉽게 생각하면, 텔레비전에서 오디오와 비디오가 포함되어 있는 각각의 채널을 MPEG-2 TS에서 말하는 프로그램이라 볼 수 있다. 방송에서 나오는 드라마나 뉴스 등의 프로그램을 말하는 것이 아니고, KBS, MBC, SBS와 같은 채널 자체를 MPEG-2 TS에서는 프로그램이라 한다.

다음 그림에서 보는 바와 같이 영화 채널, 뉴스 채널, 스포츠 채널 등의 정보를 하나의 전송 연결에 포함할 수 있고(multiplexing), 플레이어는 각 채널이 가진 고유한 ID를 이용하여 원하는 채널을 선택해 재생할 수 있다.

그림 4 MPEG-2 TS(원본 출처: http://en.wikipedia.org/wiki/MPEG_transport_stream)

다음 그림은 TS 포맷을 상세히 표시한 그림이다. 밑에 적혀 있는 숫자는 비트 단위이다.

그림 5 Transport Stream 구문(출처: ITU-T Recommendation H.222.0(05/2006))

TS 패킷의 크기는 188바이트로 고정되어 있고, 이보다 큰 데이터는 모두 나누어진다. 동기화를 위한 정보나 시간 정보, 에러 정정, 스크램블링(scrambling: 허가되지 않은 사용자가 해당 채널을 볼 수 없도록 하는 작업) 정보 등을 헤더에 명시한다.

페이로드에 포함되는 중요 데이터는 다음과 같다..

표 2 TS의 페이로드에 포함되는 데이터

다음 그림은 PAT, PMT, PES의 대략적인 관계를 나타낸 것이다. PAT를 통해 어떤 프로그램이 있는지 목록을 얻고, PMT로 선택한 프로그램의 비디오/오디오 데이터가 어떤 ID를 갖고 있는지 알아내어 해당 ID를 가진 패킷만 선택하여 재생한다.

그림 6 PAT, PMT, PES 의 상관 관계

HLS를 위한 ts 파일 생성

HLS에서 사용하기 위한 ts 파일은 MPEG-2 TS를 순서대로 저장한 파일이다. 다만 정한 시간에 따라 분할하여 저장한다.

HLS로 화면을 자연스럽게 재생하려면 각 ts 파일이 I-frame(Intra frame: 화면 전체가 압축되어 들어 있는 frame)을 포함해야 한다. 되도록이면 첫 비디오 데이터가 I-frame인 것이 좋다. 첫 화면이 I-frame 이 아니면 플레이어에서 화면이 나오지 않거나 일시적으로 뭉개진 화면이 나올 수 있다. I-frame은 데이터가의 크기가 크기 때문에 ts 파일이 포함하는 데이터의 재생 시간 간격을 적절하게 선택해야 한다. Apple이 HLS를 위해 권고하는 미디어의 규격은 다음과 같다.

표 3 HLS를 위한 Apple의 미디어 규격 권고 사항

Apple에서 권고하는 기기별/네트워크별 해상도와 비트레이트는 다음과 같다. 추천 값에 대한 더 자세한 내용은 "HTTP Live Streaming Overview" 문서를 참조한다.

그림 7 Apple의 기기별/네트워크별 해상도, 비트레이트 추천 값

Apple이 추천하는 각 ts 파일의 길이는 플레이어에서 10초간 재생할 수 있는 분량이다.

재생할 수 있는 분량이 짧아지면 네트워크로부터 받아와야 하는 데이터의 양이 증가한다. I-frame의 빈도가 늘어나게 되어 실질적인 데이터의 양도 늘어나고 전송 프로토콜의 헤더와 같은 추가적인 전송 데이터 및 갱신되는 index.m3u8 파일을 받기 위한 데이터의 양도 같이 늘어난다.

반대로 재생할 수 있는 분량이 길어지면 원래 방송하고 있는 데이터와 플레이어에서 재생하고 있는 데이터 사이의 시간 간격이 커진다. 이를 테면, 옆집에서는 TV로 축구 중계를 보고 있고 나는 HLS를 이용하여 축구 중계를 보고 있다면, 옆집에서 골을 넣는 장면을 보는 시간과 내가 골을 넣은 장면을 보는 시간의 차이는 재생할 수 있는 분량만큼이므로, 옆집에서 환호성을 지르고 나서 한참 후에야 내가 환호성을 지르게 될 수 있다.

물론 위에 나열되어 있는 값들은 Apple의 권장 값이므로, 각 서비스에 따라 적절한 값을 선택할 수 있다.

콘텐츠 보호

HLS는 콘텐츠 보호를 위해 각각의 ts 파일을 개별적으로 암호화하는 방식을 사용한다. 암호화가 적용되면 암호화에 사용한 키(key)를 #EXT-X-KEY 지시어로 플레이어에 제공한다. 플레이어는 이 키 파일에 기록된 키를 이용하여 ts 파일을 해독하여 재생한다.

HLS이 기본적으로 사용하는 암호화 방식은 AES-128이다. 따라서 키 파일에는 16 octet의 binary key 정보가 들어 있어야 한다.

모든 ts 파일은 하나의 키를 이용하여 암호화할 수도 있고, 각 구간별로 다른 키를 이용하여 암호화할 수도 있다. 이론적으로는 각 ts 파일마다 다른 키를 사용하여 암호화할 수도 있지만, 매번 키 파일을 플레이어가 받아야 되므로 추가적인 전송 데이터가 발생한다.

그림 8 HLS 에서의 콘텐츠 보호

Adaptive Bitrate Streaming

HLS의 특징 중에 하나는 사용자의 네트워크 속도에 따라 적합한 콘텐츠를 선택하여 재생할 수 있는 Adaptive Bitrate Streaming을 지원하는 것이다.

Adaptive Bitrate Streaming에 대해 간단히 살펴 보겠다.

Adaptive Bitrate Streaming을 적용하면 사용자의 네트워크 환경이 변화해도 끊기지 않고 동영상을 볼 수 있다.

예를 들어 Wi-Fi 환경에서 스트리밍 서비스를 사용하던 중에 휴대전화망 환경으로 이동하면 사용 가능한 네트워크의 대역폭이 감소된다(네트워크 주소 변화 등으로 인한 연결 중단 등의 문제는 고려하지 않았음). 이때 Adaptive Bitrate Streaming이 적용되지 않은 스트리밍 서비스에서 Wi-Fi 환경에 적합한 비트레이트(bitrate)로 라이브 서비스를 제공하고 있었다면, 플레이어가 데이터를 제대로 수신하지 못하여 지속적으로 버퍼링이 발생하거나 부족한 데이터로 인해 화면이 제대로 표시되지 않는 문제가 발생한다.

하지만 Wi-Fi 환경과 휴대전화망 환경에 맞는 라이브 서비스를 동시에 제공하는 Adaptive Bitrate Streaming이 적용되어 있다면, 휴대전화망 환경의 라이브 서비스로 자동으로 옮겨감으로써 화면의 품질이나 해상도 등은 나빠지지만 끊기지 않고 계속 서비스를 이용할 수 있는 것이다.

그림 9 Adaptive Bitrate Streaming 의 동작

HLS에서도 Adaptive Bitrate Streaming을 위해 동시에 여러 비트레이트의 ts 파일에 대한 정보를 제공하는 것이 가능하다.

HLS에서 Adaptive Bitrate Streaming을 지원하기 위한 m3u8 파일과 ts 파일의 구조는 다음과 같다.

그림 10 ABS를 위한 m3u8 파일과 ts의 연결 구조

전체를 대표하는 m3u8 파일이 있고, 대표 파일 내에서 다시 각각의 비트레이트별 플레이 리스트 파일을 가리키게 한다. 각 비트레이트별 플레이리스트 파일은 다시 각자의 비트레이트에 해당하는 ts 파일들을 가리킨다.

위의 예와 같은 variant.m3u8 파일의 내용은 다음과 같다.

Adaptive Bitrate Streaming 을 지원하는 스트리밍 서비스를 구성할 때는 다음과 같은 사항에 주의해야 한다.

각 ts 파일이 담고 있는 데이터는 동일한 구간의 데이터를 포함해야 한다. 네트워크 환경이 변화하여 다른 비트레이트를 가진 데이터를 받을 때 바뀐 비트레이트의 데이터 구간이 원래의 데이터 구간과 달라지면 순간적으로 화면의 끊김이나 앞/뒤로 건너뛰는 현상이 발생할 수 있다.

각 비트레이트의 플레이리스트에 대한 정보를 포함하는 대표 m3u8 파일에서 가장 처음에 나오는 m3u8 파일의 비트레이트는 서비스에서 가장 최적의 비트레이트값을 갖도록 해야 한다. 예를 들어, 위의 그림의 파일과 같이 대표 m3u8 파일을 만들 경우 플레이어에서 처음 시작할 때 128 kbps의 데이터를 요청하게 된다. 플레이어의 네트워크 속도가 만약 768 kbps 이상이라면 높은 화질의 영상을 재생할 수 있음에도 사용자는 낮은 화질의 영상을 한동안 시청해야 한다.

각 ts 파일이 포함하는 영상의 화면 비율은 반드시 동일해야 한다. 고화질 영상은 16:9, 저화질 영상은 4:3과 같이 다른 화면 비율을 사용하게 된다면 비트레이트의 변화에 따라 부드러운 화면 변화가 불가능하다. 단 같은 비율이라면 해상도를 변화시키는 것은 가능하다. 고화질은 800x600, 저화질은 400x300의 해상도를 사용하는 것은 가능하다.

HLS의 동작 방식

서버에서 HLS 서비스가 시작되면 m3u8 파일은 분할된 파일이 생길 때마다 계속 주기적으로 바뀐다.

그림 11 시간 흐름에 따른 m3u8 파일의 변화

위의 그림을 보면 처음에는 2, 3, 4의 일련번호를 갖는 파일이 있다. #EXT-X-TARGETDURATION이 2로 명시되어 있으므로 2초 후에는 5번 파일이 생긴다. m3u8 파일의 뒤에 5번 파일을 가리키는 줄을 추가할 수도 있다. 하지만 줄을 추가하여 m3u8 파일에 명시된 콘텐츠가 늘어나면 5번 파일이 생기고 난 뒤에 스트리밍 요청을 하는 플레이어는 콘텐츠 재생을 위해 2, 3, 4, 5의 4개 파일을 요청하게 된다. 이는 초기 시작을 위한 대기 시간을 늘리고, 실제 동영상과 플레이어에서 재생하는 동영상의 시간 차이를 늘리게 된다. 그래서 일정한 개수의 파일만을 m3u8 파일에 명시하는 것을 권장한다. 이렇게 함으로써 각 사용자마다 동일한 적정 수준의 대기 시간을 제공할 수 있다.

플레이어는 동영상 재생을 위해 다음과 같이 동작한다.

플레이어는 파일을 연속적으로 재생하여, 사용자가 마치 1개의 파일을 계속 재생하는 것과 같이 끊김 없는 화면을 제공하는 것이 중요하다. 물론, 서버에서 각 분할된 파일에 포함된 데이터가 시간적으로 겹치거나 간격이 지나치게 벌어지지 않도록 파일을 만드는 것은 기본이다.

HLS를 지원하는 플레이어

현재 HLS를 지원하는 플레이어는 다음과 같다. 우선 Apple의 모바일 제품은 모두 지원하고, Android 계열의 제품은 3.0 이후 버전에서 기본으로 지원한다.

표 4

마치며

HLS는 기존의 스트리밍 프로토콜이 지닌 단점을 극복하고 스트리밍 서비스를 위한 인프라를 단순화시키려는 의도에서 나온 규격이라고 할 수 있다. 고화질 서비스를 지원하고, 네트워크 상황에 따라 원하는 비트레이트의 콘텐츠를 선택할 수 있는 기능을 제공한다. Android 3.0 기기부터는 공식적으로 HLS를 지원하여 iOS 기기 및 Android 기기에 모두 동일한 방식의 라이브 스트리밍 서비스를 할수 있게 되었다.

HLS 이외에도 HTTP 를 이용한 Adaptive Bitrate Streaming을 지원하는 스트리밍 규격이 있다. Adobe의 HTTP Dynamic Streaming과 Microsoft의 Smooth Streaming도 HTTP를 이용한 스트리밍 규격이다. 이 외에도 MPEG과 3GPP에서 동시에 규격을 정의하고 있는 Dynamic Adaptive Streaming over HTTP (DASH)도 있다.

유선 및 무선 네트워크의 속도가 빨라짐에 따라 스트리밍 서비스의 품질 역시 점점 높아지고 있으며, 이동 시에 이용이 가능한 스트리밍 서비스의 중요성도 높아지고 있다. HTTP를 이용하지 않고 서버와 플레이어 사이의 연결에 기반하는 기존의 스트리밍 규격은 이런 이동성에 약하지만, HTTP의 경우 연결 지향적(connect-oriented) 스트리밍 방식이 아니라 필요한 데이터를 그때그때 받아오는 방식이므로 이동에도 비교적 강한 특징을 가진다.

모바일 기기가 확대될수록 HTTP를 이용한 스트리밍 방식이 기존 방식의 스트리밍 서비스를 대체할 날이 멀지 않았으리라 짐작해 본다.