미디어 스트리밍
1. 들어가며..
미디어가 없었다면 통신은 훨씬 단순했을 것이다.
미디어 통신이 특별히 어려운 이유는 크게 두 가지다.
1) 데이터량이 아주 많다
2) 방송하면 실시간이다
1920년대에 영국 BBC가 기계식 TV 방송을 시작한 이래로 동영상의 실시간 전달은 인류에게 매우 중요한 테마가 되었고,
방송과 전화가 단방향과 쌍방향 통신의 주축을 이루어오다가,
디지털과 인터넷의 듀오가 통신의 개념을 뒤집고,
기술적으로는 이제 방송이 패킷 통신 형태의 미디어 스트리밍을 뒤쫒아 가는 형국이다.
(2013년 지상파 아날로그 방송이 종료되고 디지털방송으로 전환됐지만 대세는 IPTV이다. 방송사가 통신사보다 여전히 우위에 있는 것은 기술이 아닌 콘텐츠 제작/유통 능력 때문이다.)
미디어 스트리밍이 기술적으로 방송을 리드할 수 있게 된 이유는 헝그리 정신 때문이다.
방송은 일찌감치 대중을 열광시킨 결과 수십조 원의 가치를 가진 주파수 대역을 점유하면서 여유있는 살림을 한 반면,
속도도 별로 안나오는 인터넷 세상에서 포털, 메일, 게임 등과 무한경쟁을 해야 했던 미디어 스트리밍은 화면깨짐과 버퍼링의 나락에 빠지지 않기 위해 끝없이 노력해야만 했다.
이제 미디어 스트리밍의 시조라고 할 수 있는 RTSP와 함께 본격적인 이야기를 시작해 보자.
2. RTSP
지금은 퇴물이 되어가고 있지만, 한때 RTSP가 미디어 스트리밍의 전부이던 시절이 있었다.
인터넷이 나오고 통신 속도가 점점 빨라지면서 사람들에게 욕심이 생기기 시작한다. 영화와 방송을 PC로 보고 싶다는 욕심.
하지만 만들어진 파일을 전송하는 일에만 익숙한 인터넷이 어떻게 시작과 끝이 없는 방송을 전달할 것인가? 두 시간 짜리 영화를 보기 위해 다운로드가 완료될 때 까지 한 시간 넘게 기다려야만 하는가? 1996년, 이 답답함을 해결할 실마리가 세상에 나왔다. 이름하여 Real Time Streaming Protocol.
오디오와 비디오가 각각 어떤 형식으로 압축되어 있는지, 1초에 몇 프레임 재생돼야 하는지, 둘의 sync를 어떻게 맞추면 될지 등등 서버와 클라이언트가 상세한 대화를 나눈 뒤에 서버가 데이터를 뿌리기 시작하면 클라이언트는 정신없이 패킷을 수신하고, 순서를 맞추고, 압축을 풀고, sync를 맞추어 화면과 스피커에 동영상을 출력한다. 조금의 delay가 있긴 하지만 실시간 방송도 가능하고, 한 시간이 아니라 몇초만에 영화를 볼 수도 있다.
쉽지는 않았다. 지금은 모바일로도 HD가 대세지만 불과 2008년만 해도 모바일에선 QVGA(320*240)가 '고'해상도 였으니..
**그림 출처: 위키피디아
방송과 DVD는 커녕 DMB를 따라 잡기도 벅찬 세월이 십수년 이어졌다. 하지만 H.264라는 걸출한 압축기술의 등장으로 데이터량을 절반가까이 줄이고 전송 속도도 기하급수적으로 빨리지면서 2000년대 후반 드디어 유튜브, 넷플릭스 등 RTSP를 이용한 미디어 스트리밍으로 떼돈을 버는 비즈니스 모델이 나오기 시작했고, IPTV까지 가세하여 RTSP는 꽃을 활짝 피우게 된다.
(RTSP에 대한 기술적인 이야기는 생략하려고 한다. 다만 편의상 RTSP라고 하지만 실제 미디어 전송은 RTP로 이루어 진다는 것만 짚고 넘어가도록 한다.)
3. HLS
한 때 RTSP 엔지니어였던 필자로서는 매우 아쉽게도 RTSP는 꽃을 피우자 마자 바로 시들어 가게 되는데, 그 중심에는 애플의 엔지니어 들이 있다. RTSP의 치명적인 약점은 너무 복잡하다는 것이다. 오디오와 비디오 코덱의 종류는 수 십 가지가 있는데(https://en.wikipedia.org/wiki/List_of_codecs), 그 코덱의 종류마다 RTP 패킷으로 만드는 방법이 별개의 표준문서로 정의되어 있고, 막상 구현하려다 보면 모호한 부분도 많아서 주기적으로 업체들이 모여 호환성에 대한 시험도 진행해야 한다. 이렇게 복잡하다 보니 당연히 서버와 클라이언트(플레이어) 모두 값이 비싸진다. 투자비가 많이 들게 되니 시장도 활성화 되기 어렵다.
이 상황에서 갑자기 애플이 HLS라는 기술을 들고 나왔다. 방송에서 사용되는 MPEG2-TS라는 전송 포맷을 사용하는 것 빼곤 아주아주 단순한데, 전송할 미디어를 조각내어 보통 10초 가량의 파일로 만들고 플레이리스트와 함께 전송한다. 클라이언트는 플레이리스트를 보고 조각난 파일을 이어서 재생하고 가끔씩 플레이리스트를 업데이트 한다. 이게 전부다.
RTSP와 결정적인 차이는 RTSP가 스트리밍읠 위해 파일을 풀어서 전송한 반면, HLS는 파일의 형식에 맞추어 전송한다는 것인데, 이게 서버와 클라이언트 모두를 굉장히 단순하게 만들어준다. RTSP의 구현 난이도가 100이라면 애플에서 만든 HLS는 10~20정도 되는 것 같다.
(사실 HLS가 2009년 보다 더 일찍 나왔다면, 대세가 되지 못했을 수도 있다. 미디어 전송을 UDP/RTP가 아닌 TCP/HTTP로 하려면 전송속도의 뒷받침이 필수다.)
유튜브가 2010년 경 발빠르게 RTSP에서 HLS로 돌아섰고, 이제는 대부분의 모바일 스트리밍에서 HLS를 이용한다. 초기 투자비가 훨씬 더 싸기 때문에 신규 서비스는 거의 모두 HLS라고 보면 된다.
4. 마치며..
PC나 폰으로 동영상을 보는 방법은 크게 두 가지로 나눌 수 있다.
1) 저장된 파일을 재생하기
2) 실시간으로 전송을 받아 재생하기
아, 야메(?)같은 방법이 한 가지 더 있다.
3) 파일을 다운로드 받으면서 재생하기
이 글에서는 2번에 대해서만 이야기했으나, 사실 3번도 미디어 스트리밍이라고 볼 수 있다.(구분을 위해서는 progressive download라고 부르기도 한다.) 어쨌든 세 가지는 모두 서로 밀접한 연관을 가지며 발전해나가는 관계이다. 미디어 스트리밍을 제대로 이해하기 위해서는 저장된 미디어 파일을 재생하는 기술에 대한 이해도 필수이다.
조금 더 심도 있는 이야기는 다음 기회에 해보려 한다..
엮인글: 동영상이란?
미디어가 없었다면 통신은 훨씬 단순했을 것이다.
미디어 통신이 특별히 어려운 이유는 크게 두 가지다.
1) 데이터량이 아주 많다
2) 방송하면 실시간이다
1920년대에 영국 BBC가 기계식 TV 방송을 시작한 이래로 동영상의 실시간 전달은 인류에게 매우 중요한 테마가 되었고,
방송과 전화가 단방향과 쌍방향 통신의 주축을 이루어오다가,
디지털과 인터넷의 듀오가 통신의 개념을 뒤집고,
기술적으로는 이제 방송이 패킷 통신 형태의 미디어 스트리밍을 뒤쫒아 가는 형국이다.
(2013년 지상파 아날로그 방송이 종료되고 디지털방송으로 전환됐지만 대세는 IPTV이다. 방송사가 통신사보다 여전히 우위에 있는 것은 기술이 아닌 콘텐츠 제작/유통 능력 때문이다.)
미디어 스트리밍이 기술적으로 방송을 리드할 수 있게 된 이유는 헝그리 정신 때문이다.
방송은 일찌감치 대중을 열광시킨 결과 수십조 원의 가치를 가진 주파수 대역을 점유하면서 여유있는 살림을 한 반면,
속도도 별로 안나오는 인터넷 세상에서 포털, 메일, 게임 등과 무한경쟁을 해야 했던 미디어 스트리밍은 화면깨짐과 버퍼링의 나락에 빠지지 않기 위해 끝없이 노력해야만 했다.
이제 미디어 스트리밍의 시조라고 할 수 있는 RTSP와 함께 본격적인 이야기를 시작해 보자.
2. RTSP
지금은 퇴물이 되어가고 있지만, 한때 RTSP가 미디어 스트리밍의 전부이던 시절이 있었다.
인터넷이 나오고 통신 속도가 점점 빨라지면서 사람들에게 욕심이 생기기 시작한다. 영화와 방송을 PC로 보고 싶다는 욕심.
하지만 만들어진 파일을 전송하는 일에만 익숙한 인터넷이 어떻게 시작과 끝이 없는 방송을 전달할 것인가? 두 시간 짜리 영화를 보기 위해 다운로드가 완료될 때 까지 한 시간 넘게 기다려야만 하는가? 1996년, 이 답답함을 해결할 실마리가 세상에 나왔다. 이름하여 Real Time Streaming Protocol.
오디오와 비디오가 각각 어떤 형식으로 압축되어 있는지, 1초에 몇 프레임 재생돼야 하는지, 둘의 sync를 어떻게 맞추면 될지 등등 서버와 클라이언트가 상세한 대화를 나눈 뒤에 서버가 데이터를 뿌리기 시작하면 클라이언트는 정신없이 패킷을 수신하고, 순서를 맞추고, 압축을 풀고, sync를 맞추어 화면과 스피커에 동영상을 출력한다. 조금의 delay가 있긴 하지만 실시간 방송도 가능하고, 한 시간이 아니라 몇초만에 영화를 볼 수도 있다.
쉽지는 않았다. 지금은 모바일로도 HD가 대세지만 불과 2008년만 해도 모바일에선 QVGA(320*240)가 '고'해상도 였으니..
**그림 출처: 위키피디아
방송과 DVD는 커녕 DMB를 따라 잡기도 벅찬 세월이 십수년 이어졌다. 하지만 H.264라는 걸출한 압축기술의 등장으로 데이터량을 절반가까이 줄이고 전송 속도도 기하급수적으로 빨리지면서 2000년대 후반 드디어 유튜브, 넷플릭스 등 RTSP를 이용한 미디어 스트리밍으로 떼돈을 버는 비즈니스 모델이 나오기 시작했고, IPTV까지 가세하여 RTSP는 꽃을 활짝 피우게 된다.
(RTSP에 대한 기술적인 이야기는 생략하려고 한다. 다만 편의상 RTSP라고 하지만 실제 미디어 전송은 RTP로 이루어 진다는 것만 짚고 넘어가도록 한다.)
3. HLS
한 때 RTSP 엔지니어였던 필자로서는 매우 아쉽게도 RTSP는 꽃을 피우자 마자 바로 시들어 가게 되는데, 그 중심에는 애플의 엔지니어 들이 있다. RTSP의 치명적인 약점은 너무 복잡하다는 것이다. 오디오와 비디오 코덱의 종류는 수 십 가지가 있는데(https://en.wikipedia.org/wiki/List_of_codecs), 그 코덱의 종류마다 RTP 패킷으로 만드는 방법이 별개의 표준문서로 정의되어 있고, 막상 구현하려다 보면 모호한 부분도 많아서 주기적으로 업체들이 모여 호환성에 대한 시험도 진행해야 한다. 이렇게 복잡하다 보니 당연히 서버와 클라이언트(플레이어) 모두 값이 비싸진다. 투자비가 많이 들게 되니 시장도 활성화 되기 어렵다.
이 상황에서 갑자기 애플이 HLS라는 기술을 들고 나왔다. 방송에서 사용되는 MPEG2-TS라는 전송 포맷을 사용하는 것 빼곤 아주아주 단순한데, 전송할 미디어를 조각내어 보통 10초 가량의 파일로 만들고 플레이리스트와 함께 전송한다. 클라이언트는 플레이리스트를 보고 조각난 파일을 이어서 재생하고 가끔씩 플레이리스트를 업데이트 한다. 이게 전부다.
RTSP와 결정적인 차이는 RTSP가 스트리밍읠 위해 파일을 풀어서 전송한 반면, HLS는 파일의 형식에 맞추어 전송한다는 것인데, 이게 서버와 클라이언트 모두를 굉장히 단순하게 만들어준다. RTSP의 구현 난이도가 100이라면 애플에서 만든 HLS는 10~20정도 되는 것 같다.
(사실 HLS가 2009년 보다 더 일찍 나왔다면, 대세가 되지 못했을 수도 있다. 미디어 전송을 UDP/RTP가 아닌 TCP/HTTP로 하려면 전송속도의 뒷받침이 필수다.)
유튜브가 2010년 경 발빠르게 RTSP에서 HLS로 돌아섰고, 이제는 대부분의 모바일 스트리밍에서 HLS를 이용한다. 초기 투자비가 훨씬 더 싸기 때문에 신규 서비스는 거의 모두 HLS라고 보면 된다.
4. 마치며..
PC나 폰으로 동영상을 보는 방법은 크게 두 가지로 나눌 수 있다.
1) 저장된 파일을 재생하기
2) 실시간으로 전송을 받아 재생하기
아, 야메(?)같은 방법이 한 가지 더 있다.
3) 파일을 다운로드 받으면서 재생하기
이 글에서는 2번에 대해서만 이야기했으나, 사실 3번도 미디어 스트리밍이라고 볼 수 있다.(구분을 위해서는 progressive download라고 부르기도 한다.) 어쨌든 세 가지는 모두 서로 밀접한 연관을 가지며 발전해나가는 관계이다. 미디어 스트리밍을 제대로 이해하기 위해서는 저장된 미디어 파일을 재생하는 기술에 대한 이해도 필수이다.
조금 더 심도 있는 이야기는 다음 기회에 해보려 한다..
엮인글: 동영상이란?
댓글
댓글 쓰기