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