전송 프로토콜의 변화 Part.4-영상 전송 프로토콜이 다양한 이유

이번 시간에는 왜 다양한 영상 전송 프로토콜들이 필요한지에 대해 간단히 살펴보겠습니다.

이전글에서도 언급했듯이, 네트워크를 통해 데이터를 전송하는 과정은 현실 세계에서 물건을 전달하는 과정과 유사합니다.

마치 ‘우편 배달 시스템’을 모방하여 만든 것이죠.

물건을 보낼 때 우리는 상황에 따라 택배, 퀵서비스, 혹은 DHL과 같은 해외 배송업체를 이용합니다.

때로는 이삿짐 센터의 차량을 이용하여 통째로 짐을 옮기기도 합니다.

이와 같이 물건을 보내는 목적과 상황에 따라 다양한 프로토콜을 사용하게 됩니다.

영상 전송 프로토콜 또한 이와 마찬가지입니다.

실제로 네트워크를 통해 영상이 전송될 때 어떤 상황들이 있는지 한 번 알아보겠습니다.


이전 글에서 영상이 전달되는 과정을

기자가 촬영하는 현장부터 방송국, 그리고 기지국을 거쳐 시청자에게 전달되는 세 단계로 나누어 설명했습니다.

물론, 1인 방송이나 소규모 방송에서는 생략되는 부분이 있을 수 있지만,

영상 전송 프로토콜을 이해하는 데 도움이 되도록 이 구분을 유지하여 진행하겠습니다.


영상 전송 프로토콜 1단계-컨트리뷰션(Contribution)


영상 전송 프로토콜 1단계 RTMP와 RTSP

과거에는 중계차와 방송국을 연결하는 영상 전송에 SNG 또는 위성을 주로 활용했지만,

최근에는 인터넷을 통한 전송이 더 많아졌습니다.

이러한 과정을 보통 1단계 전송이라고 합니다.

이 단계는 ‘퍼스트마일(First-mile)’ 또는 ‘컨트리뷰션(Contribution) 단계’로도 불립니다.

한글로는 목적에 따라 같은 전송이지만, 영어로는 명확히 구분을 합니다.

현장에서 중계차를 통해 방송국으로 전송하는 컨트리뷰션(Contribution) 단계에서 몇 가지 특징이 있습니다.

이 단계에서는 ‘1:1 연결’만 가능합니다.

중계차에서 시청자에게 바로 전송하지 않으며, 중계차와 방송국 사이는 1:1 데이터 전송이 이루어집니다.

이 단계에서 가장 중요한 것은 ‘화질’과 ‘딜레이’입니다.

생방송 중 스튜디오에 있는 앵커가 현장에 나가 있는 기자를 불렀을 때 3초 이상의 딜레이가 발생하면 어떻게 될까요?

그래서 컨트리뷰션(Contribution) 단계에서는 ‘딜레이’가 매우 중요합니다.

또한 원본 화질을 유지하고 연결의 안정성을 보장해야 합니다.

이런 이유로 RTMP나 RTSP 같은 전통적인 프로토콜이 사용되었지만,

최근에는 SRT와 같은 전송 프로토콜이 더 많이 사용되고 있습니다.


영상 전송 프로토콜 2단계-디스트리뷰션(Distribution)


영상 전송 프로토콜 2단계-디스트리뷰션(Distribution)

영상 전송의 두 번째 단계인 ‘디스트리뷰션(Distribution) 단계’

방송국에서 제작된 PGM을 각 지역의 기지국으로 보내는 과정을 의미합니다.

최근에는 BTV, 올레 TV, LGU+와 같은 통신사로의 전송뿐만 아니라

YouTube나 Facebook으로의 전송도 ‘디스트리뷰션(Distribution)’ 단계로 포함합니다.

인터넷 방송의 경우에도 단순히 YouTube로만 보내는 것이 아니라 Twitch, Facebook, Afreeca TV 등

다양한 라이브 중계 플랫폼을 사용하는 것도 이 단계에 해당합니다.

이러한 중계 플랫폼까지 포함하여 프로그램을 전송하는 과정을 ‘디스트리뷰션(Distribution)’ 단계라고 말합니다.


영상 전송 프로토콜 2단계-디스트리뷰션(Distribution)
영상 전송 프로토콜 2단계-디스트리뷰션(Distribution)

디스트리뷰션(Distribution)단계는 앞에서 설명한 컨트리뷰션(Contribution) 단계와는 다른 개념으로, 1:N 전송을 의미합니다.

이 두 번째 단계에서도 딜레이를 최소화하고 원본 화질을 유지해야 합니다.

하지만 안타깝게도 디스트리뷰션(Distribution) 단계에서는 프로토콜을 선택할 수 없습니다.

시청자들에게 영상 서비스를 제공하는 플랫폼 업체가 지정한 형식으로 전송해야 합니다.

보통은 RTMP라는 전송 프로토콜을 사용합니다.

따라서 유튜브와 같은 인터넷 라이브 스트리밍 플랫폼을 사용하기 위해서는

해당 플랫폼에서 제공하는 ‘RTMP 포트’를 받아서 생방송을 전송해야 합니다.

현재 대다수의 인터넷 라이브 스트리밍 플랫폼이 RTMP를 사용하고 있습니다.


영상 전송 프로토콜 3단계-딜리버리(Delivery)


영상 전송 프로토콜 3단계-딜리버리(Delivery)

위에서 언급한 첫 번째 단계인 컨트리뷰션(Contribution)은 1:1 연결로,

두 번째 단계인 디스트리뷰션(Distribution)은 1:N 연결로 이루어집니다.

하지만 3단계는 다소 다릅니다.

이것이 바로 ‘딜리버리(Delivery) 단계’입니다.

딜리버리(Delivery) 단계는 유튜브 서버에서 각 시청자에게 데이터를 전달하는 과정이라고 생각하시면 됩니다.

이 단계에서는 이전 단계보다 훨씬 많은 데이터 전송이 이뤄지며, 동시 시청자가 수십 명에서 수천 명까지 늘어나면서 데이터 양이 급증합니다.

따라서 이전에 사용되던 RTMP와 같은 프로토콜은 적합하지 않습니다.


영상 전송 프로토콜 3단계-딜리버리(Delivery)
Mpeg-Dash와 HLS

대신 ‘HLS’나 ‘Mpeg-DASH’와 같은 프로토콜을 사용하여 딜리버리 과정을 진행합니다.

이 단계에서는 데이터 전송 프로토콜과 전달 과정이 변경되므로 중간에 변환 작업이 필요합니다.

딜리버리(Delivery) 단계는 엄밀히 말하면 라이브 스트리밍보다는 데이터를 순차적으로 전달하는 과정이라고 생각하시면 됩니다.

왜냐하면 ‘HLS’나 ‘Mpeg-DASH’같은 프로토콜이 영상을 10초 단위로 잘라서 그 뭉탱이를 그냥 던져주는 것이기 때문입니다.

이 프로토콜은 비디오를 작은 조각으로 잘라서 전송하기 때문에 유튜브 생방송의 경우 최소 15초 이상의 딜레이가 발생할 수밖에 없습니다.

이러한 이론적 문제들은 프로토콜의 특성에 따른 것입니다.

Leave a Comment