인터넷 라이브 방송은 기술

• 오늘날 스마트폰, PC와 같이 인터넷에 연결된 디바이스만 있으면 원하는 실시간 인터넷 방송을 언제 어디서든 시청하고 마음만 먹으면 직접 방송까지 할 수 있는 시대에 도달하였습니다.
• 최근에는 인터넷 방송 플랫폼의 발전과 네트워크 품질의 개선으로 인터넷 방송을 진행하는 BJ(Broadcasting Jockey)와 시청자들 간의 소통이 방송 중 거의 실시간으로 가능한 수준까지 되었습니다.
• 실시간으로 인터넷 라이브 방송을 하기 위해서는 인터넷 라이브 방송 뒷단에서 방송을 가능하게 하는 다양한 기술들이 사용되고 있습니다.

 

원본 영상이 시청자들의 동영상 플레이어 까지 전달되는 과정

• 구현에 따라 조금 달라질 수는 있지만 각 구성 요소들이 수행하는 기능은 반드시 필요
  원본 영상 → 라이브 인코더 → 미디어 서버 → 전송 서버(CDN) → 동영상 플레이어 → 시청자
  
  
• 구성 요소가 어떤 역할
  1. 영상 송출 : 원본 영상 → 라이브 인코더
  2. 영상 변환 및 전송 : 미디어 서버 → 전송 서버(CDN)
  3. 영상 재생 : 동영상 플레이어→ 시청자

 

 

라이브 인코더

• 라이브 인코더는 원본 영상을 정해진 방식으로 압축(인코딩) 하고, 압축한 콘텐츠를 미디어 서버로 전송
• 인코더에서 미디어 서버로 컨텐츠를 전송하는 것을 송출이라고 함

 

1. 인코더의 종류

1. PC에 설치해서 사용할 수 있는 소프트웨어 인코더
2. 박스 형태의 하드웨어 인코더
3. 촬영하면서 송출까지 할 수 있는 모바일 앱 인코더
4. 오픈소스인 ffmpeg을 이용하여 구현한 인코더

 

2. 압축(인코딩)

• 카메라로 촬영한 원본 영상을 그대로 미디어 서버에 전송하기에는 데이터 용량이 너무 크기 때문에 압축하는 과정이 반드시 필요
• 미디어 서버에서 해석할 수 있는 압축 방식(코덱, Codec)을 사용
• 인터넷 방송에는 H.264/AAC 코덱이 주로 사용, 최근에는 더욱 압축 효율이 좋은 H.265 코덱을 사용하는 경우 늘어남
• 인코딩은 CPU를 많이 쓰는 작업 → 인코딩 작업에 평균 CPU 사용률이 80% 를 넘을 경우 출력 영상의 품질이 나빠짐
• CPU 부하로 인해 송출 중인 영상이 계속 끊기거나 버벅거린다면 출력 해상도나 비트레이트를 줄여야 함
• 소프트웨어 인코더를 사용할 경우 안정적인 방송을 위해서 쿼드코어 CPU 가 탑재된 PC 사용을 권장

 

3. 송출

• 미디어 서버로 영상을 보낼 때는 인터넷 스트리밍에 최적화된 RTMP 프로토콜을 이용
• 과거에는 UDP 기반의 RTSP 프로토콜을 많이 사용했으나 최근에는 RTMP 프로토콜이 거의 표준처럼 사용
• 안정적인 송출을 위해서는 충분한 인터넷 업로드 대역폭이 확보 필요
• 가정이나 일반 사업장에서 사용하는 인터넷 품질은 상황에 따라 변하게 됨 → 중요한 방송이라면 별도 전용 회선을 설치하여 송출 권장
• 인터넷 업로드 대역폭은 출력 비트레이트의 두 배 이상 확보되는 것이 안정적
• 송출 중인 영상이 계속 끊기거나 버벅거릴 경우 출력 해상도와 비트레이트를 낮춰주면 출력 품질 개선에 도움이 됨

 

 

미디어 서버

• 미디어 서버는 인터넷 라이브 방송의 핵심적인 역할
• 인코더가 보내준 영상을 여러 가지 화질 및 비트레이트로 변환(트랜스 코딩)
• 화질별로 변환된 영상을 다시 HLS 형식으로 변환 (트랜스먹싱 혹은 패킷타이징이라고 함)

 

1. 화질 및 비트레이트 변환

• 인터넷 방송 서비스는 사용자의 다양한 디바이스 크기, 네트워크 환경에 맞는 영상을 시청하도록 하는 것이 중요 → 불필요한 데이터 사용과 - - 배터리 소모를 방지하고 최적의 화질을 보장할 수 있어야 함
• 미디어 서버에서 원본 영상을 여러 화질로 변환해 주어야 함
• 화질 및 비드레이트 변환은 라이브 인코더와 동일하게 CPU를 많이 사용 → 라이브 인코더가 압축해서 보내준 영상을 압축 해제(디코딩) 하고 화질 변환 후 다시 압축(인코딩) 함
• 인코딩 작업에 GPU 가속을 이용하면 CPU의 인코딩 부하를 상당 부분 줄일 수 있음

 

2. HLS 변환

• HLS(HTTP Live Streaming)는 전 세계에서 가장 널리 사용하고 있는 실질적인 표준 HTTP 스트리밍 프로토콜
• M3U8 확장자의 재생목록 파일과 영상을 잘게 쪼갠 TS 청크 파일들을 전송 → 모바일과 PC 등 다양한 디바이스에서 영상을 재생 가능
  
  ※ HLS 지연(latency)
  • 카메라가 촬영하는 시간과 그 영상이 시청자에게 표시되는 시간의 차이를 지연(latency)이라고 함
  • 시청자와 실시간 소통이 필요할수록 짧은 지연(low latency) 이 필요
  • 과거에는 10초 ~ 15초 분량의 TS 청크를 재생 목록에 3개씩 담아 사용 → 미디어 서버 입장에서 30초~45초 정도 분량을 버퍼에 담아두었다가 전달
  • 위 경우 사용자 입장에서는 전송에 소요되는 시간까지 포함하여 최소 30초, 최대 1분에 가까운 지연이 발생
  • 버퍼가 클수록 재생이 안정적이지만 지연 시간은 길어짐
  • 버퍼를 짧게 가져가면 지연은 적지만 네트워크 상황에 민감해져 재생 품질이 불안정해짐
  • 최근에는 네트워크 환경이 좋아져 보다 공격적으로 튜닝하여 사용
  • 1~2초 정도의 TS 청크를 사용 → 지연 시간을 10초 미만으로 줄일 수 있어 low latency를 구현 가능

 

3. 미디어 서버 솔루션

• 3.1. Wowza Media Server (유료)
  • 유료이지만 다양한 기능과 우수한 인코딩 성능으로 널리 사용
  • 안정적인 운영을 위해 평균 CPU 사용률이 60% 를 초과하지 않도록 관리해 주는 것이 중요
  • 720P HD 화질을 포함하여 3~4 종류의 품질로 트랜스코딩을 해야 한다면 쿼드코어는 약간 불안
  • 쿼드 코어 이상의 코어를 탑재한 CPU를 사용하는 것이 안정적
    
    
• 3.2. Nginx-rtmp (오픈소스)
  • Nginx-rtmp는 nginx의 모듈로 동작하는 미디어 스트리밍 서버
  • RTMP 소스를 Pull 혹은 Push 방식으로 입력받을 수 있고 RTMP/HLS/MPEG-DASH 출력을 지원
  • 오픈 소스인 ffmpeg을 연동하면 트랜스코딩을 비롯하여 기타 다양한 기능들을 구현 가능할 수 있어 유료 솔루션의 좋은 대안 가능

 

 

전송 서버 (CDN)

• 미디어 서버에서 실시간으로 생성한 HLS 영상 조각 파일을 사용자에게 전달하려면 전송 서버가 있어야 함 → 일반적인 미디어 서버는 전송 서버의 역할까지 수행
• 동시 시청수가 많은 방송일 경우 대규모 트래픽을 안정적으로 처리하기 위해 CDN을 사용하는 것이 좋음
• CDN에서 캐싱을 하지 않으면 동시에 많은 시청자가 접속했을 때 미디어 원본 서버로 많은 요청이 들어갈 수 있음
• 무작정 캐싱 기간을 늘려놓는 것도 위험
• 최근 영상의 지연을 최소화하기 위해 TS 청크의 길이를 수초 단위로 사용
• HLS 재생목록 파일이 TS 청크의 재생 시간 내에 갱신되지 않으면 버퍼링이 발생하거나 플레이어가 영상 재생이 중단됨
• 재생 목록 파일은 TS 청크의 절반 정도 시간만 캐싱하고 갱신되도록 설정해야 함
• 콘텐츠 보호 차원에서 CDN 캐시 남아있는 과거 영상을 다운로드하는 것을 방지하기 위해 정해진 시간 이후에 들어온 요청은 캐시가 되어 있더라도 콘텐츠를 응답하지 않도록 설정 필요

 

 

동영상 플레이어

• 동영상 플레이어는 말단말에서 영상 컨텐츠를 재생하는 역할
• 미디어 서버에서 최종적으로 만든 HLS 형식은 모바일 단말이라면 안드로이드, 아이폰 구분 없이 내장된 플레이어를 통해 문제없이 재생 가능
• HLS는 Apple에서 만든 방식으로 맥 OS에서도 재생을 지원
• Windows PC에서 HLS를 재생하려면 별도의 외부 플레이어가 필요 → Window PC의 버전에 따라 다르지만 IE 11 이하에서는 HLS 재생을 지원하는 Flash 플레이어를 사용해야 함
• Chrome이나 Edge 같이 MSE (Media Source Extensions)를 지원하는 최신 브라우저라면 Javascript로 구현된 플레이어를 사용 → hls.js, video.js 사용
• 동영상 플레이어를 사용할 때 브라우저의 보안적 제약으로 재생이 불가능한 상황이 발생 가능
• 서비스 페이지의 도메인과 영상이 전송되는 도메인이 다르면 재생 X → 전송 서버나 미디어 서버에서 적절한 크로스 도메인 설정 필요
• HTTPS 페이지 내에서 HTTP 프로토콜로 전송되는 영상을 재생을 하려고 할 때, 재생이 되지 않을 수 있으니 영상도 HTTPS 프로토콜로 전송 필요

 

참고 자료

• https://medium.com/naver-cloud-platform/%EC%9D%B8%ED%84%B0%EB%84%B7-%EB%9D%BC%EC%9D%B4%EB%B8%8C-%EB%B0%A9%EC%86%A1%EC%9D%80-%EC%96%B4%EB%96%A4-%EA%B8%B0%EC%88%A0%EB%A1%9C-%EB%A7%8C%EB%93%A4%EC%96%B4%EC%A7%88%EA%B9%8C%EC%9A%94-98423dc7fcd4