Multimedia Networking
상위 문서: 컴퓨터 네트워크
개요
현재 전 세계의 대부분의 사람들은 인터넷을 이용하여 여러 멀티 미디어 건텐츠에 접근할 뿐만 아니라, 동영상과 오디오등을 인터넷에 업로드하기도 한다. 이렇듯, 멀티미디어 컨텐츠는 인터넷의 중요한 구성 요소가 되어가고 있다. 해당 문서에서는 이러한 멀티미디어 서비스를 제공하는 멀티미디어 애플리케이션의 분류 체계와, 기존 애플리케이션과의 차이점에 대해 다룬다. 또한 이를 구현하기 위한 여러 기술 들과 기법에 대해 다룬다.
Multimedia Networking Applications
멀티미디어 네트워크 애플리케이션이란 오디오나 비디오를 사용하는 모든 네트워크 애플리케이션을 의미한다.
Properties of Video
비디오란 이미지들의 연속이며, 여러 이미지들이 동일한 속도로 표시되는 것이다. 예를 들어 24 images/sec(24fps)란 초당 24장의 정지 이미지로 전송되는 비디오 품질을 의미한다. 또한 디지털 이미지란 픽셀 배열이며, 각각의 픽셀은 비트로 표시된다. 예를 들어 RGB 픽셀은 24비트로 표현 가능하다.
비디오의 가장 큰 특징은 높은 비트 전송률(bit rate)를 요규한다는 것이다. 화상 회의는 적어도 100kbps의 전송률을 요구하며, 고화질 영상 스트리밍 서비스는 3Mbps 이상의 전송률을 요구한다. 비디오의 또다른 특징은 압축이 가능하다는 것이며, 이를 통해 영상 품질과 비트 전송률 사이의 절충(trade-off)를 택할 수 있다. 이렇게 멀티미디어의 데이터를 압축하고 디지털 형식으로 변환하는 과정을 인코딩(encoding)이라고 한다.
압축을 할 때 중요한 것은 중복(redundancy)를 활용하는 것으로 이는 공간적 중복(spatial redundancy)와 시간적 중복(temporal redundancy)로 구분된다. 공간적 중복은 이미지 내부에서 반복되는 색상, 패턴들을 의미하며, 시간적 중복은 연속된 프레임에서 중복되는 프레임을 의미한다. 보라색 픽셀이 하나의 프레임 내에서 중복된다고 할 때, 각 픽셀의 색 정보를 N번 전송하는 대신 공간적 중복을 활용하여 보라색 + 반복 횟수: N만을 전송하면 된다. 또한 시간적 중복을 활용한다면 연속된 프레임(frame i와 frame i+1) 사이의 차이만 전송하여, 전체 프레임을 다 보내지 않고, 변화된 부분만 보내는 방식이다.
동영상의 비트레이트는 CBR(Constant Bit Rate)와 VBR(Variable Bit Rate)로 나뉜다. CBR은 고정 전송률로 비디오를 전송하는 방식이다. 즉, 매 초마다 동일한 양의 데이터를 사용해서 비디오를 압축하는 방식이다. 인코딩 속도가 일정하여 비교적 예측가능하며, 이에 따라 일정한 네트워크 대역폭을 요구한다는 장점이 있다. 하지만 모든 프레임에 동일한 비트 수를 사용하므로, 동적인 화면과 같이 압축이 어려운 프레임에 대해서는 영상의 품질이 떨어질 수 있다는 단점이 있다.
VBR이란 가변 전송률로 비디오를 전송하는 방식이다. 즉, 프레임 간의 변화나 복잡도에 따라 인코딩 속도가 달라지는 방식이다. 이에 따라 장면의 복잡도에 따라 적절한 전송률을 사용하여 비디오 서비스의 품질을 일정하게 유지할 수 있다는 장점이 있다. 하지만 요구되는 네트워크 대역폭의 요구량이 일정하지 않다는 단점이 있다.
Properties of Audio
실제의 소리는 연속적인 파동 형태의 아날로그 신호이다. 따라서 디지털 전송을 위해서는 이를 아래와 같은 과정을 통해 디지털 신호로 변환하여야 한다:
- 아날로그 오디오 신호는 일정한 속도로 샘플링(sampling)된다.
- 샘플링이란, 일정 시간 마다 소리의 세기를 측정하는 것이다.
- 예를 들어, 전화는 초당 8000번의 샘플링을, CD에 저장된 음악은 초당 44100번의 샘플링을 요구한다.
- 샘플링하여 측정된 소리의 세기는 어떤 유한한 값 중 하나로 반올림(quantized)되며, 이 과정을 양자화(quantization)이라고 한다.
- 예를 들어 8비트 사용시, 가능한 양자화 값은 256개이다.
- 이 과정에서 원래의 값과 차이가 생기는데, 이를 양자화 오차(quantization error)라고 한다.
- 모든 샘플의 비트 표현은 이에 해당하는 디지털 신호가 된다.
이러한 과정은 figure 1을 통해서 더욱 잘 이해할 수 있다. 또한 이를 통해서 오디어의 전송률을 계산할 수 있는데, 예를 들어 초당 8000번의 샘플링이 진행되고, 256개의 양자화 값이 존재할 때, 해당 오디오의 전송률은 log2256bits/sample x 8000samples/sec = 64000bps(64kbps)가 된다. 오디오 스피커를 통해 이를 다시 재생하기 위해서는 수신자가 해당 디지털 신호를 다시 아날로그 신호로 변환해야 한다. 하지만 이것은 원래 신호의 근사치일 뿐이며, 원래의 아날로그 신호에 더 가까워지기 위해서는 샘플링 속도 혹은 양자화 값의 수를 늘려야 한다. 즉, 비디오와 마찬가지로 QoS와 비트 전송률 간의 절충(trade off) 관계가 있다.
Types of Multimedia Network Application
인터넷은 여러 가지 유형의 멀티미디어 애플리케이션을 지원하며, 이는 크게 세 가지 범주로 나뉜다:
- 저장된 오디오/비디오 스트리밍(Streaming Stored Audio and Video)
- IP 기반의 음성/영상 통화(Conversational Voice- and Video-over-IP)
- 실시간 오디오/비디오 스트리밍(Streaming Live Audio and Video)
먼저, 저장된 오디오/비디오 스트리밍에 대해 논의하자. 이때 해당 문서에서는 저장된 비디오 스트리밍 애플리케이션에 대해서 집중하여 서술한다. 저장된 오디오 스트리밍(예: Spotify의 음악 스트리밍 서비스)은 저장된 비디오 스트리밍과 매우 유사하지만, 일반적으로 비트 전송률이 훨씬 낮을 뿐이다. 이 범주의 애플리케이션에서, 전송하는 매체는 미리 녹화되어 서버에 저장되어 있는 비디오이다. 이때 저장된 비디오 스트리밍 애플리케이션에는 다음과 같은 세 가지 특징이 있다:
- 스트리밍(Streaming): 저장된 비디오 스트리밍 애플리케이션에서는 클라이언트가 서버로부터 비디오를 받고 몇 초 내에 재생을 시작한다. 즉, 클라이언트는 비디오의 한 지점을 재생하는 동시에, 서버로부터 이후의 부분을 받는다. 이 기법을 스트리밍이라고 하며, 이는 전체의 비디오 파일을 먼저 다운로드하고 재생하는 방식보다 더욱 빠른 재생을 가능하게 한다.
- 상호작용성(Interactivity): 미디어는 사전에 녹화된 것이며, 이에 따라 사용자는 비디오를 일시 정지하거나, 앞으로 또는 뒤로 이동하거나, 빨리 감기 등을 할 수 있어야 한다. 또한 해당 동작을 클라리언트가 요구했을 때, 그 반응 시간은 매우 짧아야 한다.
- 연속 재생(Continuous playout): 생이 시작되면, 비디오는 원래 녹화된 타이밍에 맞춰 계속 재생되어야 한다. 따라서 데이터는 클라이언트가 재생하기 전에 적시에 서버로부터 도착해야 하며, 그렇지 않으면 QoS는 프레임 정지/건너뜀 등의 현상으로 악화된다.
이러한 스트리밍 서비스에서 가장 중요한 성능 지표는 처리량(throughput)이다. 이는 연속적인 재생을 보장하기 위해서는 네트워크가 해당 비디오의 비트 전송률보다 높은 처리량을 제공해야 하기 때문이다.
그리고, IP 기반 음성/영상 통화에 대해서 논의하자. IP 기반의 음성 통화는 사용자의 관점에서 전통적인 circuit-switching 전화 서비스와 유사하여 종종 인터넷 전화라고도 불린다. 또한 VoIP(Voice-over-IP)로도 알려져 있다. 영상 통화는 음성에 더하여 참여자의 영상도 포함된다는 점에서만 구분된다. 이때 VoIP에서 중요한 특성 두가지는 아래와 같다:
- timing consideration: 약간의 지연만 생겨도 사용자는 불편을 느끼므로 음성/영상 애플리케이션은 지연에 매우 민감하다. 이는 delay tolerance가 매우 낮다는 말로 표현되기도 한다.
- loss-tolerant: 데이터 손실에 비교적 관대하여, 데이터의 완전성과 무결성이 상대적으로 중요하지 않다는 의미이다.
마지막으로 실시간 오디오/비디오 스트리밍에 대해 논의하자. 실시간 오디오/비디오 스트리밍 서비스는 전통적인 라디오/TV 방송과 유사하지만, 전송이 인터넷을 통해서 이루어진다는 점에서 차이가 있다. 이들 애플리케이션은 사용자의 위치에 상관없이 생방송을 시청할 수 있게 한다. 해당 애플리케이션은 보통 동일한 프로그램을 동시에 여러 사용자에게 전송한다. 오늘날 인터넷에서는 보통 CDN을 이용해 이를 수행한다. 저장된 오디오/비디오 스티리밍과 마찬가지로, 네트워크는 실시간 멀티미디어 흐름마다 비디오 소비 속도보다 높은 평균 처리량을 제공해야 한다.
Streaming Stored Video
스트리밍 비디오 애플리케이션의 경우, 사전 녹화된 비디오들은 서버에 저장되어 있고, 사용자들은 이러한 비디오를 요청하여 원하는 때에 재생할 수 있도록 서버에 요청을 보낸다. 사용자는 비디오를 처음부터 끝까지 중단 없이 볼 수도 있고, 끝나기 훨씬 전에 시청을 중단할 수도 있으며, 또는 일시정지하거나 앞으로/뒤로 이동하면서 비디오와 상호작용할 수도 있다. 이때 스트리밍 비디오 시스템은 다음의 세 가지 범주로 분류될 수 있다:
- UDP 스트리밍
- HTTP 스트리밍
- 적응형(Adaptive) HTTP 스트리밍
이 세 가지 방식 모두 실제로 사용되지만, 오늘날 대부분의 시스템은 HTTP 스트리밍 및 적응형 HTTP 스트리밍을 사용한다. 이 세 가지 방식의 스트리밍 비디오는 모두 공통적으로 클라이언트 측 애플리케이션 버퍼링을 광범위하게 사용하여, 서버-클라이언트 간의 지연 변화 및 사용 가능한 대역폭 변화의 영향을 완화한다는 특성을 가진다. 이는 각 클라이언트는 비디오를 요청한 후 실제 재생이 시작되기까지의 몇 초 정도의 초기 지연은 허용하므로, 클라이언트는 비디오가 도착하자마자 바로 재생을 시작할 필요가 없으며 대신에 버퍼에 일정량의 비디오를 저장(버퍼링)한 뒤 재생을 시작하는 방식으로 구현된다. 이러한 방식은 몇가지 이점을 가진다:
- 서버에서 클라이언트로의 지연이 일시적으로 늘어나 특정 비디오 청크의 도착이 지연되더라도, 해당 청크가 아직 재생되지 않은 버퍼된 청크가 소진되기 전에 도착하기만 하면, 이러한 지연은 사용자에게 전혀 인지되지 않는다.
- 서버에서 클라이언트로의 대역폭이 일시적으로 비디오 소비 속도보다 낮아지더라도, 클라이언트의 버퍼가 완전히 고갈되지만 않는다면 사용자는 끊김 없이 비디오를 시청할 수 있다.
Figure 2는 클라이언트 측의 버퍼링을 시각적으로 보여준다. 예를 들어 비디오가 CBR로 인코딩되었다고 가정하자. 따라서 각 비디오 청크는 일정시간 Δ 동안 재생될 프레임들을 포함한다. 이 경우 서버는 첫 번째 청크를 시간 t0에 전송하고, 두 번째 블록을 t0 + Δ, t0 + 2Δ에 전송하며, 그 이후도 마찬가지로 일정 간격으로 전송한다. 한편 클라이언트 입장에서는 재생을 시작한 이후, 각 청크가 이전 청크 이후의 Δ 시간 간격으로 재생되어야, 비디오가 끊김 없이 재생된다. 그러나 네트워크의 end system 간의 지연은 가변적이므로, 비디오 청크마다 서버에서 전송된 시간과 클라이언트에서 수신된 시간 사이의 지연은 다르다. 예를 들어 첫 번째 블록은 t1에 도착하고, 두 번째 블록은 t2에 도착한다고 하자. 이때 각 청크 사이의 네트워크 지연은 figure 2에서 수평 거리로 표현된다. 만약 클라이언트가 첫 번째 청크가 도착한 즉시, 즉 t1에 재생을 시작한다면,
두 번째 청크는 t1 + Δ까지 도착하지 않아 재생이 불가능하며, 이는 서비스의 품질을 저하시킨다. 하지만 만약 클라이언트가 재생을 t3까지 지연시키고, 그동안 청크 1~6이 모두 도착해 있다면, 이후에는 모든 청크가 재생 시간 전에 이미 도착해 있으므로, 정상적인 타이밍으로 재생이 가능하다.
UDP Streaming
UDP 스트리밍에서는 서버가 UDP 프로토콜을 통해 일정한 속도로 비디오 청크를 전송하여 클라이언트의 비디오 소비 속도에 맞추어 전송 속도를 조절한다. 예를 들어, 비디오 소비 속도가 2Mbps이고, 각 UDP 패킷이 8,000비트의 비디오 데이터를 담고 있다면, 서버는 자신의 소켓에 (8,000비트)/(2Mbps) = 4밀리초마다 UDP 패킷 하나를 전송한다. 이때 UPC는 혼잡 제어(congestion control) 메커니즘을 사용하지 않기 때문에, 서버는 TCP에서 요구되는 속도 제어 제약 없이 비디오 소비 속도 그대로 패킷을 네트워크에 밀어 넣는다.
또한 UDP 스트리밍은 서버 → 클라이언트 사이의 비디오 스트림 외에도, 클라이언트 ↔ 서버 간 별도의 제어 연결(control connection)을 유지한다는 것이다. 이 연결은 클라이언트가 세션 상태 변경 명령어(예: 일시 정지, 재개, 위치 이동 등)를 전송하는 데 사용된다. 이러한 제어 연결을 위해 RTSP(Real-Time Streaming Protocol) 프로토콜이 사용된다.
하지만 UDP는 아래와 같은 단점을 지닌다:
- 연속 재생이 보장되지 않음: 서버와 클라이언트 사이의 사용 가능 대역폭이 예측 불가능하게 변동하기 때문에, 고정 속도 UDP 스트리밍은 연속적인 재생을 보장하지 못할 수 있다.
- 미디어 제어 서버 필요: 클라이언트 → 서버로의 상호작용 요청이나, 클라이언트의 현재 상태를 추적하기 위해 RTSP 서버 같은 미디어 제어 서버가 필요하다.
- UDP 차단 문제: 많은 방화벽이 UDP 트래픽을 차단하도록 설정되어 있어, 이러한 방화벽 뒤에 있는 사용자는 UDP 비디오를 수신할 수 없다.
HTTP Streaming
HTTP 스트리밍에서는 비디오가 단순히 특정 URL을 가진 일반 파일 형태로 HTTP 서버에 저장된다. 사용자가 비디오를 보고 싶을 때, 클라이언트는 서버와 TCP 연결을 맺고, 해당 URL에 대해 HTTP GET 요청을 보낸다. 그러면 서버는 HTTP 응답 메시지 안에 비디오 파일을 담아 가능한 한 빠르게[1] 전송한다. 클라이언트 측에서는, 수신된 바이트들이 클라이언트 애플리케이션 버퍼에 저장된다. 이 버퍼에 저장된 바이트 수가 임계값을 넘으면, 클라이언트 애플리케이션은 재생을 시작한다.
얼핏 보면 TCP를 통한 서버-클라이언터 간의 전송 속도는 혼잡 제어 메커니즘에 의해서 제한되기 때문에, TCP 상에서의 비디오 스트리밍이 제대로 작동할 수 없을 것처럼 보인다. 하지만 버퍼링과 프리패칭(prefatching) 기법은 혼잡 제어 메커니즘에도 불구하고 TCP에서의 HTTP 스트리밍을 가능케 한다. 또한 TCP 상에서의 HTTP 사용은 방화벽 및 NAT에 의해 제약을 받지 않고, RTSP 서버 같은 미디어 제어 서버가 필요 없다는 장점이 있다.
Prefetching Video
비디오 프리패칭(Prefetching Video)이란, 앞으로 재생할 데이터를 일시적으로 버퍼에 저장하는 것이다. 이는 end system 사이의 지연 시간 변화와, 가용 대역폭 변화의 영향을 완화한다. Figure 2에서는 서버가 비디오를 재생 속도에 맞추어 전송한다고 가정했지만, 저장형 비디오 스트리밍의 경우 클라이언트는 보다 높은 속도로 다운로드를 시도하여 미래에 재생될 프레임을 미리 받아둘 수 있으며, 이렇게 미리 로드된 프레임들은 클라이언트 측의 버퍼에 저장된다. TCP 스트리밍에서는 이러한 프리패칭이 자연스럽게 발생하는데, 이는 TCP의 혼잡 회피 메커니즘이 사용 가능한 대역폭을 최대한 활용하고자 하기 때문이다. 예를 들어 클라이언트의 비디오 소비 속도가 1 Mbps이고, 서버→클라이언트 전송 가능 속도가 1.5 Mbps일 때, 아주 짧은 초기 지연 후 재생이 가능하며, 초당 500 Kbit 씩 버퍼에 축적된다. 이렇게 버퍼에 데이터를 축적함으로써, 향후의 네트워크 속도가 1 Mbps 아래로 일시적으로 떨어지더라도, 클라이언트는 버퍼 덕분에 끊김 없는 재생을 유지할 수 있다.
Client Application Buffer and TCP Buffers
Figure 3는 HTTP 스트리밍 시의 클라이언트와 서버 간의 상호 작용을 보여준다. 서버 측에서 흰색 부분은 이미 소켓에 전송된 비디오 데이터이며, 하늘색 부분은 아직 전송되지 않은 부분이다. 소켓을 통해 전송된 바이트는 TCP 송신 버퍼에 저장된 뒤에 인터넷으로 보내진다. Figure 3에서는 TCP 송신 버퍼가 가득 차있는 상태이므로, 서버는 일시적으로 소켓을 통해 바이트를 저장할 수 없다. 한편 클라이언트 측에서는, TCP 수신 버퍼에서 바이트를 읽어서 애플리케이션 버퍼로 이동시킨다. 동시에 클라이언트 애플리케이션은 주기적으로 애플리케이션 버퍼에서 비디오 프레임을 가져오고 압축 해제 후 사용자 화면에 출력한다.
사용자가 비디오를 일시 정지하였을 때에는, 버퍼에서 바이트를 제거하지 않지만, 서버에서는 계속 데이터를 전송하므로 결국 클라이언트 애플리케이션 버퍼가 가득 찬다. 이 경우 역방향 압력(back pressure)이 발생하여, TCP 수신 버퍼도 데이터를 내보내지 못해 가득 차고, 서버의 TCP 송신 버퍼도 데이터를 전송할 수 없어 가득 찬다. 이에 따라 서버는 전송을 멈추고, 사용자가 재생을 재개할 때까지 블록(block)된다. 이러한 역방향 압력은 꼭 일시 정지 시에만 발생하는 것은 아니다. 즉, 일반적으로 재생할 때에도 애플리케이션 버퍼가 가득 차면, TCP 버퍼들도 가득 차게 되고, 서버는 전송 속도를 줄일 수밖에 없다.
결과적으로, 클라이언트가 버퍼에서 f 비트를 제거하면, 서버는 f 비트를 새로 전송할 수 있게 된다. 따라서, 서버 전송 속도는 클라이언트의 소비 속도보다 클 수 없다. 즉, 클라이언트 애플리케이션 버퍼가 가득 차면, HTTP 스트리밍에서 서버의 전송 속도에 상한이 생긴다.
Analysis of Video Streaming
Figure 4와 같은 상황을 통해서 비디오 스트리밍의 초기 지연과 버퍼 고갈로 인한 멈춤 현상을 이해해 보자. 우선 figure 4에서는 다음과 같은 정의를 사용한다:[2]
- B: 클라이언트 애플리케이션 버퍼의 크기 (비트 단위)
- Q: 재생을 시작하기 위해 필요한 최소 버퍼량 (
Q < B) - r: 비디오 소비 속도 (예: 초당 30프레임 × 프레임당 100,000비트 → r = 3 Mbps)
이 상황에서, 서버가 클라이언트 버퍼가 가득 차있지 않은 이상, 고정된 전송률 x로 비트를 전송한다고 가정하자. 또한 이때 시점 t = 0일 때 버퍼는 비어있으며, 비디오가 도착하기 시작한다. 이때 재생이 시작되기 위해서는 Q개의 비트가 도착해야 하고, 비트가 도착하는 속도는 x이고, 버퍼에서 제거되는 비트는 없다. 따라서 재생이 시작되는 시점 tp은 아래와 같이 계산된다:
tp = Q / x
tp 이후, 만약 x < r이라면, 버퍼는 절대 가득 차지 않으며, 재생 시작 후, r 속도로 버퍼가 고갈되며, x 속도로 채워지므로 결국 버퍼는 고갈되고 비디오는 멈춘다.(freeze) 이에 따라 다시 Q 비트를 모으기까지 tₚ만큼 대기하며, 재생과 멈춤이 반복된다. 이때 주목할 만한 것은 Q의 크기, 즉 tp가 커짐에 따라
반면 x > r이면 tp 이후 버퍼 내에 저장된 비트의 수는 x - r 속도로 증가한다. 이에 따라 버퍼 내에 저장된 비트의 수가 Q에서 B까지 도달하는데 걸리는 시간인 tf는 아래와 같이 계산된다:
tf = (B - Q) / (x - r)
이 경우, 초기 지연 이후 비디오가 멈추는 일 없이 비디오가 끝날 때까지 연속 재생된다.
