[미디어 기술 이해] 6단계로 알아보는 라이브 생방송 송출 원리
최근 ‘라방’ 이라는 단어의 부상과 함께 네이버 쇼핑라이브에서 Live로 쇼핑도 하고, BTS 공연도 생중계로 볼 수 있게 되었죠. 이처럼 다양한 도메인에서 라이브 방송의 활용도는 높아지고 있습니다.
🔻BTS 웸블리 공연 생중계의 기술🔻
기존에 녹화된 영상을 시청하는 VOD와는 다른 특징을 가진 라이브 방송. 어떤 원리로 송출되는 것일까요?
카메라로 촬영되는 영상이 시청자(클라이언트)에게 전달되기까지, 다음과 같은 단계들을 거치게 됩니다.
라이브 방송 영상의 전달 단계
카메라 ▶ Encoder(인코더) ▶ Media Server(+CDN Server) ▶ 동영상 플레이어 ▶ 시청자(Client)
각 순서마다 기술 요소를 살펴보겠습니다.
카메라 ▶ Encoder
우선, 카메라에서 영상을 Encoder(인코더)로 보내게 됩니다.
* 잠깐! Encoding(인코딩)이란? “컴퓨터를 이용하여 영상, 이미지 또는 소리 데이터를 생성할 때, 원래의 데이터양을 줄이기 위하여 데이터를 코드화하고 압축하는 것. 저장하는 방법에 따른 각각 코덱값이 설정되어 있고, 이러한 파일을 재생할 때에는 코드화된 내용을 원래의 정보로 변환하는 디코딩 작업을 한다.” — 출처 : 네이버 국어사전
압축되지 않는 동영상은 무지막지하게 용량이 크기 때문에 그대로 작업하면 편집, 보관, 전송, 배포를 하는데 시간 및 비용 측면에서 낭비가 발생합니다. 따라서 큰 용량의 영상을 압축하는 과정이 필요한데, 이 과정에서 코덱을 활용하여 다양한 방식으로 영상 압축을 하게 됩니다.
네이버 클라우드 플랫폼 Live Station에서는 아래와 같이 다양한 코덱을 지원합니다.
대표적인 영상코덱에는 H.264 가 있으며, 음성코덱으로는 AAC가 있습니다.
H.264 : 효율적인 압축률을 보여주는 코덱입니다. 손실 압축 방식이지만 뛰어난 화질을 유지하며 동영상 크기를 줄여 주기 때문에 고화질 영상의 웹 배포용으로 많이 사용합니다
AAC : 오디오 코덱으로 MPEG-4 Audio 라고도 부릅니다. MP3(MPEG-1 Layer3)에 비해 뛰어난 음질과 높은 압축률을 보이지만 인코딩 시간이 오래 걸린다는 단점을 가지고 있습니다.
원본 파일을 압축한다고 할 때, 압축의 방식에도 여러 종류가 존재합니다. 대표적으로는 손실 압축과 무손실 압축이 있습니다. 이러한 압축방식을 이미지를 압축시키는 JPEG 과 PNG를 통해 설명해보겠습니다.
압축 방식 이해하기
📌 JPEG : Joint Photographic Experts Group
JPEG의 경우 손실 압축형식을 사용합니다. 디테일 일부를 희생시켜 크기를 줄이는 방식인데요. 메모리 공간을 절약할 수 있고, 온라인 게시나 이메일 전송 등에 효율적으로 사용됩니다.
다시 말해 JPEG는 파일의 크기를 엄청나게 줄일 수 있는 슬라이딩 스케일(Sliding Scale) 압축 방식을 사용하여 메모리 공간을 절약할 수 있다는 장점이 있지만, 단점으로는 과하게 압축을 할 경우 부자연스러우며 확대를 할 경우에는 픽셀처럼 보이는 현상이 나타난다는 점을 꼽을 수 있습니다.
📌PNG : Portable Network Graphics
PNG의 경우 무손실 압축을 사용합니다. 때문에 JPEG와는 다르게 이미지 디테일 손실이 없습니다. 결과적으로 JPEG형식보다 더 고품질 이미지를 생성하는 것입니다. 동시에, 고품질의 이미지를 생성한다는 것은 파일의 크기가 커진다는 것을 의미합니다. 따라서 무손실 압축 방식의 PNG로는 고품질의 이미지를 생성할 수 있지만 상대적으로 많은 메모리를 사용하게 됩니다.
최근에는 네트워크 및 스토리지 기술의 발전으로 압축 없이도 원하는 작업을 수행할 수 있기 때문에, JPEG보다는 PNG가 온라인에서 많이 사용하는 이미지의 형태로 자리잡고 있습니다.
이러한 이미지 압축 방식의 예시처럼, 각각의 상황과 목적에 맞는 압축 방식을 이용한 코덱을 사용하는 것이 중요합니다.
Encoder ▶ Media Server(+ CDN Server)
이렇게 Encoder를 거친 뒤, 미디어 서버로 영상을 보낼 때는 인터넷 스트리밍에 최적화된 스트리밍 프로토콜을 사용하게 됩니다. ‘스트리밍 프로토콜’이라는 용어가 다소 생소하실 수 있어, 간단히 설명드리겠습니다.
스트리밍이란, 멀티미디어 파일을 다운로드 하는 동시에 실행하는 방법이나 기술을 말합니다. 예를 들면 넷플릭스에서 영화를 보는데 영화 전체를 다운로드 받고 난 뒤에 즉, 2GB 가량의 영상을 전부 다운 받은 후 영화가 재생된다면 사용자 불만이 폭주하겠죠?
실제 넷플릭스는 그렇지 않습니다. 다운로드와 동시에 바로 재생이 되며, 추가 다운로드가 계속 진행되는 방식을 스트리밍이라고 하며, 이러한 스트리밍의 규칙을 스트리밍 프로토콜이라고 부릅니다.
아래는 대표적인 스트리밍 프로토콜의 사례입니다.
Encoder : RTMP,RTSP,webRTC,SRT
Player : HLS,DASH,LL-HLS,webRTC,SRT
Encoder의 경우 주로 RTMP(Real Time Messaging Protocol) 프로토콜을 사용합니다.
과거에는 UDP기반의 RTSP(Real Time Streaming Protocol) 프로토콜을 많이 사용하였으나 최근에는 RTMP 프로토콜이 거의 표준이 되어가고 있습니다.
Player의 경우에는 HLS(HTTP-Live Streaming), MPEG-DASH가 대표적입니다.
스트리밍이란 ‘다운로드와 동시에 미디어가 재생되는 기술’이라고 설명 드렸는데, 스트리밍의 효율적인 동작을 위해서는 파일을 작은 단위로 분할해야 합니다.
이 과정은 대표적인 Player 프로토콜인 HLS, DASH을 통해 알아보도록 하겠습니다.
Player 프로토콜 작동 과정 이해하기 feat. HLS & DASH
✅ 우선 H.264 + AAC등 포맷의 동영상 파일을 작은 단위로 분할합니다.(용량에 따라 2초 ~10초 단위)
✅ 이와 더불어 분할된 파일의 재생순서가 작성된 manifest 파일을 생성합니다.
manifest파일에는 분할된 동영상 파일을 어떤 순서로 몇 초간 재생할 것인지에 대한 내용들이 텍스트로 작성되어 있습니다. HLS의 경우에는 .m3u8 파일이, Dash의 경우 .mpd(xml)와 같은 manifest 파일이 생성됩니다.이러한 과정을 거쳐 작은 단위로 분할된 미디어 파일은 mp2ts와 mp4로 구성되어 있고 mp2ts의 확장자는 .ts입니다.
✅ 마지막으로 HLS, DASH를 지원하는 브라우저나 Application에서 Manifest 파일을 읽어서 재생합니다. Manifest 파일에 작성되어 있는 분할된 동영상 파일을 순차적으로 읽어 들여 재생하게 됩니다. 따라서 첫번째 segment file을 다 불러오게 되면 재생을 시작할 수 있게 되고, 재생이 진행되면서 2번째 및 3번째 segment file을 뒤에서 계속 실행합니다.
만약 동영상을 중간부터 재생한다고 하면 manifest 파일(.m3u8, mpd)에 근거하여 해당 타임에 맞는 segment file을 먼저 다운로드를 하게 될 것입니다.
manifest 파일인 .m3u8 (HLS), .mpd(DASH)는 하나 또는 여러 개의 미디어 파일 경로가 작성되어 있는 파일이라고 설명 드렸었죠?
최근에는 위 그림과 같이 비디오 스트리밍에 있어서 공통적인 미디어 포맷을 사용하여 복잡성과 Latency를 줄 일수 있는 CMAF의 등장으로 빠른 속도로 Adaptive Bitrate Stream을 제공하기 위한 표준이 등장하기도 하였습니다.
네이버 클라우드 플랫폼 Live Station 채널을 생성하시면 [녹화 저장 설정]이라는 기능을 선택할 수 있습니다. 녹화 저장 설정 기능은 실시간 영상의 녹화파일을 자동으로 MP4, HLS 형식을 지정해서 Object Storage에 저장합니다.
* Live Station 녹화설정 유저 가이드
Object Storage로 이동해 보겠습니다. 아래 그림과 같이 playlist.m3u8를 포함한 많은 세그먼트 파일들을 확인할 수 있습니다. 이 Segment파일들은 다시 Initialization Segment(초기화 세그먼트) 와 Media Segment(미디어 세그먼트)로 나뉘어지게 됩니다.
위의 그림의 맨 아래 부분에서 playlist.m3u8을 확인할 수 있는데요. 해당 파일이 Manifest 파일이 될 것입니다. 이 playlist.m2u8이라는 파일 내에 실제 Segment 파일들이 어떤 식으로 재생되어야 하는지가 작성되어 있는 것입니다.
Initialization Segment(초기화 세그먼트)는 manifest 파일을 부르며, 실제 동영상 정보를 담고 있는 Media Segment(미디어 세그먼트)의 시퀀스를 디코딩하는데 필요한 정보를 담고 있습니다. 또한 코덱 초기화 데이터, 트랙 ID, 타임스탬프 등을 포함합니다.
아래 그림을 통해 playlist.m3u8을 자세히 살펴보도록 하겠습니다.
#EXTM3U àm3u8 파일#EXT-X :Version:3 à m3u8 버전3 사용#EXT-X-TARGETDURATION:35 à 총 재생시간 35초#EXTINF:10 à 재생시간 10초
그 후에는 각각의 ts(세그먼트 파일) 들이 시간별로 반복됩니다.
playlist.m3u8 파일의 위에 보이는 .ts 파일들 또한 하나하나의 segment 파일들이며, 하나의 동영상이 여러 개로 분할된 상태를 보여줍니다.
각각의 .ts 파일들은 Media Segment(미디어 세그먼트)에 해당됩니다. Media Segment(미디어 세그먼트)는 패킷화된 동영상들, 그리고 자신이 플레이어 되어야 할 미디어 타임라인상의 타임스탬프 정보가 포함된 실제 동영상 데이터입니다.
Media Server(+ CDN Server) ▶ 동영상 플레이어
안정적인 송출을 위해서는 충분한 인터넷 업로드, 대역폭이 확보되어야 합니다. 따라서 Bitrate를 변환하는 작업도 필수적으로 필요합니다.
비트레이트(Bitrate)는 특정한 시간 단위(이를테면 초 단위)마다 처리하는 비트의 수를 뜻합니다.
나아가 멀티비트레이트(Multi Bitrate)는 비디오 플레이어에서 보여지는 화질 선택 기능과 밀접하게 관련이 있습니다. 멀티비트레이트는 비트레이트가 다른 여러 개의 영상을 준비하여 필요에 따라 영상을 전환하는 방식이나 기술을 뜻합니다.
아래 그림을 보면 Bandwitdth에 따라 각기 다른 Bitrate Stream이 선택되는 것을 확인할 수 있습니다.
뿐만 아니라 해상도에 따라서 평균적으로 필요한 비트는 달라지게 됩니다. Bitrate가 높을수록 동영상은 더 많은 비트를 가지게 되고, 화질은 좋아집니다. 하지만 그만큼 용량은 커지게 됩니다.
위의 그림 속 표시한 영역을 보면 bitrate가 평균적으로 4500K 정도인 BPS의 bandwidth에서Full HD(1080p)가 선택됨을 알 수 있습니다. 이는 곧 1920X1080의 해상도를 말하게 되는 것입니다.
네이버 클라우드 플랫폼에서도 Video Quality를 자동 혹은 수동으로 선택할 수 있으며, 아래 그림과 같이 Video Bitrate에 따라서 Quality가 달라지는 것을 확인할 수 있습니다.
따라서 Bitrate별로 여러 개의 동영상 셋을 준비해서 제공하게 됩니다.
동영상 플레이어 ▶ 시청자(Client)
이후 실시간으로 생성한 HLS 및DASH 영상 조각 파일을 사용자에게 전달하려면 전송 서버가 있어야합니다. 일반적인 미디어 서버는 전송 서버의 역할까지 수행하지만, 동시 시청자가 많은 방송일 경우에는 대규모 트래픽을 안정적으로 처리하기 위해 CDN을 사용하는 것을 권장합니다.
Apple의HLS의 경우 사파리에서 바로 미디어 소스를 적용할 수 있지만, DASH일 경우에는 대부분 MSE(Media Source Extensions)를 이용해서 직접 미디어 소스를 확장합니다. DASH나 HLS는 스트리밍할 미디어 데이터의 정보를 동영상 플레이어에게 전달하는 목적으로 만들어졌기 때문에 실질적으로 플레이어에 관여하지 않습니다.
따라서 시청자(클라이언트)측에서 이러한 Adaptive Streaming을 가능하게 하는 표준 기술로 MSE (Media Source Extensions)을 사용하며 이를 통해 스트리밍 데이터를 플레이어로 전달하게 됩니다.
MSE((Media Source Extensions)의 경우 과거에는 어도비(Adobe)의 플래시 혹은 마이크로소프트의 실버 라이트가 아니면 불가능했지만, 최근에는 표준 웹기술만으로도 구현이 가능해지고 있으며 이러한 웹기술이 나오는 속도도 점점 빨라지고 있는 추세입니다.
MSE(Media Source Extensions)에 대해 상세하게 알고 싶으시면 아래 링크를 참고 부탁드립니다.
- MSE 상세 설명자료 : https://www.w3.org/TR/media-source/
지금까지 설명한 내용을 6단계의 흐름으로 정리를 해보겠습니다.
1. 클라이언트는 실시간 영상을 시청하기 위해 동영상의 각 Quality & Resolution 별 Segment 정보들이 담겨있는 Manifest(.m3u8, .mpd) 파일을 Server에게 요청합니다.
2. Manifest 파일을 파싱합니다.
3. 파싱 된 파일에서 필요한 정보들을 얻습니다. 즉, 비디오에 대한 정보, 어떤 해상도의 퀄리티를 사용할 수 있는지 그리고 어디서 해당 세그먼트를 받을 수 있는지(CDN) 파악합니다.
4. 클라이언트는 User Network Bandwidth을 측정하고 manifest 내용에 따라 가장 최적의 비디오 퀄리티를 선택(Multi Bitrate)한 뒤, 필요한 Segment를 다운로드합니다.
5. 다운로드한 Segment 데이터를 MSE 에게 제공합니다.
6. MSE에서 받은 데이터를 형식에 맞게 디코딩하고 영상을 실행합니다.
지금까지 네이버 클라우드 플랫폼 미디어상품 중 Live Station 서비스가 어떤 동작원리로 송출되는지 살펴보았습니다.
위 과정 실행에 어려움이 있으시면 댓글 또는 네이버 클라우드 플랫폼 페이스북 유저 그룹에 남겨주시면 빠르게 도와드리겠습니다.
🔻 Live Station 관련 다른 포스팅도 함께 살펴보세요🔻
< BTS 웸블리 공연의 감동을 전하는 Live Station >
< Live Station 으로 다양한 이벤트를 즐겨요, 이벤터스>
< 누구나 쉽게 실시간 라이브 플랫폼을 만드는 방법>
