Transcript ch7-2
7장 목차
7.1 멀티미디어 네트워킹 응용
7.2 스트리밍 저장 오디오 및
비디오
7.3 최선형 서비스를 최대로
활용하기
7.4 실시간 대화형 서비스
7.5 다양한 서비스
클래스 제공
7.6 QoS 보장
7-1
스트리밍 멀티미디어 서비스를 위한 접근
응용 계층에서의 지원 방법:
client에서 buffering
encoding
압축
Media Player
지연 변이(jitter) 제거
압축 풀기(decompression)
에러 숨기기
대화식 제어를 위한 GUI
7-2
인터넷 멀티미디어: 단순한 방법
오디오/비디오는 서버에 저장
파일은 HTTP object로서 전송
client는 이것을 전부 받아서
media player에 넘겨줌
audio/video는 스트림이 아님:
play할 때까지 긴 시간이 걸림
7-3
인터넷 멀티미디어: 스트리밍 접근
browser는 HTTP GET으로 metafile을 받음
Metafile은 audio/video 파일의 URL과 content type 정보를 갖고
있다.
browser는 media player를 시작하고, metafile을 넘겨줌
media player는 웹 서버에 연결
서버는 audio/video를 player에 스트림으로 전송한다.
7-4
스트리밍 서버로 부터 스트리밍
스트리밍 서버와 media player는 HTTP가 아닌 프로토콜 사용
단계(3)에서 UDP 혹은 TCP를 사용
7-5
스트리밍 멀티미디어: client buffering
variable
network
delay
client video
reception
constant bit
rate video
playout at client
buffered
video
constant bit
rate video
transmission
client playout
delay
time
Client에서 어느 정도 패킷이 버퍼에 모일 때까지
playout을 지연한다. 이것은 네트워크 상에서 발생할 수
있는 패킷의 지연과 지연 변이 영향을 상쇄시켜준다.
7-6
스트리밍 멀티미디어: client buffering
constant
drain
rate, d
variable fill
rate, x(t)
buffered
video
TCP의 체증 제어로 x(t)는 시간에 따라 변한다.
TCP는 손실된 패킷을 재전송하므로 UDP 보다 더 좋은 품질을
제공할 수 있지만 버퍼가 빌 수 있으므로 play가 일지 중지될 수
있다.
7-7
스트리밍 멀티미디어: UDP or TCP?
UDP
서버는 클라이언트에 적절한 최대한의 속도로 전송(congestion을
고려하지 않음)
보통 send rate= encoding rate = constant rate
그러면, fill rate = constant rate - packet loss
Jitter를 제거하기 위해 짧은 playout 지연 시간 (2-5 seconds) 사용
TCP
TCP 체증 제어 알고리즘이 허용하는 최대 속도로 전송
fill rate는 TCP 체증 제어로 변동
playout 지연 시간을 크게 한다: TCP 전달 속도의 변동을 완화시킨다.
HTTP/TCP는 방화벽을 쉽게 통과할 수 있다.
7-8
스트리밍 멀티미디어: client rate(s)
1.5 Mbps encoding
28.8 Kbps encoding
Q: 어떻게 서로 다른 client의 수신 속도를 처리할
것인가?
28.8 Kbps dialup modem
100 Mbps Ethernet
A: 서버는 다른 속도로 encoding된 비디오 copy를
보관하고 client의 속도에 맞추어 해당 비디오 copy를
전송한다.
7-9
스트리밍 미어어의 제어: RTSP
HTTP
멀티미디어 컨텐츠를
제어하는 방법이 없음
RTSP: RFC 2326
client-server 응용 계층
프로토콜
사용자의 미디어 제어:
되감기, 빠른 진행, 일시
정지, 등
RTSP가 하지않는 것:
audio/video가 어떻게
encapsulation되는지는
말하지 않음
streamed media가 어떤
수송 계층 프로토콜을
사용할 지 말하지 않음
(UDP 혹은 TCP 사용
가능)
media player가
audio/video를 어떻게
버퍼링할 지 말하지 않음
7-10
RTSP: out of band 제어
RTSP 메시지는 out-of-band로 전달:
RTSP 제어 메시지는 미디어 스트림과는 다른 포트
번호를 통해서 전달된다.
포트 번호: 554
미디어 스트림은 “in-band”로 간주할 수 있다.
7-11
RTSP 예
시나리오:
Metafile은 웹 브라우저에 전달된다.
브라우저는 media player를 동작시킨다.
media player는 제어 메시지 전달을 위한 연결과 데이터
전달을 위한 연결을 스트리밍 서버와 설정한다.
7-12
Metafile 예
<title>Twister</title>
<session>
<group language=en lipsync>
<switch>
<track type=audio
e="PCMU/8000/1"
src = "rtsp://audio.example.com/twister/audio.en/lofi">
<track type=audio
e="DVI4/16000/2" pt="90 DVI4/8000/1"
src="rtsp://audio.example.com/twister/audio.en/hifi">
</switch>
<track type="video/jpeg"
src="rtsp://video.example.com/twister/video">
</group>
</session>
7-13
RTSP 동작
7-14
RTSP 메시지 교환 예:
C: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0
Transport: rtp/udp; compression; port=3056; mode=PLAY
S: RTSP/1.0 200 1 OK
Session 4231
C: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0
Session: 4231
Range: npt=0C: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0
Session: 4231
Range: npt=37
C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0
Session: 4231
S: 200 3 OK
7-15