컴퓨터공학부 2000-30294 권진백
2 구현 모델
2.1 기능 정의
LSS가 제공하는 기능은 다음과 같다.
2.1 스트리밍(Streaming)
스트리밍은 인터넷과 같은 네트웍을 통해 서버에서 클라이언트로 비디오 또는 오디오를 전송하는 것을 의미한다. 서버는 비디오를 네트웍으로 보낼 수 있도록 패킷으로 쪼갠다. 클라이언트는 그 패킷들을 다시 모아서 원래 형태로 만든 후 재생된다. 이 때, 재생과 패킷 수신은 동시에 일어난다. 여기서 연관된 일련의 패킷들을 스트림(stream)이라고 한다.
스트리밍은 클라이언트가 비디오 데이터를 받으면서 재생한다는 점에서, 전체 비디오를 받은 후 재생하는 단순한 파일 전송과 구별된다. 사실, 스트리밍 클라이언트 패킷을 받으면서 재생을 하고, 재생된 데이터는 버린다. 파일을 스트리밍하는 데 다음과 같은 프로토콜을 사용할 수 있다.
유니캐스트(Unicast) 스트리밍
유니캐스트에서는 클라이언트가 RTSP(Real Time Streaming Protocol을
사용해 비디오에 대한 요청(request)을 서버에 알린다. 서버는 그 비디오에 대한
정보를 담고 있는 스트리밍 세션(streaming session)으로 클라이언트에
응답한다. 하나의 스트리밍 세션은 비디오 스트림과 오디오 스트림과 같은 한 개
이상의 스트림으로 구성된다. 서버는 클라이언트에게 필요한 스트림의 개수와
각 스트림의 정보(예, 미디어 타입, 코덱 등)를 알려준다. 그리고 나서 실제
스트림들이 RTP를 통해 클라이언트로 전송된다.
|
|
| 그림 1. RTSP와 RTP를 이용한 유니캐스트 |
RTSP는 TCP/IP를 사용하고, RTP는 저수준의 UDP/IP를 사용한다.
2.3 구성 요소
2.4 개발 방법
3.1 Real Time Streaming Protocol (RTSP)
RTSP는 오디오나 비디오 같은 연속형 미디어의 시간에 동기화된 스트림들을
설정하고 제어하는 역할을 한다. 하지만, RTSP가 연속형 미디어 자체를 전달하지는
않는다. 즉, RTSP는 멀티미디어 서버의 리모트 컨트롤이다.
하나의 RTSP 세션동안, 서버로 RTSP 요청을 보내기 위해 여러개의 TCP(또는
UDP) 연결을 열고 닫을 수 있다.
RTSP에 의해 제어되는 미디어 스트림은 RTP일 수 있지만, RTSP는 미디어 스트림을
위한 트랜스포트 메카니즘에 의존하지 않는다. 이 프로토콜은 HTTP/1.1과 매우
흡사하다. 따라서, HTTP의 확장이 대부분의 경우에 RTSP에도 추가될 수 있다.
RTSP에서 제공하는 메소드(method)는 아래와 같다.
| OPTIONS | 사용가능한 메소드를 얻는다. |
| SETUP | 트랜스포트 연결을 설정한다. |
| ANNOUNCE | 미디어 개체의 설명(description)을 변경한다. |
| DESCRIBE | 미디어 개체의 설명을 얻는다. |
| PLAY | 재생을 시작한다. |
| REDIRECT | 클라이언트를 새로운 서버로 리다이렉트(redirect) |
| PAUSE | 스트림 전송을 중단한다(상태는 유지). |
| SET_PARAMETER | 장치 또는 인코딩을 제어한다. |
| TEARDOWN | 세션 상태를 지운다. |
| ... |
그림 2는 위의 메소드를 이용한 RTSP의 기본적인 동작 과정을 보여준다.
 |
| 그림 2. RTSP의 동작과정 |
그림에서, 클라이언트는 먼저 OPTIONS 메소드를 사용해서 서버에서 제공하는 메소드들을 얻고, DESCRIBE 메소드를 사용해 서버에게 요청할 미디어 개체의 설명(description)을 얻는다. 그리고 나서, SETUP 메소드를 사용해 미디어 스트림 전송을 위한 트랜스포트 연결을 설정하고, PLAY 메소드를 보내고 응답을 답은 후 RTP 채널을 통해 스트림을 받아서 재생한다. RTSP 세션을 끝낼 때는 PAUSE 메소드를 사용해 스트림 전송을 중단시킨 후, TEARDOWN 메소드로 세션을 완전히 없앤다.
3.2 Real-Time Protocol (RTP)
RTP는 실시간 특성을 갖는 데이터의 "end-to-end" 전송 서비스(대화형 오디오와 비디오)를 제공한다. 이런 서비스는 "payload type identification", "sequence numbering", "timestamping"과 "delivery monitoring"을 포함한다. 어플리케이션들은 보통 UDP 위에서 RTP를 사용함으로써 다중화와 체크썸(checksum) 서비스를 이용한다. 하지만, RTP는 다른 네트웍 이나 트랜스포트 프로토콜 위에서도 사용될 수 있다. RTP는 하부의 네트웍에서 제공한하면, 멀티캐스트 기능을 이용해서 여러개의 클라이언트로의 데이터 전송을 지원한다.
RTP는 잘 알려진 HTTP와 FTP의 파일 전송 프로토콜과 비슷하지만, 실시간 스트림에 적합하게 설계되었다. RTP는, HTTP와 FTP와 달리, 클라이언트로 미디어 개체 전체를 다운로드하지 않는다. 대신, 단방향 데이터 스트림을 재생 데이터율로 실시간으로 전송한다. 연결이 데이터 스트림을 감당할 정도로 출분한 대역폭을 가지고 있는 한, 그 미디어는 정상적으로 재생된다. 그 데이터는 재생된 후에 지워진다. 시청자가 다시 그 미디어를 재생하기 위해서는 스트리밍 서버에 다시 요청해야 한다.
3.3 WAVE 파일 포맷
WAVE 파일 포맷은 Microsoft의 RIFF 스펙의 정의된 파일 포맷이다.
RIFF 스펙은 멀티미디어 파일을 위한 스펙으로서 다른 종류의 데이터를 포함할 수
있다.
RIFF는 많은 종류의 데이터(특히, 오디오와 비디오 같은 멀티미디어 데이터)를
저장하기 위한 파일 포맷이다. 그것은 청크(chunks)와
서버-채널(sub-channel)에 기반을 둔다. 파일에서 청크 타입과 청크 크기가
먼저 나오고, 그 다음 실제 청크 내용이 나온다. RIFF 파일 전체가 모든 다른
청크를 담고 있는 거다란 청크이다. RIFF 청크의 컨텐츠에서 가장 먼저 나오는 것이
"폼 타입(form type)"이다. 이 것이 파일 내용의 전체 타입을 표현한다. 따라서,
RIFF 파일의 구조는 아래와 같다.
Offset Contents
(hex)
0000 'R', 'I', 'F', 'F'
0004 Length of the entire file - 8 (32-bit unsigned integer)
0008 form type (4 characters)
000B first chunk type (4 character)
0010 first chunk length (32-bit unsigned integer)
0014 first chunk's data
... ...
바이트들의 저장 순서는 "Little-Endian"이다.
WAVE 포맷은 디지털 오디오를 저장하는 RIFF의 부분집합이다. 그것의 폼 타입은 "WAVE"이고, 다음 두 종류의 청크가 필요하다.
Offset Length Contents 0 4 bytes 'RIFF' 4 4 bytes8 4 bytes 'WAVE' 12 4 bytes 'fmt ' 16 4 bytes 0x00000010 // Length of the fmt data (16 bytes) 20 2 bytes 0x0001 // Format tag: 1 = PCM 22 2 bytes <channels> // Channels: 1 = mono, 2 = stereo 24 4 bytes <sample rate> // Samples per second: e.g., 44100 28 4 bytes <bytes/second> // sample rate * block align 32 2 bytes <block align> // channels * bits/sample / 8 34 2 bytes <bits/sample> // 8 or 16 36 4 bytes 'data' 40 4 bytes <length of the data block> 44 bytes <sample data>
4.1 LSSP 서버 구조
RTSP에 따라 동작하는 서버 부분이다. 처음에 TCP 포트를 "listen"하고 있다가
클라이언트의 접속 요청이 있으면 "이벤트 루프(event loop)"로 들어간다(그림 3).
테스트 버전으로서, 현재는 한 개의 클라이언트만 지원하도록 구현되었다.
여러 클라이언트를 지원하도록 하는 것은 프로세스나 스레드를 사용해서 쉽게
구현될 수 있다.
 |
| 그림 3. RTSP 서버의 이벤트 루프 |
이벤트 루프에서는 클라이언트에서 오는 RTSP 메시지를 받고 처리하고 응답하는 기능이 구현되어 있다. 추가로, 이벤트 루프에서 RTP 세션 스케쥴러를 시작시킨다. 아래는 이벤트 루프의 주요 기능이다.
그림 4는 LSSP 서버의 전체 구조이다.
 |
| 그림 4. LSSP 서버 전체 구조 |
RTSP 메시지 핸들러(Message Handler)는 RTSP 메시지를 파싱하고 그 결과에 의해 세션 관리자를 제어하고, 처리 후 응답을 보내는 역할을 한다. RTSP 세션 관리자(Session Manager)는 세션들을 관리하고 각 세션에 해당하는 스트림을 생성하고 초기화한다. RTSP 메시지에 따라 각 세션을 제어한다. RTP 스트리머(Streamer)는 미디어 데이터를 파일에서 읽어 RTP패킷들을 만들어 스케쥴러에게 전달한다. 스케쥴러(Scheduler)는 스트리밍을 스케쥴해서 RTP 패킷으로 만들어 UDP 포트로 보내는 기능을한다.
4.1 RTSP 메시지 핸들러(Message Hander)
서버는 클라이언트가 처음 접속하면 INIT 상태에 있게 된다. 그 다음 SETUP 메소드
요청을 받으면 READY 상태로 전이하고, PLAY 메소드 요청을 받으면 PLAY 상태로
전이하고 TEARDOWN 메소드 요청이 오면 다시 INIT 상태로 가게 된다.
 |
| 그림 5. RTSP 서버의 상태 전이 |
4.2 RTSP 세션 관리자(Session Manager)
클라이언트로 부터 SETUP 메소드 요청을 받게되면 세션을 생성, 초기화하고 그 세션을 서버의 세션 리스트에 추가한다. 각 세션은 세션 ID와 현재 상태(그림 5), WAV 파일의 URL 등의 정보를 유지한다. 또한 URL로 부터 RTP 스트림을 초기화하고 스트림에 대한 정보를 가진다. 세션이 유지하는 RTP 스트림과 관련된 정보는 데이터 포트번호, 데이터율, 시간 정보등을 갖는다. 스트림의 모든 상세한 정보는 RTP 스트림에서 가지고 있다.
이 세션은 계속해서 스트림의 상태 관찰하고 RTSP 메소드 요청 이벤트로부터 서버의 상태를 전이시킨다. 그 결과에 따라 스트림을 제어한다. READY 상태에서 PLAY 메소드 요청을 받으면, 드디어 스트림의 전송을 시작한다.
4.3 스트리머(Streamer)
PLAY 메소드 요청을 받게 되면 해당되는 세션은 그 것의 스트림을 시작시킨다. 스트림은 이미 알려진 클라이언트의 RTP 포트번호로 UDP 연결을 설정하고, WAV 파일을 열고, RTP 패킷를 위해 필요한 정보(SSRC,전송률,일련번호,패킷크기)를 결정한다. 그리고 나서 실제 전송을 위해 스케쥴 리스트에 그 스트림을 등록한다. (나중에 스케쥴러에 의해 실제 전송이 행해진다.) PAUSE의 경우에는 스케쥴 리스트에서 스트림이 제거함으로써, 스케쥴러는 그 스트림을 더 이상 스케쥴하지 않게 된다.
4.4 스케쥴러(Scheduler)
스케쥴러는 이벤트 루프에서 매번 호출된다. 활성화되면, 스케쥴러는 스케쥴 리스트에 있는 스트림들을 전송하기 위해 그 스트림에 해당되는 스트림 이벤트(stream_event())를 호출한다. 스트림 이벤트는 스트림의 WAV 파일을 패킷 크기 만큼 읽어서 RTP 패킷을 만들어(build_RTP_packet()) UDP 포트로 보내는 기능을 한다. RTP를 위한 정보는 세션 관리자에 의해 이미 스트림이 가지고 있다.
4.4 RTSP 클라이언트
클라이언트 역시 리눅스용으로 구현하였고, 텍스트 기반 인터페이스를 갖는다. 명령어 클라이언트 어플리케이션에서 제공되는 명령어와 그에 해당되는 RTSP METHOD는 다음과 같다.
현재 메시지 핸들러와 세션 관리자 구현이 끝난 상태이고, 테스트를 위해 클라이언트을 구현해서 간단하게 RTSP가 정상 작동하는 지를 테스트할 예정이다. 그 다음 나머지 부분들, 스트리머, 스케쥴러의 구현을 끝낼 예정이다.