Video Streaming 이해

RTMP, RTSP에 관하여 조사하다가 괜찮은 자료가 있어서 퍼왔다.

 

출처 : http://www.sagomi.com/index.php/2011/08/13/understand-videostreamin/

 

 

우리는 하루에도 수없이 많은 비디오를 YouTube, 개인 블로그, 일반 웹사이트, 인터넷 언론사, iPhone 등의 웹에서 보고 있습니다.  웹에서 보는 비디오 는 거의 비슷하게 보이지만 사실 그 안을 들여다 보면  서로 다른 기술이 사용됩니다. 웹상의 비디오 사용은 하루가 다르게 더 편하고, 더 빠르고, 더 효율적인 방향으로  점점 발전하고 있습니다. 그 이유는 비즈니스 목적의 비디오 사용과 소셜미디어의  폭발적인  증가에 기인합니다. 전세계적으로 YouTube, Justin.tv를 포함하여 비디오 서비스를 다루는 사이트가 알려진 것만 해도 약 100여개가 넘습니다.

웹캐스팅, 인터넷  방송, 웨비나, VOD 서비스, 비디오 공유 소셜 미디어사이트 등 비디오를 활용하는 애플리케이션을 비즈니스에 활용하기 위해서는 비디오가 어떻게 우리 눈에 보일 수 있도록 인터넷으로 전송되는지에 대한 기술적인 이해를 할  필요가 있습니다. 그래야만 더 고객 지향적이고 확장 가능한  비즈니스 서비스 환경을 만들 수 있기 때문입니다.  사라질 기술을 잘 못  선택하면 2-3년 후 전체를 다시 검토해야하는 낭패를 볼 수 있습니다.

이번 글에서는 비디오를 전송하는 다음과 같은 3가지 기술 과 그 장,단점에 대해 살펴보겠습니다.

* 멀티캐스트 (Multi-cast) 와 P2P 방식의 스트리밍은 특정한 경우를 제외하고 일반적으로 비즈니스 용도로 사용하지 않으므로 제외합니다.

• 프로그래시브 다운로드 (Progressive Download)
• RTMP/RTSP 스트리밍 (RTMP/RTSP Streaming)
• 어댑티브 HTTP 스트리밍 (Adaptive HTTP Streaming)

프로그래시브 다운로드 (Progressive Download)

현재 Live가 아닌 VOD 서비스 시장에서 가장 광범위하게 사용되는 비디오 전송 방식입니다. 전세계 비디오 트래픽의 약 55%가 이 방식으로 사용된다고 합니다.  이 방식에 가장 크게 기여하는 사이트는  YouTube, ESPN, CNN 등 입니다.

단어에서 알 수 있듯이 점진적(Progressive)으로 내 컴퓨터로 다운로드하여 play되는 방식이며, 미디어 서버가 아닌 웹서버에 비디오를 올려놓고 URL주소를 player에 링크만 걸면 되므로 가장 쉽고 비용 절감적인 방법입니다. 웹서버를 사용하므로 HTTP 프로토콜을 사용합니다.

시청자가 비디오를 틀릭하면 웹서버로 부터 즉시 다운로드가 시작됩니다.  다운로드 즉시 play가 될 수도 있고, 좀 더 시간이 지난 후 play될 수도 있습니다.  (전체 파일이 다운로드 될 필요는 없습니다.) 그 이유는 시청자의 인터넷 다운로드 속도가 어느정도 확보되어 있는가에  달려있습니다. 중간 부분을 보려해도  그 부분까지 아직 다운로드가 되지 않았으면 시청이 불가능 합니다. 즉 그냥 기다려야 합니다. 하지만 비디오를 웹에서 다루기에 가장 쉽습니다.

이 방식의 단점은 내 컴퓨터로 파일을 다운로드하며 가져오는 방식이므로 보안에 문제가  있으며, 유료 비디오 서비스를 위한 사이트에 사용할 수는 없습니다.  다만 시청이 끊나면 다운로드된 비디오는 삭제됩니다. 이런 이유로 YouTube 비디오를 내 컴퓨터로 통채로 다운로드 할 수 있는 무료 프로그램이 무수히 많이 있습니다. ( 무료 YouTube Downloader 를 설치하여 시도해 보시기 바랍니다.  )

또한 이 방식은  라이브 스트리밍 (Live Streaming)을 지원하지 않으므로 라이브 중계에는 사용할 수 없습니다.

대부분의 비디오 호스팅 업체는 bandwidth  traffic 사용을 비용의 중요한 부분으로 계산하는데 이 방식은 bandwidth 효율성이 매우 떨어집니다. 예를 들어 1GB 사이즈의 비디오를 보려고 클릭하였는데 보다 보니 원하는 것이 아니라서 닫았습니다. 그러나 이미 다운로드가 300MB 되었다면 호스팅 업체는 300MB에 대한 비용을 계산한다는 것입니다. 물론 이 비용은 시청자가 아니라 비디오를 올린  회사에서 호스팅 비용으로 지불하겠지만, 수 천개의 비디오를 웹서버에 저장하여 활용하는 회사인 경우 그 비용은 기하급수적으로 늘어나게 됩니다.

이 방식의 또 다른 단점은 한번 비디오가 play되면  중간에 비디오 퀄러티를 능동적으로 변경할 수 없다는 것입니다.  즉 중간에 fullscreen을 클릭하여 화면 사이즈가 커져도 화질은 자동 변경이 되지 않는다는 의미입니다. 미리 정해진 화질로 내려 받습니다.

프로그레시브 다운로드 방식을 그림으로 보면 다음과 같습니다. 그냥  무조건 기다리면 볼 수 있습니다. 전적으로 시청자의 다운로드 bandwidth 상태에 달려 있습니다. 모 공공사이트의 1시간  이러닝 강의을 이  방식으로 제공하는데  일부를 보고 다음 날 보고자하면 처음부터 다시 보아야 합니다. 죽는 일이지요.

Progressive Download Example from Vimeo 

대표적인 비디오 공유 사이트 Vimeo에서 가져온 샘플입니다.  다운로드되는 상태 바를  보실 수 있으며, 2분 앞쪽을 클릭하셔도 비디오가 다운로드 되지 않았기 때문에 전혀 play가 되지 않는다는 것을 알 수 있습니다.

 

HTTP Pseudo-Streaming

YouTube는 사이트가 점점 커지다 보니 이런 고민이 생겼을 겁니다.  Bandwidth 사용이 너무 비효율적이다. 그리고  고화질 비디오의 제공이 어렵다.  라이브도 않된다. HD 비디오로 올려 놓아도 모뎀 환경에 있는 시청자가 클릭하면 과연 볼 수 있을 것인가 ? 몇 %나 볼 수 있을까 ? 그렇다면 어떻게 해야하나 ?

이러한  프로그래시브 다운로드의 일부 단점을 보완하기 위한 HTTP Pseudo-Streaming 기술이 나왔습니다.  pseudo- 는 가짜라는 접두어이며, 말 그대로 정상적인 스트리밍 기술이 아닌 유사한 가짜 스트리밍 기술입니다. 이 방식은  아직 다운로드 되지 않은 부분을 클릭하더라도  메타 프레임 정보를 가지고 잇어서 그 부분의 메타프레임부터 다시 다운로드를 시작하여 play되므로 중간부터 볼 수 있도록 해주는 기술입니다. bandwidth 효율성을 어느 정도 놓여주며,  웹서버에 특별한 모듈을 설치하여야 작동하며  flash player와 HTML5 player에서  지원됩니다. (여러분이 사용하시는 비디오 플러그인에 따라 지원 가능할 수도 있고 아닐 수도 있다는 이야기입습니다.) 또한 비디오 화질을 시청자가 선택하게끔 제공합니다.

YouTube를 보시면 240p, 360p, 480p 를 시청자 스스로가 본인의 가용 다운로드 bandwidth 한도에서 스스로 선택하게끔 되어있습니다.  고객 편의를 위해 미리 3가지 형태로 엔코딩하여 올려놓은 것을 선택하게끔 만든 것이지요. 이 것을 자동화 할 수는 없을까요 ? 누군가 생각했겠죠.

Pseudo-Streaming Example from YouTube 

Vimeo 비디오와 비교하여 살펴 보시기 바랍니다.

RTMP/RTSP 스트리밍 (RTMP/RTSP Streaming) 

우선 이 방식의 이해를 돕기위해 프로토콜에 대해 잠시 설명합니다. 이런 이야기가 있습니다. 난 그녀와 프로토콜이 맞는다. 무슨 이야기 인가요 ? 그녀와 나는 눈 빛만으로도 무슨 의미인지 안다는 이야기입니다. 통신도 마찬가지 입니다. 주고 받는 프로토콜이 서로 맞아야 데이타를 주고 받을 수 있습니다.

HTTP (Hypertext Transfer Protocol ) : World Wide Web을 위한 데이터 통신 표준 프로토콜입니다. 여러분들이 보시는 웹사이트가 바로 HTTP 프로토콜을 사용합니다. 방화벽의 80 포트를 기본으로 사용합니다.

MMS (Microsoft Media Server) Protocol : 마이크로소프트가 비디오 전송을 위해 오래전 만든 프로토콜입니다. MS는 현재HTTP 프로토콜을 사용하는 IIS Smooth Streaming을 적극적으로 홍보하므로 이 글에서는 제외합니다. player plugin으로는mms는 Windows media player, IIS Smooth Streaming 은 Silverlight player를 사용합니다.

RTMP (Realtime Messaging Protocol) : Adobe에서 인수한 Macromedia에서 만든 비디오 전송을 위한 프로토콜입니다. 보안안성을 강화한 RTMPS, RTMPE 방법도 있습니다. player plugin으로는 flash player를 사용합니다. 방화벽 포트는 80 과 1935를 사용합니다.

RTSP (Realtime Streaming Protocol ) : IETF(Internet Engineering Task Force)의  MMUSIC Working Group에서 만든 국제표준 멀티미디어 전송 프로토콜입니다. 불행이도 대부분의 호스팅 업체와 CDN업체에서 지원을 하지 않아 많이 사용되고 있지 않습니다.

Pseudo-streaming으로 일부 단점을 보완하였지만 그래도 가장 중요한 몇 가지 이슈가 남아있습니다.

• 라이브 중계가 어렵다.
• 보안상 문제가 있다. (HTTP 프로토콜은 RTMP 프로토콜보다 훔치기 쉽다.)
• 여전히 bandwidth 효율성이 떨어진다. (장시간 비디오 사용 불가)

자 그럼 한번 생각해 보겠습니다.  평균1시간  분량의 드라마/영화 수백편을 온라인 서비스한다고 가정해 봅니다. 프로그래시브 다운로드 방식으로 사이트를 구축하면 어떤 문제가 발생할까요 ?

고객의 불만이 늘어날 것입니다. 다운로드하는데 느리고..내가 보고 싶은 부분부터 볼수가 없으니 얼마나 답답하겠습니까 ? 보안도 문제지요 콘텐츠를 마구 컴퓨터로 저장하여 P2P 사이트에 올리면 어떻게 되겠습니까 ? 또한 bandwidth 효율성은 엄청 떨어질 것입니다. 바로 문닫게 될 것입니다. 고민이 있으면 해결 방법을 찾겠지요.

RTMP/RTSP 스트리밍은 이런 문제를 해결하기 위해 나온 기술이며,  이러닝, VOD 서비스, 라이브 중계 등의 분야에서 가장 많이 사용되고 있습니다.  이 방식은 전체 파일을 보내는 개념이 아니라 시청자가 시청하려는 부분의 몇 프레임만을 전송합니다.

즉,  시청가가 보려고 하는 장면을 찾아 클릭하면 그 부분의 프레임부터 play되고 지나간 프레임은 자동 삭제되는 방식입니다.(psudo-streaming 방식은 지난 것은 삭제되지 않고 저장 됨.)   순간 시점의 프레임을 본다고 생각하시면 됩니다.

라이브 중계가 가능하며, 다운로드가 없어 보안에 문제가 없으며 아울로 bandwidth 효율성이 좋아집니다.

그림으로 보면 다음과 같습니다.

그럼 이 방식의 단점은 없을까요 ?

이 방식은 시청자가 클릭하는 부분의 프레임을 보내기 위해 특별한 웹서버를 사용하는데 이 것을 우리는 스트리밍 서버 (또는 미디어 서버)라고 합니다.  그리고 특별한 유료 소프트웨어가 필요한데 대표적인 것으로 FMS ( Flash Media Server)  와 WMS ( Wowza Media Server ) 가 있습니다.  즉 물리적인 하드웨어 와 추가적인 소프트웨어가 필요합니다.  그리고 비디오 서비스를 위해 전문 기술자가  필요한 서버를 관리해야하는 추가적인 일들이 발생합니다.

또한 RTMP 프로토콜은 HTTP와는 다르게 방화벽의 80 과 1935 포트를 사용하는데 종종 보안을 위해 1935 포토를 막아 놓은 회사들이 있습니다. 누군가는 서비스를 받지 못한다는 이야기 입니다.  여러분이 어떤 웹사이트에서  live이던 on-demand이던 화면이 안보이시는 경우는 .. 방화벽의 000포트를 열어서..어쩌고 저쩌고.뭐시기 ..이런 잡다한 내용을 FAQ에 늘어 놓는다면 미디어 서버를 사용하는 MMS 스트리밍 이나 RTMS 스트리밍 방식일 것입니다.

장점은 많지만 추가 비용이 발생하고 관리가 복잡합니다. ( 1935 포트가 막힌 것을 감지하고 자동으로 80포트로 자동 전송하는 아주 지능적인 player도 있습니다. )

스트리밍의 대 전제는 전송하는 비디오 데이타레이트보다 시청자의 다운로드 bandwidth가 반드시 커야한다는 것입니다.

예를 들어 HD급의 1.7Mbps 로 엔코딩한 비디오를 서비스한다고 생각해 보면 시청자는 반드시 2Mbps 이상의 다운로드 bandwidth를 확보하고 있어야 합니다. 만일 그 순간 같은  망에 있는 몇몇이 10MB 파워포인트를 이메일로 보냄에 따라 500kbps로 다운로드 속도가 떨어지면 어떻게 될까요 ?  완전 스톱입니다. 진행이 되지 않습니다.

그럼 이런 문제는 어떻게 해결해야 할까요 ? RMTP/RTSP 스트리밍에서는 기본적으로 위 그림에서 보듯이 서로 다른  bit-rate로 엔코딩 된 비디오 파일  3-4개를 서버에 저장하여 제공함으로 클라이언트는 중간에 화질을 교체할 수 있습니다.

RTMP/RTSP  Streaming Sample from Hulu

Hulu는 미국내 에서만 서비스를 제공하는데 장시간/고화질의 유료 TV 드라마, 영화 온라인 서비스 사이트입니다. 이해를 돕기 위해 Movie Trailer를 가져왔으니 위의 프로그래시브 다운로드 방식과 어떻게 다른가 비교하여 보시기 바랍니다.

 

어댑티브 HTTP 스트리밍 (Adaptive HTTP Streaming)

이 전송 방식은 비교적 최근에 나온 기술입니다.  기존 방법의 문제점과 HD화질 전송 및 모바일 환경의 디바이스에 비디오 전송을 고민하다 보니 이 방법도 시원 찮고 저 방법도 시원 찮아 개발된 기술입니다. 모바일  기기는 이동중에  bandwidth가 수시로 변하기 때문에 비디오를 시청하기가 매우 어렵습니다.  이 기술은 Move Networks사의 특허 기술인 adaptive bitrate  기술에서 출발합니다. adaptive란 단어가 들어간 이유는 시청자 bandwidth 환경을 스스로 인지하여 그에 맞는 스트리밍을 자동으로 보내준다는 의미 입니다. 처음 이 기술을 사용하여 실전에 적용된 사례는 2008년 베이징 올림픽 인터넷 라이브 중계를 마이크로소프트사의  IIS Smooth Streaming 기술을 사용한 것이 처음입니다.  Apple은 2009년 중순 iPhone 3.0 출시와 함께 HTTP Live Streaming 이란 이름으로  iOS 기반의 디바이스에 Live 중계와 VOD 서비스를 위해 출시하였습니다.  Adobe사는 2009년 말 Adobe HTTP Dynamic Streaming (프로젝트 이름 ; Zeri )이란 이름으로 이 기술을 발표하였습니다.

이 기술은 프로그래시브 다운로드 방식의 장점 ( 미디어 서버와 같은 비싼 장비와 RTMP 프로토콜같은 복잡한 것을 사용하지 않는다.) 과 RTMP 방식의 장점 (bandwidth 효율성 이 뛰어나고 비디오 화질 변경이 용이하다.)을 혼합한 것입니다.

기술적인 기본 개념은 아래 그림 (위의 다른 방식의 그림과 비교해 보세요. )과 같이 엔코딩 비디오를 통채로 저장 하는 것이 아니라 작은 조각 (몇 초 단위, chunk라고 함)으로 잘라서 저장하고 시청자가 원하는 부분을 클릭하면 그 부분 조각을 순서적으로 보내주는 것입니다.  통상 3,4개의 bitrate로 엔코딩된 비디오 파일과 타임 인터벌 매트릭스 형태로  구성된 XML로된 master 파일이 있어서 서버와 클라이언트 사이에 교신하여 시청자의 bandwidth 상황/CPU 사용을 체크하여 그에 맞는 화질을 전송받는 방식입니다. 물론 비디오 서비스 공급자는 300kbps, 700kbps, 1Mbps, 1.7Mbps 등 3,4개의 bitrate로 엔코딩하여 저장해야하는 불편은 있습니다.

iPhone, iPad 용 m-Learning, e-Learning , VOD , 라이브 서비스를 한다는 업체들이 H.264/AAC 코덱의 mp4 포맷으로 엔코딩하여 제공한다는 것은 pseudo-streaming을 한다는 의미이고,  HTTP Live Streaming이 아닙니다. 저희가 서비스하는 i OS용 엔코딩 서비스는  다양한 비트레이트의 다양한 파일로 나타납니다. 업체가 모르는 것인지 속이는 것이지 아무튼… 

이 방식은 불행하게도 아직 표준이 없고 IT 빅브라더들인 Apple, MS, Adobe 가 독자적인 기술로 또 다른 전쟁을 하고 있습니다.  Apple은 자신의 방식을 IETF에 표준으로 제출한 상태입니다.  다행이도 3GPP/MPEG 컨소시움은 DASH 라는 이름으로 이 기술 표준화에 앞장서고 있습니다.

과연 차세대 비디오 시장의  이 밥그릇 싸움은 누구의 승자가 될까요 ?  매우 궁금합니다.

이 adaptive HTTP streaming 방식은 차후 자세하게 다루어 보도록 하겠습니다.

정리 (Summary)

언급한 3가지 방식을 표로 정리해 보겠습니다.

 

맺음말

어떤 방식을 목적하는 비즈니스에 사용해야 할까요 ?  정답은 없는 것 같습니다.  상황에 따라 다를 것입니다.

• 3분이내의 짧은 비디오 여러개를 웹페이지에서 활용하십니까 ?
• 장시간의 이러닝용 영상을 서비스하려하십니까 ?
• 모바일 기기에도 활용하시겠습니까 ?
• 유료 콘텐츠서비스인가요  ? 무료 콘텐츠 서비스인가요 ?
• 라이브 중계가 필요한 것인가요 ?
• 비디오 품질이 중요한가요 ? HD급이 필요한가요 ?
• DRM은 필요한가요 ?

여러분의 비즈니스 목적이 무엇인가에 따라 최적의 조합의 방법을 찾아야 할 것입니다.

저 라면 어쩌겠냐구요 ?

무조건 Adpative HTTP Streaming으로 합니다. 가장 진보된 방법이니까요..

근데 Big Brother Apple, MS, Adobe 중 어느 방식을 선택해야할까요 ?  표준화는 어떻게 되나요 ? 누구 아시는 분 계시면 답좀 주세요 !