컴퓨터망

22. Multimedia

이 장에서는 오디오 및 비디오 서비스를 위해 인터넷을 사용하는 응용 프로그램에 중점을 둔다

Introduction

스트리밍 stored 오디오/비디오는 압축 오디오/비디오 파일에 대한 요청

스트리밍 라이브 오디오/비디오는 인터넷을 통해 라디오 및 TV 프로그램을 방송하는 것

interactive 오디오/비디오는 대화형 오디오/비디오 응용 프로그램에 인터넷을 사용하는 것

Digitizing audio and video

오디오 또는 비디오 신호를 인터넷에서 전송하려면 먼저 디지털화해야 한다

인터넷을 통해 비디오를 전송하려면 압축이 필요하다

Audio and video compression

인터넷을 통해 오디오나 비디오를 보내려면 압축이 필요하다
오디오 압축과 비디오 압축에 대해 설명한다

Video compression

Streaming stored audio/video

저장된 오디오 및 비디오를 스트리밍하는 방법을 알아본다
웹 서버에서 이러한 유형의 파일을 다운로드하는 것은 다른 유형의 파일을 다운로드하는 것과 다를 수 있다

Using a web server

• 압축된 오디오/비디오 파일을 텍스트 파일로 다운로드할 수 있다
• 클라이언트(브라우저)는 HTTP의 서비스를 사용하고 파일을 다운로드하기 위해 GET 메시지를 보낼 수 있다
• 웹 서버는 압축된 파일을 브라우저로 보낼 수 있다
• 그러면 브라우저는 일반적으로 미디어 플레이어를 사용하여 파일을 재생할 수 있다

이 접근 방식은 매우 간단하며 스트리밍이 필요하지 않다
그러나 오디오/비디오 파일은 일반적으로 압축 후에도 크기가 크다
이 접근 방식에서 파일은 재생되기 전에 완전히 다운로드되어야 한다
속도가 느리다!!

Using a web server with metafile

• 미디어 플레이어는 오디오/비디오 파일을 다운로드하기 위해 웹 서버에 직접 연결된다
• 웹 서버는 실제 오디오/비디오 파일과 오디오/비디오 파일에 대한 정보를 담고 있는 메타파일이라는 두 개의 파일을 저장한다

1. HTTP 클라이언트는 GET 메시지를 사용하여 웹 서버에 액세스
2. 메타파일에 대한 정보가 응답
3. 메타파일이 미디어 플레이어로 전달
4. 미디어 플레이어는 메타파일의 URL을 사용하여 오디오/비디오 파일에 액세스
5. 웹 서버가 응답

문제점은 브라우저와 미디어 플레이어가 모두 HTTP 서비스를 사용한다는 것

HTTP는 TCP를 통해 실행되도록 설계되었다
이것은 메타파일 검색에는 적합하지만 오디오/비디오 파일 검색에는 적합하지 않다
그 이유는 TCP가 손실되거나 손상된 세그먼트를 재전송하기 때문에 스트리밍 철학에 어긋나기 때문이다

Using a media server

UDP를 사용해야 한다
그러나 웹 서버에 액세스하는 HTTP와 웹 서버 자체는 TCP용으로 설계되었다
또 다른 서버인 미디어 서버가 필요하다
그림은 개념을 보여준다

1. HTTP 클라이언트는 GET 메시지를 사용하여 웹 서버에 액세스
2. 메타파일에 대한 정보가 응답
3. 메타파일이 미디어 플레이어로 전달
4. 미디어 플레이어는 메타파일의 URL을 사용하여 미디어 서버에 액세스하여 파일을 다운로드 다운로드는 UDP를 사용
5. 미디어 서버가 응답

Using a media server and RTSP

• RTSP(실시간 스트리밍 프로토콜)는 스트리밍 프로세스에 더 많은 기능을 추가하도록 설계된 프로토콜
• RTSP를 사용하여 오디오/비디오 재생을 제어할 수 있다

그림 25.13은 미디어 서버와 RTSP를 보여준다

1. HTTP 클라이언트는 GET 메시지를 사용하여 웹 서버에 액세스
2. 메타파일에 대한 정보가 응답
3. 메타파일이 미디어 플레이어로 전달
4. 미디어 플레이어는 미디어 서버와의 연결을 생성하기 위해 SETUP 메시지를 보냄
5. 미디어 서버가 응답
6. 미디어 플레이어는 재생(다운로드)을 시작하기 위해 PLAY 메시지를 보냄
7. 오디오/비디오 파일은 UDP를 통해 실행되는 다른 프로토콜을 사용하여 다운로드
8. TEARDOWN 메시지를 사용하여 연결 끊음
9. 미디어 서버가 응답

Streaming live audio/video

• 라이브 오디오/비디오 스트리밍은 라디오 및 TV 방송국에서 오디오 및 비디오를 방송하는 것과 유사
  • 방송국에서 방송하는 대신 인터넷을 통해 방송
• stored 오디오/비디오 스트리밍과 라이브 오디오/비디오 스트리밍 사이에는 몇 가지 유사점이 있다
  • 둘 다 지연에 민감하다
  • 둘 다 재전송을 수락할 수 없다
• 그러나 차이점이 있다
  • stored에서 통신은 유니캐스트 및 주문형이다
  • live 통신은 멀티캐스트 및 라이브이다

Real time interactive audio/video

실시간 대화형 오디오/비디오에서 사람들은 실시간으로 서로 통신한다
인터넷 전화 또는 VoIP(Voice over IP), 화상회의 등이 있다

Time RelationShip

실시간 데이터는 세션 패킷 간의 시간 관계를 보존해야 한다
예를 들어 첫 번째 패킷은 00:00:00에 시작하고 두 번째 패킷은 00:00:10에 시작하며 세 번째 패킷은 00:00:20에 시작한다
또한 각 패킷이 대상에 도달하는 데 1초(간단함을 위해 과장됨)가 걸린다고 상상해 본다
receiver는 첫 번째 패킷을 00:00:01에, 두 번째 패킷을 00:00:11에, 세 번째 패킷을 00:00:21에 재생할 수 있다

그러나 패킷이 다른 지연으로 도착하면 어떡해?
예를 들어, 첫 번째 패킷은 00:00:01(1초 지연)에 도착하고, 두 번째 패킷은 00:00:15(5초 지연)에, 세 번째 패킷은 00:00:27(7초 지연)에 도착한다
수신기가 00:00:01에 첫 번째 패킷을 재생하기 시작하고 끝냈지만 다음 패킷은 아직 도착하지 않았다
원격 사이트에서 비디오를 볼 때 첫 번째 패킷과 두 번째 패킷 사이, 두 번째 패킷과 세 번째 패킷 사이에 간격이 있다
이 현상을 지터라고 한다
그림은 상황을 보여준다

패킷 간의 지연으로 인해 실시간 데이터에 지터가 생긴다

TIme stamp

• 지터에 대한 한 가지 솔루션은 타임스탬프를 사용하는 것이다

• 각 패킷에 타임스탬프가 있는 경우 수신기는 각 패킷을 타임스탬프에 맞춰 실행한다

  • 즉, receiver는 각 패킷이 재생될 때를 알고 있다

패킷 사이에 간격이 없게 진행된다

지터를 방지하기 위해 패킷에 타임스탬프를 이용해 도착 시간을 재생 시간과 분리할 수 있다

Playback buffer

• 도착 시간과 재생 시간을 구분하려면 재생될 때까지 데이터를 저장할 버퍼가 필요하다
  • 버퍼를 playback buffer라고 한다
• 첫 번째 패킷의 첫 번째 비트가 도착하면 receiver는 임계값에 도달할 때까지 데이터 재생을 지연한다

앞의 예에서 첫 번째 패킷의 첫 번째 비트는 00:00:01에 도착한다
임계값은 7초이고 재생 시간은 00:00:08이다
임계값은 데이터의 시간 단위로 측정된다
데이터의 시간 단위가 임계값과 같아질 때까지 재생이 시작되지 않는다
데이터는 각각 다른 속도로 버퍼에 저장되지만 고정된 속도로 추출되고 재생된다
버퍼의 데이터 양이 줄어들거나 늘어나지만 지연이 임계 데이터 양을 재생하는 시간보다 짧으면 지터가 없다

실시간 트래픽을 위해서는 playback buffer가 필요하다

실시간 트래픽을 위해서는 각 패킷의 시퀀스 번호가 필요하다

• 순서를 알아야한다

실시간 트래픽은 멀티캐스팅 지원이 필요하다

translation은 수신 네트워크의 대역폭과 일치하도록 페이로드의 인코딩을 더 낮은 품질로 변경하는 것을 의미

• 때때로 실시간 트래픽은 translation이 필요하다
• translater는 고대역폭 비디오 신호의 형식을 저품질 신호로 변경할 수 있는 컴퓨터다
• 예를 들어 소스가 5Mbps에서 고품질 비디오 신호를 생성하고 대역폭이 1Mbps 미만인 수신자에게 보내는 경우에 필요하다
  • 신호를 수신하려면 신호를 디코딩하고 더 적은 대역폭이 필요한 낮은 품질로 다시 인코딩하는 translater가 필요하다

Mixing은 여러 트래픽 스트림을 하나의 스트림으로 결합하는 것을 의미

• 동시에 데이터를 보낼 수 있는 소스가 두 개 이상인 경우(비디오 또는 오디오 회의에서와 같이) 트래픽은 여러 스트림으로 구성된다
• 트래픽을 하나의 스트림으로 수렴하기 위해 다른 소스의 데이터를 혼합할 수 있다

TCP는대화형 멀티미디어 트래픽에 적합하지 않다 재전송해도 소용이 없으니깐

UDP는 대화형 트래픽에 TCP보다 더 적합
그러나 UDP의 단점을 보완하기 위해서는 또 다른 전송 계층 프로토콜인 RTP의 서비스가 필요하다

RTP

• RTP(realtime transport protocol)는 인터넷에서 실시간 트래픽을 처리하도록 설계된 프로토콜이다
• RTP에는 전달 메커니즘(멀티캐스팅, 포트 번호 등)이 없다
• RTP는 UDP와 함께 사용해야 한다
• RTP는 UDP와 응용 프로그램 사이에 있다
• RTP는 타임스탬프, 시퀀싱 및 믹싱 기능을 관리한다

그림 25.18은 프로토콜에서 RTP의 위치를 보여준다

RTP는 임시 짝수 UDP 포트를 사용합니다.

• RTP 자체가 전송 계층 프로토콜이지만 RTP 패킷은 IP 데이터그램에 직접 캡슐화되지 않는다
  • 대신 RTP는 응용 프로그램처럼 취급되며 UDP 사용자 데이터그램으로 캡슐화된다
• 다른 응용 프로그램과 달리 wellknown 포트가 RTP에 할당되지 않는다
  • 짝수 포트 번호를 사용한다
    • 다음 번호(홀수)는 RTP와 함께 사용되는 RTCP(Real-Time Transport Control Protocol)입니다.

RTCP

• RTP는 소스에서 목적지로 데이터를 전달하는 한 가지 유형의 메시지만 허용한다
  • 세션에 다른 메시지가 필요하다
• RTCP(realtime transport 프로토콜)는 이러한 목적을 위해 설계된 프로토콜이다
  • 메시지는 데이터의 흐름과 품질을 제어하고 수신자가 소스에 피드백을 보낼 수 있도록 한다

Message type

RTCP는 RTP에 대해 선택된 포트 번호 뒤에 오는 홀수 UDP 포트 번호를 사용한다

Voice over ip

하나의 실시간 대화형 오디오/비디오 애플리케이션인 VoIP 또는 인터넷 전화에 집중해 보겠다
아이디어는 인터넷을 몇 가지 추가 기능이 있는 전화 네트워크로 사용하는 것이다
circuit switched 네트워크를 통해 통신하는 대신 이 응용 프로그램은 packet switched 인터넷을 통해 두 당사자 간의 통신을 허용한다
이러한 유형의 통신을 처리하기 위해 SIP 및 H.323의 두 가지 프로토콜이 설계되었다

SIP Address

SIP에서는 이메일 주소, IP 주소, 전화 번호 및 기타 유형의 주소를 사용하여 발신자와 수신자를 식별할 수 있다

SIP Session

Establishing

SIP에서 세션을 설정하려면 3방향 핸드셰이크가 필요하다
호출자는 통신을 시작하기 위해 UDP, TCP 또는 SCTP를 사용하여 INVITE 메시지를 보낸다
수신자가 세션을 시작하려는 경우 응답 메시지를 보낸다
응답 코드가 수신되었음을 확인하기 위해 호출자는 ACK 메시지를 보낸다

Communicating

세션이 설정된 후 호출자와 수신자는 두 개의 임시 포트를 사용하여 통신할 수 있습니다.

Terminating

세션은 어느 쪽이 보낸 BYE 메시지로 종료될 수 있습니다.