WWW 을 통한 비디오 전송
- Broadcasting Over the Internet

박경순
(주)아이네트
정보기술실 iWorld팀
E-mail : sosarian@iWorld.net
URL : http://www.iWorld.net/~sosarian/
Abstract:
현대 사회에서 가장 중요한 매체의 하나로 급부상한 WWW은, 네트웍 속도의 증가와 WWW기술의 발전, 인터넷 사용자의 기하급수적인 증가로 인하여 멀티미디어적 요소에 대한 필요성이 대두되어 기존의 평면적이고 단방향적인 홈 페이지에 오디오, 비디오등과 같은 contents가 추가되고 있는 실정이다. 하지만, 이러한 멀티미디어 데이터는 그 데이터량이 방대하여, 상대적으로 느린 현재의 네트웍 속도로는 본격적인 서비스가 불가능하다. 이를 해결하기 위한 노력으로, 데이터를 높은 효율로 압축하여 보다 빠른 전송을 꾀하기도 하고, 데이터 자체를 스트리밍(streaming)하여 받으면서 동시에 보여주는 실시간 전송 기술이 선보이게 되었다.

여기서는 이러한 실시간 전송 기술에 대하여 알아보고, 현재 WWW에서 비디오 데이터를 서비스할 수 있는 방법과 종류, 그리고 최근 많은 관심을 불러 일으키고 있는 인터넷 생방송에 대한 궁금증을 풀고, 앞으로의 전망과 방향을 미리 생각 해 봄으로써 미래의 인터넷과 멀티미디어 환경에 대하여 가늠 해 보고자 한다.
Tutorial 세션임을 감안하여, 일반인이 손쉽게 구현할 수 있는 방법도 간단한 예와 함께 소개하고 있다.

Keywords:
Video, VOD, WWW, Broadcasting, MPEG

Table of Contents

1. WWW과 Video

1.1. 현재 WWW의 방향

91년 HTML 규약이 처음 발표된 이래로 5년동안 WWW은 실로 그 예를 찾아볼 수 없을정도로 빠른속도로 퍼져나갔다. 학술정보의 공유를 목적으로 시작한 WWW은 점차 기업의 홍보, 온라인 서비스에 이용되면서 약간의 지식만 가지고 있다면 개인도 자신의 홈페이지를 손쉽게 작성 할 정도로 대중화 되었다. 이렇게 많은 사람이 사용하고 그 시장성이 인정받으면서, 3차원 공간을 표현하는 VRML(1), 새로운 인터넷 언어로 각광받고 있는 Java(2), 기존의 데스크톱 환경과의 유기적 결합을 꽤하는 ActiveX(3)등을 비롯, 자연히 멀티미디어에 대한 열망이 일어나게 되었으나, 그 소프트웨어적 기술의 급성장에 반하여, 그 하부구조인 네트웍의 속도는 그다지 큰 성장을 이루지 못하고 있는 실정이다.

1.2. WWW과 Video 결합의 문제점

1.2.1. 네트웍 속도의 문제

앞서 언급했다시피, 멀티미디어 데이터는 그 양이 대단히 크고, 그것을 나의 PC로 가져오기에는 네트웍의 속도가 너무 느리다는데 근본적인 문제점이 있다. 가장 일반적으로 사용하는 모뎀의 경우 대부분 28.8Kbps의 속도이고 이것은 초당 최대 28.8Kbytes의 데이터를 가져올 수 있다는 의미이다. 그러므로 10Mbytes의 데이터를 가져오는데는 약 1시간이 걸린다는것을 알 수 있다. 이것은 5분도 안되는 비디오 클립을 보기 위하여 1시간을 기다려야 한다는 의미이다.

1.2.2. 프로토콜상의 문제

HTTP 는 서버와의 연결이 지속적이지 않기 때문에 불가능하며, TCP나 UDP는 불필요한 Acknowledge 헤더나, 불안정한 데이터 전송으로 인하여 Video, Audio의 frame loss, bitrate loss 문제가 발생한다. 하지만 인터넷 자체가 TCP/IP를 기반으로 하고 있기 때문에, 당장 이 문제를 해결하기는 쉽지 않을 것으로 보인다. 따라서 대부분의 시도는 TCP나 UDP를 이용하면서, 그 안에서 다른 방법을 모색하고 있거나, 네트웍 대역폭 손실을 줄이기 위한 방안으로는 기존의 IP unicasting 이외에, IP multicasting 방식을 사용하고 있다.

2. Video Service

2.1. Video Data Format

크게 이 세가지 비디오 포맷이 가장 많이 사용되어 왔기 때문에 대부분의 product들은 이들 포맷을 변형, 혹은 그대로 이용한다.

2.2. 실시간 비디오 전송

위에서 언급한 프로토콜상의 문제는 인터넷 자체가 TCP/IP 기반으로 운영되기 때문에 당장 탈피하기는 현실적으로 어려움이 있고, 네트웍 속도 역시 단기간에 해결될 문제가 아니기 때문에, 현재의 인프라에서 소프트웨어적으로 해결하고자 하는 노력의 결과로 여러가지의 기술들이 생겨났다.

2.2.1. 데이터 압축



위에서 언급한 포맷의 데이터를 최대한 압축하여 전송 시간을 단축시키고 Client에서 decompress하여 보여주는 방법이다. 이 방법은 Server의 부하를 줄일 수 있고, 별도의 Video Server가 필요치 않으므로 비용면에서 유리하나, 데이터량이 크기에 따라 전송 시간이 오래걸린다. 따라서, 데이터 압축과 streaming을 겸하여 사용하는 경우가 대부분이다. 별도의 서버를 사용하는 경우에 비하여, 네트웍 속도와 부하에 상당히 많은 영향을 받으며, frame rate가 떨어진다.

2.2.2. 데이터 Streaming

위에서 언급한 포맷의 데이터를 최소단위로 쪼개어 Client로 보내고 Client에서는 받는 즉시 화면에 보여주게 되므로, 데이터 크기에 상관없이 즉시 보여줄 수 있으나, Server쪽의 부하가 크고, 별도의 Video Server가 필요하기 때문에 부대 비용이 들어가는 단점이 있다. 또한 효율의 극대화를 위하여 데이터 압축 기술과 병행하여 사용하기도 한다.

2.2.3. Unicast

한 호스트에서 다른 호스트로 데이터를 전송하는 일반적인 방법은 도착점이 일정하다는 것이다. 즉, one-to-one 방식으로 데이터를 전송하고, 동일한 데이터를 10개의 다른 호스트로 전송을 하려면 10개의 복사본을 각각 전송하여야 하기 때문에 10배의 네트웍 대역폭을 차지하는데, 이 방식이 일반적인 IP Unicasting 방식이다.

2.2.4. Multicast

이것은 one-to-one 과 달리 one-to-many 방식으로, 특정한 데이터를 그룹멤버에게 전송하는 것으로, 송신자는 수신자가 누구인지 알 필요가 없으며, 멤버는 언제나 가입과 탈퇴가 자유롭다. 또한 10개의 다른 호스트로 전송을 한다고 해도 하나의 데이터만 보내면 10개의 그룹멤버가 받을 수 있으므로 네트웍 대역폭의 낭비를 줄일 수 있다.
이 경우는 각 호스트간에 터널이라는 가상의 Backbone을 설정하는데, 이것은 일반적인 경우 multicasting address를 인식하지 못하기 때문이다. 따라서 기존의 OS의 경우 특별히 커널을 패치시켜야 하는데, 최근에 업그레이드되는 OS나, 라우터등은 multicasting 기능을 내장하고 있다. MBone(4)이 그 대표적인 예이다.

3. 현재의 실시간 비디오 전송 제품, 기술

3.1. On-demand Only

3.1.1. VDOLive

http://www.vdo.net/

StreamWorks와 함께 실시간 비디오 전송의 선구적 역할을 하였으며, AVI포맷의 비디오를 encoder를 이용하여 vdo 포맷으로 압축하여 별도의 서버를 이용하여 streaming 하는 형식이다. 서버는 Windows NT부터 거의 모든 Unix 플랫폼을 지원한다.

3.1.2. InterVU

http://www.intervu.com/

MPEG 파일을 플러그인 형태로 streaming 하여 보여준다. 별도의 서버는 필요치 않으며, 아래의 Vivo의 경우와 같이 EMBED tag를 사용하여 HTML 문서안에 포함시킬 수 있다. Video, Audio 모두 MEPG-1 포맷만 지원한다.

3.1.3. VivoActive

http://www.vivo.com/


AVI포맷의 비디오를 VivoActive Producer를 사용하여 viv포맷으로 압축한 후, 별도의 서버가 필요 없이 바로 EMBED tag를 사용하여 플러그인 형태로 보여준다. Player는 이 압축된 데이터를 streaming 하는데, 별도의 서버가 필요 없기 때문에 경제적인 면에서 대단히 유리하며, 저속의 네트웍에서도 비교적 높은 bitrate과 framerate를 보여준다.

이 외에 CineWeb (by Digigami), ClearFusion (by Iterated Systems)등이 있다.

3.2. On-demand, On-the-Fly Enabled

3.2.1. StreamWorks

http://www.xingtech.com/

PC상에서는 처음으로 on-the-fly를 가능하게 한 제품으로 MPEG-1포맷의 오디오/비디오, MPEG-2포맷의 오디오, LBR (Low Bitrate)의 오디오 포맷을 지원한다. 크게 서버, Transmitter, 플레이어로 나뉘며, 생방송을 위해서는 Transmitter라는 별도의 하드웨어가 반드시 필요하다.

3.2.2. MBone

http://www.mbone.com/

IP Multicasting을 이용하여 IETF 화상회의를 목적으로 만들어졌는데, 각종 이벤트나 생중계에도 많이 사용되고 있다. 학술적인 목적으로 시작되었던 만큼, 여러곳(특히 대학)에서 관련 애플리케이션을 지속적으로 개발, 업그레이드하고 있으나, 모뎀 사용자는 이용할 수 없다는 단점이 있다.

3.2.3. Vosaic

http://www.vosaic.com/

제 4 회 국제 WWW Conference에서 발표된 Vosaic은 기존의 TCP/UDP를 이용한 비디오 데이터 전송의 한계를 극복하고자 새로이 VDP (Video Datagram Protocol)를 제정하여 이를 이용하고 있다. 아직은 베타 테스트중이며 별도의 서버가 필요하다.

이 외에 Multicasting을 지원하는 FlashWare (by Precept), NetShow (by Microsoft)등이 있다.

3.3. 비교표

구분VDOLiveInterVUVivoActive StreamWorksMBoneVosaic
개발사VDO NetInterVu Vivo SoftwareXing Tech. Vosaic
생중계여부XXXOOO
지원포맷AVIMPEG-1 AVI, MOVMPEG-1,2,LBR MPEG-1,2,LBR
서버OXX OXO
플랫폼ALLWin95/NT, MAC Win, MACALLALL ALL

4. Video Content 제작 - VivoActive를 중심으로

VivoActive는 별도의 서버가 필요없고, Tool과 Player가 무료로 배포되므로 일반 사용자도 손쉽게 비디오 컨텐트를 개발할 수 있다. 다음 순서에 따라 간단한 비디오 파일을 홈페이지에 올려보자.
  1. 우선 필요한 두개의 파일을 설치한다.


  2. 샘플로 사용할 AVI파일을 하나 준비한다.

  3. 웹 서버에 video/vivo MIME 형식을 등록한다. (확장자 viv, vivo)
  4. VivoActive Producer를 실행하여 avi 파일을 선택하고 알맞게 Tunning을 한다. 여기서 결과 파일의 크기와 화질을 감안하여, framerate, bitrate등을 조절할 수 있다.



  5. 조절이 끝나면 Generate 버튼을 눌러 인코딩을 시작한다. 참고로, 1.9Mb의 AVI파일을 인코딩 하는데 Pentium 133 + 48M RAM 환경에서 35초가 소요되며 380Kb로 인코딩 되어 5:1의 압축률을 보였다.
  6. HTML 문서에 다음과 같이 임베딩 태그를 이용하여 삽입시킨다. 

    <EMBED SRC="six.viv" AUTOSTART=TRUE WIDTH=180 HEIGHT=140>

그다음 이 페이지를 브라우징 하면 비디오를 감상할 수 있다.

5. 인터넷 방송 - MBC TV

MBC TV인터넷 생방송 시스템은 StreamWorks를 이용하여 구성되어 있다. 사용자는 Windows, Mac 혹은 X-Window용 플레이어를 설치하고, 14.4K 이상의 모뎀, 혹은 LAN으로 인터넷에 연결될 수 있으면 된다.

  1. 웹브라우저를 통해 생방송 링크를 클릭한다.
  2. 웹서버는 클라이언트에게 application/x-xdma MIME 형태의 xdm 파일을 클라이언트에게 전송하는데, 이 파일에는 StreamWorks 서버에 대한 정보를 담고 있다.
  3. 웹브라우저는 이를 이용하여 StreamWorks 플레이어를 실행시키고 xdm파일 정보를 넘겨준다.
  4. 플레이어는 넘겨받은 정보에 대하여 StreamWorks 서버에게 전송을 요청하고, 서버는 Transmitter로부터 계속 전달되어지는 비디오 데이터를 플레이어에게 스트림으로 전송하면, 플레이어는 이를 화면에 보여준다.
이와같은 구성으로 이루어져 있는데, Transmitter는 비디오나 안테나, 케이블TV 라인등을 입력으로 받아 MPEG포맷으로 인코딩하여 계속 서버에게 데이터를 전송한다.

6. 향후 전망

6.1. 가정에서의 인터넷 멀티미디어

지금까지 살펴본 여러가지 기술들은 계속적으로 성능 향상을 꽤하며 업그레이드 되고 있으며, 또한 새로운 개념의 기술들이 당분간 지속적으로 등장하리라 보지만, 그 성능은 거의 엇비슷하다. 가장 근본적으로 해결되어야 할 물리적인 네트웍의 속도는 눈에 띄게 빨라지기에는 아직 이르기 때문이며, 한정된 속도 위에서의 이러한 소프트웨어적 해결 방안은 한계가 있기 마련이기 때문이다. 가장 많이 보급된 28.8K 모뎀으로도 일반적인 음성 데이터를 받기에는, 그리 좋은 음질은 아니지만 어느정도 가능하다. 하지만, 비디오 데이터의 경우는 음성 데이터보다 그 크기가 훨씬 방대하기 때문에 가정을 겨냥한 멀티미디어 컨텐트 서비스는 막대한 frame loss나 bitrate loss를 감당할 수 밖에 없다.

하지만 ISDN을 시작으로 점차 기존의 속도 한계를 넘어서려는 움직임이 보이고 있고, 향후 가장 기대되고 있는 케이블 모뎀이 실용화 되고 널리 보급된다면, 일단 가정에서의 네트웍 속도는 해결되리라는 전망이다. 이렇게 되면 이러한 대용량의 멀티미디어 서비스가 본격적으로 가능해 지고, 보다 다양하고, 제약없는 형태로 VOD 서비스, 화상전화등이 가능해질것이다.

6.2. 인트라넷 환경에서의 가능성

각 기업체들은 점차 인터넷 전용선을 설치하는 기관이 늘어가는 추세이고, 인트라넷 환경에서의 네트웍 속도는 최소한 10Mbps 이상을 육박하기 때문에, 이러한 비디오 데이터를 전송하는데는 별다른 무리가 없기 때문에, 사내 방송이나 이벤트, 화상 회의등에 활용 분야가 매우 밝다. 또한 국제적인 Backbone 망의 속도도 T3로 고속화하고 있기 때문에 인트라넷 환경을 대상으로 한 이러한 비디오 전송은 그 영향력이 매우 크다고 할 수 있다. 여기서 한가지 간과할 수 없는것은, 앞서 이야기한 multicasting 방식의 기술이 점차로 늘어날 것이라는 점이다. 아무리 네트웍 대역폭이 넓다고 해도, 동일한 데이터를 복수개 전송하는것은 상당한 낭비이기 때문에, 일반적인 데이터에 앞서 이러한 대용량의 멀티미디어 데이터 전송은 muticasting 방식으로 자연히 발전 할 것이다.

각주 (Footnotes)

(1)
VRML (Virtual Reality Modelling Language) - http://vag.vrml.org/www-vrml/
(2)
Java (by Sun Microsystems, Inc.) - http://www.javasoft.com/
(3)
ActiveX (by Microsoft Corp.) - http://www.microsoft.com/
(4)
MBone (Multicast Back Bone) - http://www.mbone.com/
Last-Modified : Tuesday, 09-Dec-2014 17:26:19 UTC