🤔 원본 영상이 시청자들의 동영상 플레이어에 전달되기 까지는?
원본 영상 ➡️ 라이브 인코더 ➡️ 미디어 서버 ➡️ 전송 서버(CDN) ➡️ 동영상 플레이어 ➡️ 시청자
구현에 따라 조금 달라질 수는 있지만 각 구성 요소들이 수행하는 기능은 반드시 필요하다!
- 원본 영상 ➡️ 라이브 인코더 : 영상 송출
- 미디어 서버 ➡️ 전송 서버(CDN) : 영상 변환 및 전송
- 동영상 플레이어 ➡️ 시청자 : 영상 재생
1. 라이브 인코더
- 원본 영상을 정해진 방식으로 압축(인코딩) 하고, 압축한 컨텐츠를 미디어 서버로 전송하는 역할을 한다.
- 인코더 -> 미디어 서버로 컨텐츠를 전송하는 것을 보통 송출이라고 한다.
압축(인코딩)
- 카메라로 촬영한 원본 영상을 그대로 미디어 서버에 전송하기에는 데이터 용량이 너무 크기 때문에 압축하는 과정이 반드시 필요하다.
- 아울러 미디어 서버에서 해석할 수 있는 압축 방식(코덱, Codec)을 사용해야 한다.
- 인코딩은 CPU를 많이 쓰는 작업이다.
- 인코딩 작업에 평균 CPU 사용률이 80% 를 넘을 경우 출력 영상의 품질이 나빠질 수 있습니다.
- 만약 CPU 부하로 인해 송출 중인 영상이 계속 끊기거나 버벅인다면 출력 해상도나 비트레이트를 줄이는 것이 좋다.
송출
- 미디어 서버로 영상을 보낼 때는 보통 인터넷 스트리밍에 최적화된 RTMP 프로토콜을 이용한다.
- 안정적인 송출을 위해서는 충분한 인터넷 업로드 대역폭이 확보되어야 한다.
가정이나 일반 사업장에서 사용하는 인터넷 품질은 상황에 따라 가변적일 수 있다.
절대 끊어지면 안 되는 중요한 방송이라면 별도 전용 회선을 설치하여 송출하는 것을 권장한다.
보통 인터넷 업로드 대역폭은 출력 비트레이트의 두 배 이상 확보되는 것이 안정적이며,
만약 송출 중인 영상이 계속 끊기거나 버벅일 경우 출력 해상도와 비트레이트를 낮춰주면 출력 품질 개선에 도움이 될 수 있다.
2. 미디어 서버
- 미디어 서버는 다음과 같은 인터넷 라이브 방송의 핵심적인 역할을 담당합니다.
- 인코더가 보내준 영상을 여러 가지 화질 및 비트레이트로 변환 (트랜스 코딩)
- 화질별로 변환된 영상을 다시 HLS 형식으로 변환 (트랜스먹싱 혹은 패킷타이징이라고 함)
화질 및 비트레이트 변환
- 인터넷 방송 서비스는 사용자의 다양한 디바이스 크기, 네트워크 환경에 맞는 영상을 시청하도록 하는 것이 중요하다.
- 불필요한 데이터 사용과 배터리 소모를 방지하고 최적의 화질을 보장할 수 있기 때문이다.
➡️ 이를 위해 미디어 서버에서 원본 영상을 여러 화질로 변환해 주어야 한다.
- 라이브 인코더가 압축해서 보내준 영상을 압축 해제(디코딩) 하고 화질 변환 후 다시 압축(인코딩) 한다.
➡️ 때문에 이 작업은 앞서 설명한 라이브 인코더와 동일하게 CPU를 많이 사용한다.
인코딩 작업에 GPU 가속을 이용하면 CPU 의 인코딩 부하를 상당량 줄일 수 있다.
HLS 변환
- HLS(HTTP Live Streaming)는 전 세계에서 가장 널리 사용하고 있는 실질적인 표준 HTTP 스트리밍 프로토콜이다.
- M3U8 확장자의 재생목록 파일과 영상을 잘게 쪼갠 TS 청크 파일들을 전송하며, 이를 통해 모바일과 PC 등 다양한 디바이스에서 영상을 재생할 수 있다.
지연 (Latency)
- 카메라가 촬영하는 시간과 그 영상이 시청자에게 표시되는 시간의 차이를 지연(latency) 라고 한다.
- 시청자와 실시간 소통이 필요할수록 짧은 지연(low latency) 이 필요하다.
- 과거 : 10초~15초 분량의 TS 청크를 재생 목록에 3개씩 담아 사용하는 것이 일반적
-> 미디어 서버 입장에서 30초~45초 정도 분량을 버퍼에 담아두었다가 전달하는 셈
-> 따라서 사용자 입장에서는 전송에 소요되는 시간까지 포함하여 최소 30초, 최대 1분에 가까운 지연이 발생한다.- 현재 : 1~2초 정도의 TS 청크를 사용한다면
-> 지연 시간을 10초 미만으로 줄일 수 있어
-> 소위 말하는 low latency를 구현할 수 있다.- 버퍼가 클수록 재생이 안정적이지만 지연 시간은 길어진다.
- 반대로 버퍼를 짧게 가져가면 지연은 적지만 네트워크 상황에 민감해져 재생 품질이 불안정해질 수 있다.
미디어 서버 솔루션
3. 전송 서버 (CDN)
- 미디어 서버에서 실시간으로 생성한 HLS 영상 조각 파일을 사용자에게 전달하려면 전송 서버가 있어야 한다.
- 일반적인 미디어 서버는 전송 서버의 역할까지 수행한다.
- 하지만 동시 시청수가 많은 방송일 경우 대규모 트래픽을 안정적으로 처리하기 위해 CDN 을 사용하는 것이 좋다.
- CDN에서 캐싱을 하지 않으면 동시에 많은 시청자가 접속했을 때 미디어 원본 서버로 많은 요청이 들어갈 수 있다.
- 그렇다고 무작정 캐싱 기간을 늘려놓아도 안된다.
- 최근에는 영상의 지연을 최소화하기 위해 TS 청크의 길이를 수초 단위로 사용하는 경우가 많다.
- 이때 HLS 재생목록 파일이 TS 청크의 재생 시간 내에 갱신되지 않으면 버퍼링이 발생하거나 플레이어가 영상 재생을 중단할 수 있다.
- 따라서 재생 목록 파일은 TS 청크의 절반 정도 시간만 캐싱하고 갱신되도록 설정해 두는 것이 좋다.
- 아울러 컨텐츠 보호 차원에서 CDN 캐시 남아있는 과거 영상을 다운받는 것을 방지하기 위해 정해진 시간 이후에 들어온 요청은 캐시가 되어 있더라도 컨텐츠를 응답하지 않도록 설정해두는 것이 필요하다.
4. 동영상 플레이어
- 동영상 플레이어는 말 그대로 사용자 단말에서 영상 컨텐츠를 재생하는 역할을 한다.
- 미디어 서버에서 최종적으로 만든 HLS 형식은 모바일 단말이라면 안드로이드, 아이폰 구분 없이 내장된 플레이어를 통해 문제없이 재생할 수 있다.
- 다만 Windows PC에서 HLS를 재생하려면 별도의 외부 플레이어가 필요하다.
- 동영상 플레이어를 사용할 때 브라우저의 보안적 제약으로 재생이 불가능한 상황이 발생할 수 있다.
- 서비스 페이지의 도메인과 영상이 전송되는 도메인이 다르면 재생이 되지 않는다.
-> 이를 위해 전송 서버나 미디어 서버에서 적절한 크로스 도메인 설정을 해주어야 한다. - 또한 HTTPS 페이지 내에서 HTTP 프로토콜로 전송되는 영상을 재생을 하려고 할 때도 마찬가지로 재생이 되지 않을 수 있으니
-> 영상도 HTTPS 프로토콜로 전송하는 것이 필요합니다.
인터넷 라이브와 관련된 기술 범위가 상당히 넓기 때문에 모든 것을 완전히 이해하기는 쉽지 않다.
게다가 이 모든 것을 직접 구축한다는 것은 더욱 어려운 일일 것이다!
