달력

22020  이전 다음

  •  
  •  
  •  
  •  
  •  
  •  
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29

스트리밍 프로토콜의 기본적인 개념 및 종류에 대해 알아보았고, 

대표적으로 RTSP, HTTP, HLS등이 있는데, 그 중 RTSP에 대해 알아보도록 하겠음.


RTSP란 Real-Time Streaming Protocol로써

사용자가 미디어의 재생, 중지, skip, 되감기등의 기능을 이용하여 미디어를 재생하고자 할때, 

즉, DVD나 CD를 조작하는 것 처럼, 사용자가 재생을 제어할 수 있도록 하기 위한 것.
이때 client와 server는 제어 정보를 교환하는 프로토콜이 필요한데 이것이 바로 RTSP이다.


그 대략적인 내용은 다음과 같다.

 - Real Networks사와 Netscape Communication사가 공동개발하였고, 

 - IETF가 1998년에 표준화함.(현재 v.2.0 마무리단계) RFC2326에 규정

 - Streaming data를 제어하기 위한 방법을 제공

 - Audio, Video등의 멀티미디어 데이터를 포함하는 미디어 서버를 원격 조작하기 위한 프로토콜

 - 명령어는 PLAY, PAUSE등과 같이 VCR동작과 유사하며 시간 정보를 바탕으로 서버에 접근

 - 실제 미디어 정보를 전송하지는 않으며 미디어 전송관련해서는 RTP 프로토콜(Transport Layer)을 사용

 - HTTP 프로토콜과 문법이나 동작이 비슷함.

 - HTTP는 stateless, RTSP는 stateful (무상태형과 상태형 프로토콜)

 - Presentation layer의 protocol임.

 - 일반적으로 RTP/RTCP와 함께 쓰임. (Realtime Transport Protocol/Real Time Control Protocol) 



'Work' 카테고리의 다른 글

RTSP(Real-Time Streaming Protocol)  (1) 2014.03.19
Streaming Protocol  (0) 2014.03.19
Posted by smoothoperator

댓글을 달아 주세요

  1. 예예~  댓글주소 수정/삭제 댓글쓰기 2014.11.19 00:12 신고

    앗.... 왠지 너무 어려운...ㅎㅎ
    저도 좀 배워야겠습니다.^^

Streaming Protocol

Work 2014. 3. 19. 16:28

What is Streaming


is multimedia that is constantly received by and presented to an end-user while being delivered by a provider.(from wiki)

즉, 미디어 스트리밍이라 함은, 사용자가 어떤 미디어를 감상하기 위해서,

해당 미디어 파일을 서버로부터 다운로드 완료한 후에 감상하던 기존 방식과 달리,

미디어를 완전히 다 전송 받지 않았음에도 불구하고 전송중에 재생할 수 있는 것을 말한다.


스트리밍을 언급하기 전에 먼저 미디어를 전송하는 방식에 대해 간단히 정리해 보자면, 크게 세가지 방식으로 구분해 볼 수 있겠다.

- Download 방식

- Progressive Download 방식

- Streaming 방식

Streaming protocol이 제안되기 전에는 사용자가 서버로부터 미디어를 받아 재생할 수 있는 방법은 

Download방식이었다. 

즉, 해당 동영상을 서버로부터 사용자의 저장매체에 다운로드하여 이를 재생시키는 일반적인 방법.


Progressive Download 방식은 streaming 방식의 전단계로 이해하면 될 것 같다.

즉, 미디어를 온전히 download받기 전에, 파일의 일부가 도착하는 대로 재생하는 방법. 

typically using the HTTP protocol.

network의 전송상태에 따라 adaptable하지 못하고, skip 등의 동작이 안됨.

(이를 보완한 것이 HTTP pseudo-streaming)

또한 미디어 서버가 아닌 웹서버에 미디어를 올려놓고 URL주소를 client의 player에 링크만 걸면 되므로 

가장 쉽고 비용 절감적인 측면이 있다.

현재 Live가 아닌 VoD Service 시장에서 가장 광범위하게 사용됨.

전 세계 비디오 트래픽의 약 55%가 이 방식으로 사용됨.(2011년 자료 기준)

YouTube, ESPN, CNN등이 이에 해당.


Streaming 은 사용자의 측면에서 봤을때, progressive download방식과 특별한 차이를 느끼지 못한다.

즉, 미디어를 채 다 다운로드 받기 전에 사용자는 해당 미디어를 재생하여 감상할 수 있다.

다만, 서버측과 보다 interactive하게 동작하여, network환경에 보다 adaptive하게 동작한다던지 보다 효율적으로 데이타 전송을 처리하는 장점이 있다.

이와 관련된 protocol로는 다음의 것들이 있음.

 - RTSP, 

 - MMS(Multimedia Messaging Service/Microsoft Media Server), 

 - HLS(HTTP Live Streaming), 

 - Microsoft's Smooth Streaming, 

 - Adobe's HDS


Streaming을 몇가지 방식으로 구분해 보자면..

기술적으로는 UnicastMulticast방식으로 구분하고, 

그 방식에 따라서는  VoD type과 Live type으로 구분할 수 있다.

기술적인 구분을 잠깐만 언급하고 가자면, Unicast는 정보를 하나의 IP에 보내는 방식이며, Multicast는 정해진 그룹에게 동시에 컨텐츠를 보내는 것이다. (Broadcast와 구분할것.)

VoD 방식과 Live방식. 

인터넷에 여러가지 정의들이 이것 저것 많아 혼란을 주는데, 가장 명확한 구분은, 

VoD방식은 Encoding이 완료되어 '저장된' 미디어 정보를 전송하는 것이고, Live방식은 정보를 실시간으로 encoding하여 client측에 보낸다는 것이 가장 심플하고 정확한 구분인 것 같다.

즉, 그 이름(naming)에서 힌트를 얻어 이해하는 것이 가장 심플함.


Why?

그렇다면 이러한 Streaming protocol이 나오게 된 배경에 대해 알아보자.

실시간 전송 환경은 높은 대역의 대역폭을 필요로 하며, 데이터 전송의 완전 무결성 보다는, 

그 실시간성에 보다 더 초점이 맞춰져 있다.

데이터(글자나 cmd)가 전송중 오류로 인해 생기는 문제, 그 영향은 매우 크지만, 

재생중인 비디오/오디오 데이타의 몇 픽셀의 색상오류 혹은 음성중 잠깐의 노이즈는 

그다지 문제 될 것이 없기 때문이다.

따라서 기존의 데이터를 위한 (파일전송 등) 프로토콜은 streaming 데이터를 전송하기 위한 프로토콜로는 적합하지 않음.

 

HTTP/FTP 프로토콜의 문제점 for Streaming

HTTP/FTP등의 일반적인 연결지향형 프로토콜은 일반적인 인터넷 프로토콜로써 송신 및 수신시에 

전송 데이터의 확고한 안정성 보장에 중점을 둔 프로토콜임.

따라서 속도에 중점을 두어 설계된 프로토콜이 아니다.

즉, HTTP/FTP등은 전송되는 목적지에 전송하는 모든 데이터 패킷의 완전한 전송을 보장한다.

이러한 프로토콜은 TCP Layer를 사용하는데, 멀티미디어 전송의 관점에서 TCP전송은 3가지 주요 단점을 가진다.

 1. Processing overhead

 2. Network transmission delay

 3. Lack of multimedia functionalities

위와 같은 단점으로 인해 화상회의, 인터넷 broadcasting, multicasting과 같은 실시간 전송 프로토콜은 UDP Layer에서 설계됨.

UDP전송은 전송을 보장하거나 수신을 위한 데이터의 안정성을 보장하는 프로토콜이 아님.

TCP와는 달리 UDP는 연결에 대한 정보를 갖지 않음.

예를 들어 서버측에서 데이터 패킷을 client에 전송한다고 하더라도, 이렇게 전송되는 패킷이 실제로 client에 안전하게 전송되었는지에 대해 확신할 수 없음.

실제로, 데이터 전송의 손실에 대한 복구는 수신단의 부담으로 남겨두고, 

네트워크 오버헤드나 application구동에 대한 적은 제약 때문에 실시간 멀티미디어 전송에는 UDP가 많이 이용됨.

HTTP나 FTP는 TCP기반의 프로토콜로써, 안정적인 데이터 전송과, low bandwidth, high network err환경에 적합한 프로토콜임.

만약 수신단에서 받은 데이터에 err가 발생했을 경우, 송신측에 이를 재요청하여 데이터의 재전송/재수신이 이루어지게 된다.

그러나 이런한 데이터 전송에 대한 무손실 보장은 결국 네트워크에 대한 오버헤드로 작용하게 됨.

이와 같은 이유로 스트리밍 데이터의 전송에서는 TCP를 이용한 기존의 프로토콜보다는,

멀티미디어 전송에 적합한 UDP를 기반으로 하는 프로토콜을 이용하게 됨.


Protocols

이 부분에 대한 내용은 여기에 아주 잘 정리되어 있음 

(http://www.garymcgath.com/streamingprotocols.html)

(http://www.wonsuk73.com/15)

아래 내용이 나오겠지만, 기존에는 스트리밍 서버를 이용한 RTP/RTSP 프로토콜이 주류를 이루었으나, 

몇가지 단점으로 인해 무료인 HTTP기반으로 옮겨가는 추세이다.

MS의 'Smooth Streaming', Apple의 'HTTP Live Streaming', Adobe의 'HTTP Dynamic Streaming'이 그 예.

이와 관련된 표준화 기구들의 활동들이 다음과 같다.

 - 3GPP: Adaptive HTTP Streaming(AHS)

 - IETF: HTTP Live Streaming

 - MPEG: Adaptive Bitrate Streaming 


Protocol stack

스트리밍과 관련한 프로토콜은 OSI reference model의 몇가지 다른 layer에 걸쳐있다.

Transport layer, 

Session layer,

Presentation layer, 

Application layer, 


RTP Family

RTP(Real-time Transport Protocol)는 꽤 오래되고 종종 쓰이는 스트리밍 방식이다.

IETF RFC 3550에 정의되어 있음.

실시간 전송을 주 목적으로 하므로, UDP 통신을 기반으로 함. 물론 TCP를 사용하는 것도 가능하나, it's unusual.

layer상으로는 UDP(혹은 TCP)의 상위단이긴 하지만, transport layer로 간주됨.

Sesseion layer의 RTCP(Realtime Control Protocol)와 같이 쓰인다.

RTCP의 주 목적은 데이터 전송 quality에 대한 feedback을 받고, data rate 을 조절하는 등의 역할을 함.


다른 몇가지 프로토콜도 RTP와 일반적으로 같이 쓰이는데, 

RTSP(Real Time Streaming Protocol)가 바로 그것. defined by IETF RFC 2326.

RTSP는 Presentation layer protocol이며 흔히 'Network remote control'이라 불림.

어떤 면에서 HTTP와 유사하며, playing, pausing, recording같은 미디어 플레이에 관련된 request를 전달.

간혹, RTP, RTCP, RTSP 이 stack을 통채로 RTSP라 부르기도 함.

기존의 대부분의 웹 비디오 서비스는 스트리밍 서버를 기반으로 하는 바로 이 RTSP 프로토콜 기반이었으나,

최근 추세는 HTTP기반으로 옮겨가려는 시도들이 주요 IT업체를 중심으로 이루어지고 있음.

스트리밍 서버는 고가인 반면, HTTP 서버는 무료인데다 방화벽 문제가 없기 때문임.


RTP, RTCP, RTSP는 모두 서로 다른 port로 동작하며 보통 RTP port가 N이면, RTCP는 N+1.

RTSP는 544사용.

RTP session은 수신단에서 합쳐지는 multiple stream이 포함될 수 있다.

예를 들면, 오디오와 비디오가 서로 다른 채널로 동시에 전송되는 것 처럼.


UDP URL은 웹브라우저에서 지원되는 경우가 많지 않다.

따라서 브라우저상에서 RTP/UDP stream을 보려면 별도의 plug-in이 필요한 경우가 많음. 예를 들면 Flash.

브라우저가 아닌 stand alone player들도 많이 있는데, 

대표적으로 RealPlayer, Windows Media Player, QuickTime Player. 가 있음.

Android, iOS device들은 기본적으로 RTP-compatible한 player를 가지고 있지 않음.

RealPlayer(Android)같은 3rd party app을 설치해야만 함.


RTMP

Real Time Messaging Protocol.

Flash에서 주로 사용하던 독점적인 프로토콜이었으나, Adobe가 spec을 공개하여 이제 다른 sw에서도 쓰임.

requirement는 아니지만 보통 TCP 방식으로 통신하고, 어플리케이션 상에서는 session layer에서 동작함.

Flash의 몰락과 함께 이 RTMP도 함께 기울것으로 보여짐.

Jobs가 엄청 싫어한 이 Flash는 Apple의 모든 제품에 쓰이지 않으며, 

따라서, RTMP stream역시 쓰이지 않음. 3rd party app중에는 지원하는 것이 있기도 함.


원래 RTMP는 방화벽 환경에서는 사용할 수 없었으나, 이를 위해 RTMPT(RTMP through HTTP)가 등장.

또한 이 외에도 encryption등을 지원할 수 있게 다음의 몇가지 프로토콜들이 파생됨.

RTMPE, RTMPTE, RTMPS


HTTP Live Streaming

New trend in streaming society.

streaming계의 떠오르는 샛별 정도라 할 수 있는게 바로 이 HLS.

Apple의 주도로 개발되고 iOS에 널리 쓰임. 

(Apple이 개발했다하여 Cupertino streaming이라고도 함.)


Live Streaming하면 RTSP가 전통적으로 유명했으나, 

RTSP는 도입비용이 높고, 방화벽 환경에서 서비스가 원활하게 이루어지지 않는다는 단점이 있음.

반면 HTTP는 쉽고 간단하며, 방화벽 환경에서도 서비스에 문제가 없으니(보안도 중요하고)

이를 통해 원활한 스트리밍을 해보자는 노력중에 하나가 바로 이 Apple의 HLS.


streaming을 위해 adaptive bit rate을 지원하는 HTTP를 사용한다는 것이 주요 내용.

하지만 (위에서 언급한 바 있지만)

TCP/IP를 기반으로하는 이 HTTP는 사실 실시간 미디어 스트리밍으로는 이론상 적합하지 않음.

하지만 최근 high speed 인터넷이 널리 보급되다 보니, 

TCP/IP base로, 데이터 무손실을 위해 주고 받는 ack같은 것들이 그다지 신경쓸게 되지 못함.


여기에 각 브라우저 별 HLS지원 여부를 확인할 수 있도록 해둠.(http://www.jwplayer.com/html5/hls/)


TCP 환경에서 정상적으로 스트리밍을 하기 위해 영상을 잘게 쪼개서 보내는데, 

이 쪼개진 영상들에 대한 정보를 playlist라는 것에 담는다.

이 HLS에서 허용하는 playlist format은 M3U 형식(.m3u or .m3u8)


Adobe HTTP Dynamic Streaming

Adobe에서 개발.

HLS와 마찬가지로 HTTP상에서 동작하며, RTMP와 마찬가지로 Flash와 연동됨.

재생하려면 Flash가 있어야 된다고 스펙에 명시되어 있으며, 따라서, 주로 desktop 환경용으로 쓰임.


Microsoft Smooth Streaming

MS에서 개발한 것으로 주로 Silverlight와 함께 쓰임.


Dynamic Streaming over HTTP

Shoutcast

BitTorrent Live Streaming


HTML5

HTML5에서는 추가 plug-in 없이 자바스크립트로 비디오와 오디오에 대한 재생이 가능하도록 한다.

즉, Flash, Silverlight, ActiveX같은 plug-in이 없어도 브라우저 자체에서 자바스크립트를 이용하여 재생, 일시정지등의 컨트롤이 가능하게 됨. (http://unikys.tistory.com/278)


이 부분이 잘 이해가 안감.

즉, 서버측이 미디어 서버든 웹서버든, RTSP/RTP 프로토콜을 지원하든 HLS 프로토콜을 지원하든 상관없이

client의 브라우저가 HTML5 표준을 만족하고 지원하면 자바스크립트의 video/audio tag를 이용해서 

재생이 가능하다는 거야 뭐야.


그리고 위 링크된 블로그에 보면 맨 마지막에

'아무런 추가 프로그램 설치 없이 브라우저만으로 영상통화를 한다',  

'자바스크립트의 'video' tag만을 이용해 스트리밍을 한다.'라고 하는데..

영상통화를 한다는것은 Live streaming을 한다는 얘기고 

그렇다면 streaming protocol을 사용한다는 얘긴데..

HTML5 표준 자체에서 정하는 스트리밍 프로토콜이 따로 있다는 건가?


대략 2010년까지는 아래와 같고, 

"The HTML5 standard itself does not address video streaming protocols, but a number of vendors and organizations are working to improve the experience of delivering video over HTTP."


2012년 경에, HTML5기반의 비디오 스트리밍은 HTTP를 이용한다고 나온다.

(http://lists.w3.org/Archives/Public/public-html-ig-ko/2012May/0032.html)

즉, 위에서 살펴본 HTTP 기반의 다양한 streaming protocol들이 HTML5 표준에 적용된듯.

아님 대표 하나가 정해져서 적용되나?

HTTP를 이용한다는 것의 의미는, 

Progressive download를 한다는 것이며

웹서버를 통한 download를 한다는 것이며, 

RTP family등이 사용하는 미디어서버를 사용하는 방식이 아니라는 뜻이다.

HLS, HDS등의 주소는 video tag에 넣을 수 있지만, 

rtmp, rtsp등의 주소는 video tag에 넣을 수 없다고 함. 이게 지원되면 이건 HTML5표준이 아니란다.


현재 streaming에 사용되는 server/client들은 다음과 같은 것들로 다양함.

(출처: http://linuxism.tistory.com/1267)


Streaming Server

* Adobe Flash Media Server

* crtmpserver

* Erlyvideo

* Flazr - Java 구현

* FreeSWITCH RTMP media streaming

* haXeVideo - 프로그래밍 언어 haXe 로 작성된 다중 스레드 FLV 스트리밍 서버

* Helix Universal Server

 - 리얼 네트웍스가 판매하고 RealServer의 후계 기종

 - 전송 매체 종류 Real Media, Windows Media, Quick Time

 - 지원 OS로는 Windows, Linux , FreeBSD , Solaris , HP-UX 등

* Netris iStream Video Server

* OneTeam Media Server

* Onlinelib VCS Video Communication Server (iPhone 지원을 포함)

* QuickTime Streaming Server

 - 애플이 개발한 스트리밍 서버로 오픈 소스 Darwin Streaming Server를 기반

* Unreal Media Server

* WebORB Integration Server

* Windows Media Service

 - 마이크로소프트가 제공하는 플랫폼으로 

   Windows NT Server 4.0, Windows 2000 Server => Windows Media Server 4.1 

   Windows Server 2003 => Windows Media Server 9가 사용 되고 있다.

   컨텐츠 개발 인코더 등도 무료로 배포되고 있다.

* Wowza Media Server

 - Wowza Media Systems가 개발하고 있는 동영상 스트리밍 서버 .

 - RTMP를 사용하여 Adobe Flash Player와 통신할 수 있지만 클라이언트 서버 간의 원격 프로시저 호출도 지원


Open source

* Darwin Streaming Server

 - 애플의 소스 공개 정책에 따라 윈도우즈와 매킨토시 양쪽을 모두 지원

 - 소스까지 공개되어 있기 때문에 누구든지 무료로 설치 가능

 - 동영상, MP3 등의 디지털미디어를 실시간으로 배포하고 라이브 이벤트를 실현시킬 수 있으며, 

    Linux, Solaris, Windows NT/2000 등 가장 대중적인 엔터프라이즈급 플랫폼을 지원

* FFmpeg

 - FFmpeg은 명령어를 직접 입력하는 방식으로 동작

 - 여러가지 자유 소프트웨어와 오픈 소스 라이브러리로 구성되어 있다.

 - 라이브러리 중에는 libavcodec도 들어있으며 또, libavformat 라는 음성/영상 다중화, 역다중화 라이브러리도 있다.

 - 이 프로젝트의 이름은 MPEG 영상 표준화 그룹에서 유래했고, "mpeg" 앞에 붙은 "FF"는 "fast forward"를 의미한다.

 - 2011년 3월 13일에 FFmpeg의 개발은 개발 체제의 충돌로 ffmpeg.org와 libav.org로 분열했다.

* Red5 Media Server

 - flash player 스트리밍이 가능하도록 하는 Open Source Flash Server

 - Java 로 작성된 오픈 소스 서버

* SHOUTcast

 - Winamp의 개발, 배포 알려져 있는 Nullsoft가 무상으로 제공

 - Winamp와 SHOUTcast 서버의 조합으로 라이브 전송 가능

* VideoLAN Server


Streaming Client

* GStreamer

* Media Player Classic

* MPEG4IP

* MPlayer

* QuickTime

* RealPlayer

* Skype

* VLC media player

 - VLC 미디어 플레이어 (VLC media player, Video LAN Client)은 크로스 플랫폼 에서 동작하는 미디어 플레이어  - 많은 미디어 파일에 대한 코덱이 내장. 동영상 파일이나 음성 파일 등 많은 미디어 파일을 재생 표시할 수 있다. 

 - GPL 하에 있는 무료 소프트웨어 이다

* Winamp

* Windows Media Player

* Xine

* MythTV via Freebox


---

reference:

1. http://www.ktword.co.kr/abbr_view.php?id=49&m_temp1=1381&nav=1 

2. http://www.dreamy.pe.kr/zbxe/CodeClip/158284

3. http://blog.naver.com/PostView.nhn?blogId=osw9987&logNo=130131033548&parentCategoryNo=&categoryNo=&viewDate=&isShowPopularPosts=false&from=postView

4. http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-39

5. http://blog.naver.com/PostView.nhn?blogId=tltlzhf&logNo=150170980067

6. http://linuxism.tistory.com/1267

7. http://darkit.egloos.com/206272

8. http://blog.secmem.org/137

9. http://helloworld.naver.com/helloworld/7122

10. http://www.wonsuk73.com/15

'Work' 카테고리의 다른 글

RTSP(Real-Time Streaming Protocol)  (1) 2014.03.19
Streaming Protocol  (0) 2014.03.19
Posted by smoothoperator

댓글을 달아 주세요

기록

ordinaryDay 2014. 3. 16. 21:39

기록.


유행하는 SNS들이 많으나, 

포스팅하는 즉시, 만천하에 공개되고, 

불과 얼마지나지 않아 timeline에서 사라져 버리는..


그런 것들 말고, 

예전의 싸이월드처럼.

누군가의 소식이 궁금하면 

그곳에 찾아가는 수고를 하고, 그래서

한페이지 한페이지 넘겨가며 읽는 수고스러움을 마다 않는

뭔가 그런것이 

갑자기 그리웠다.


꽤 오랜만에 예전 싸이월드에 들어가

그때 꽤 오랫동안 소복히 적어둔 일기들을 보고

옛 생각에 잠겼다.


다시 그곳에 일기를 적어볼까..

하고 잠깐 생각해 보았다.


'ordinaryDay' 카테고리의 다른 글

기록  (0) 2014.03.16
맥북에어를 들이다.  (0) 2014.03.16
미국출장 1  (0) 2013.07.15
호수공원의 밤  (0) 2013.05.06
주일 두시 예배  (0) 2013.05.05
퇴근 길  (0) 2013.05.02
Posted by smoothoperator

댓글을 달아 주세요