스트리밍 서비스(온 디맨드, 라이브)에 대한 이해

Summary

 

원본 영상
=> 특정 코덱에 따라 인코더가 인코딩을 진행 (미디어 서버가 이해할 수 있는 코덱이어야 함)
=> 미디어 서버에 송출
=> 미디어 서버는 디코딩한 후 특정 화질과 비트레이트로 변환(트랜스 코딩)
=> HLS로 변환 
=> CDN을 거치자(캐싱)
=> 사용자에게 서비스한다.

 

온 디맨드 스트리밍 vs 라이브 스트리밍

aws.amazon.com/ko/cloudfront/streaming/

미디어 스트리밍 자습서 | CDN, 비디오 호스팅, 배포 | Amazon CloudFront

 

온 디맨드 스트리밍 서비스와 라이브 스트리밍은 다르다. (너무 당연한 이야기인가?)

 

온 디맨드 스트리밍 서비스는 이미 영상을 가지고 있는 상태에서 스트리밍으로 서빙을 하는 것이다.

watcha, netflix, hulu, 아마존 프라임 등은 전부 온 디맨드 스티리밍 서비스를 하는 것이다.

 

HLS는 촬영 즉시 생방송으로 스트리밍 서비스를 하는 것이다.

twitch, afreeca, 마카롱 등이 라이브 스트리밍을 서비스하면서 동시에 과거 영상들을 온 디맨드 스트리밍을 하고 있다.

 

라이브 스트리밍을 위한 전통적인 프로토콜은 RTSP인데 도입 비용이 높았고, 이를 애플 사에서 개선한 것이

HLS(HTTP Live Streaming) 프로토콜이다. 가장 대중적인 스트리밍 포맷이라고 한다.

이름은 Live Streaming인데 온 디맨드 스트리밍에서도 사용한다고 한다.

 

HLS에서는 네이버 기술 블로그에서 살펴보자.

https://d2.naver.com/helloworld/7122

 

 

AWS에서 제시하는 스트리밍을 위한 아키텍쳐

어쨌거나 온 디맨드 스트리밍과 라이브 스트리밍을 위한 AWS에서 제시하는 아키텍쳐 자체도 다르다.

 

온디맨드는 아래와 같이 아키텍쳐를 구성한다.

서버리스로 구동하는 건 AWS에서 추천하는 바이나 서비스하고자 하는 영상이 적을 경우에는 수작업으로 해도 좋다.

그러나 기왕 하는 김에 람다로 S3 이벤트를 감지하여 자동으로 MediaConvert를 트리거하는 것이 멋지긴하다.

 

원본 => S3 스토리지 저장 => 트랜스 코딩, HLS 변환(MediaConvert가 해줌) => CDN => 사용자

aws.amazon.com/ko/solutions/implementations/video-on-demand-on-aws/

https://aws.amazon.com/ko/cloudfront/streaming/

 

생방송 서비스는 아래와 같이 제시한다.

원본 => 인코딩 => 미디어 서버(트랜스 코딩, HLS 변환) => CDN => 사용자로 이어지는 플로우에 대한 상세한 설명은 후술되어 있다.

aws.amazon.com/ko/solutions/implementations/live-streaming-on-aws/

https://aws.amazon.com/ko/cloudfront/streaming/

 

 

 

온 디맨드 스트리밍 서비스가 서비스 되는 과정

원본 => 스토리지에 저장 => 트랜스 코딩, HLS 변환 => CDN => 사용자로 이어집니다.

라이브 스트리밍 서비스 과정을 공부하면 자연스럽게 알게 되기도 하고, 온 디맨드 스트리밍 서비스는 제가 직접 이후에 구축해볼 것이니 생략하겠습니다.

 

 

라이브 스트리밍 서비스가 서비스 되는 과정

* 네이버 기술 블로그의 글을 참고하여 작성되었습니다.

인터넷 라이브 방송은 어떤 기술로 만들어질까요?

 

원본 영상 → ⓐ 라이브 인코더 → ⓑ 미디어 서버 → ⓒ 전송 서버(CDN) → ⓓ 동영상 플레이어 → 시청자

 

1. 원본 영상 → 라이브 인코더 > 영상 송출
2. 미디어 서버 → 전송 서버(CDN) > 영상 변환 및 전송
3. 동영상 플레이어→ 시청자 > 영상 재생

 

각 단계에 대해서 자세히 살펴보도록하겠습니다.

 

ⓐ 라이브 인코더

라이브 인코더는 원본 영상을 정해진 방식으로 압축(인코딩) 하고, 압축한 컨텐츠를 미디어 서버로 전송하는 역할을 합니다. 일반적인 인코더인데 실시간으로 인코딩을 하여 송출한다고 해서 '라이브'라고 붙였을 따름이다. 인코더에서 미디어 서버로 컨텐츠를 전송하는 것을 보통 송출이라고 말합니다.

 

- 인코더의 종류

 

PC에 설치해서 사용할 수 있는 소프트웨어 인코더

박스 형태의 하드웨어 인코더(방송국에서 볼 수 있는 그 커다란 인코더)

촬영과 동시에 송출까지 할 수 있는 모바일 앱 인코더

편하게는 ffmpeg를 이용하여 간단한 인코더를 구현할 수도 있다.

요새는 그냥 소프트웨어적으로 인코딩하는게 편하다.

 

- 압축(인코딩)을 왜 해야 해? + 압축 방식(Codec)

 

카메라로 촬영한 원본 영상을 그대로 미디어 서버에 전송하기에는 데이터 용량이 너무 크기 때문이다.

또, 압축하는 방식도 쌩으로 압축을 하는 것이 아니라 미디어 서버가 해석할 수 있는 압축 방식(코덱, Codec)을 사용해야 합니다. 

인터넷 방송에는 H.264/AAC 코덱이 주로 쓰이며, 최근에는 더욱 압축 효율이 좋은 H.265 코덱을 사용하는 경우도 많다고 한다. 

 

프리미어 프로의 Format을 참고해보시면 인코딩 방식을 확인할 수 있습니다.

 

 

인코딩은 CPU를 많이 쓰는 작업이다. 인코딩 작업에 평균 CPU 사용률이 80% 를 넘을 경우 출력 영상의 품질이 나빠질 수 있다. 만약 CPU 부하로 인해 송출 중인 영상이 계속 끊기거나 버벅인다면 출력 해상도나 비트레이트를 줄이는 것이 좋습니다.

 

- 송출

 

원본 영상을 특정 코덱으로 압축했다면 미디어 서버에 송출하면 됩니다.

미디어 서버로 영상을 보낼 때는 인터넷 스트리밍에 최적화된 RTMP(Real Time Messaging Protocol) 프로토콜을 이용한다고 한다. 

물론, RTMP의 단점들과 기술의 발전으로 SRT(Secure Reliable Transport) 프로토콜을 이용해야 한다는 의견도 있다.

blogs.akamai.com/kr/2020/10/rtmp-akamai.html

 

인터넷 업로드 대역폭은 출력 비트레이트의 두 배 이상 확보되는 것이 안정적이며, 만약 송출 중인 영상이 계속 끊기거나 버벅일 경우 출력 해상도와 비트레이트를 낮춰주면 출력 품질 개선에 도움이 될 수 있습니다.

 

 

ⓑ 미디어 서버 

원본 영상을 인코딩을 거쳐 미디어 서버로 송출되었다. 여기서 미디어 서버가 하는 일은 다음과 같다.

1. 인코더가 보내준 영상을 여러 가지 화질 및 비트레이트로 변환 (트랜스 코딩)
2. 화질별로 변환된 영상을 다시 HLS 형식으로 변환 (트랜스먹싱 혹은 패킷타이징이라고 함)

 

 

- 화질 및 비트레이트 편환(트랜스 코딩)

 

실시간 영상을 시청하는 디바이스 환경에 따라 적절한 영상을 줘야 합니다. 작은 스마트폰에서 UHD 빡빡하게 내보내면 불필요한 데이터 사용, 배터리 소모가 됩니다. 적절한 화질을 보장하기 위해서 원본 영상을 여러 화질로 변환해야 합니다.

 

트랜스 코딩 작업은 CPU를 많이 사용합니다. 이유는 라이브 인코더가 압축해서 보내준 영상을 압축 해제(디코딩) 하고 화질 변환 후 다시 압축(인코딩) 하기 때문입니다. 인코딩 작업에 GPU 가속을 이용하면 CPU 의 인코딩 부하를 상당량 줄일 수 있습니다.

 

- HLS 변환

 

HLS 프로토콜의 이점은 앞서 언급하였습니다. M3U8 확장자의 재생목록 파일과 영상을 잘게 쪼갠 TS 청크 파일들을 전송하며, 이를 통해 모바일과 PC 등 다양한 디바이스에서 영상을 재생할 수 있습니다.

 

twitch 스트리밍의 네트워크 탭을 확인해보면 ts 청크 파일들이 브라우저로 들어오고 있는 것을 확인해볼 수 있습니다.

 

여기서 중요한 건 TS 청크를 몇 초 간격으로 자를 것인가 입니다. 청크의 단위에 따라 지연 시간이 결정되거든요.

 

과거에는 10초~15초 분량의 TS 청크를 재생 목록에 3개씩 담아 사용하는 것이 일반적이었습니다. 미디어 서버 입장에서 30초~45초 정도 분량을 버퍼에 담아두었다가 전달하는 셈입니다. 따라서 사용자 입장에서는 전송에 소요되는 시간까지 포함하여 최소 30초, 최대 1분에 가까운 지연이 발생합니다. 버퍼가 클수록 재생이 안정적이지만 지연 시간은 길어집니다.

 

요새 누가 방송을 하는데 latency가 30초가 되면 다들 아우성을 치겠죠. 그러면 버퍼를 짧게 가져가면 됩니다. 대신 지연은 적지만 네트워크 상황에 민감해져 재생 품질이 불안정해질 수 있습니다. 요새는 네트워크 환경이 좋아져 1~2초 정도의 TS 청크를 사용한다고 합니다.

 

- 미디어 서버로 뭘 써야 하나?

 

Wowza Media Server(유료)

Nginx-rtmp(무료)

 

• Nginx-rtmp 는 nginx 의 모듈로 동작하는 미디어 스트리밍 서버입니다. RTMP 소스를 Pull 혹은 Push 방식으로 입력받을 수 있고 RTMP/HLS/MPEG-DASH 출력을 지원합니다. 여기에 ffmpeg 을 연동하면 트랜스코딩을 비롯하여 기타 다양한 기능들을 구현할 수 있어 유료 솔루션의 좋은 대안이 될 수 있습니다.

 

 

ⓒ 전송 서버 (CDN) => 캐싱해서 원본 서버에게 요청하는 것을 줄이자.

 

사실 CDN은 없어도 서비스를 할 수 있기는 합니다. CDN이 하는 일이 뭡니까. 캐싱이죠. 캐싱 안해도 원본 서버에 데이터를 요청하면 되니깐요. 미디어 서버에서 바로 사용자에게 HLS 영상 조각 파일을 쏘면 됩니다.

 

그러나 대규모 트래픽을 안정적으로 처리하기 위해 CDN 을 사용하는 것이 좋습니다.  만약 CDN이 없이 서비스를 하고 있는데 많은 인원이 들어온다면 원본 서버에 무리가 가게 됩니다. 이는 라이브 스트리밍 뿐만 아니라 일반적인 웹 서비스에서 상식적인 내용입니다.

 

 

- 그러면 캐싱 기간을 어느 정도로 잡아야 하는가?

 

영상의 지연을 최소화하기 위해 TS 청크의 길이를 짧게(1~3초) 단위로 사용하는 경우가 많습니다. 이때 HLS 재생목록 파일이 TS 청크의 재생 시간 내에 갱신되지 않으면 버퍼링이 발생하거나 플레이어가 영상 재생을 중단할 수 있습니다. 

 

따라서 재생 목록 파일은 TS 청크의 절반 정도 시간만 캐싱하고 갱신되도록 설정해 두는 것이 좋습니다.

또, 컨텐츠 보호 차원에서 CDN 캐시 남아있는 과거 영상을 다운받는 것을 방지하기 위해 정해진 시간 이후에 들어온 요청은 캐시가 되어 있더라도 컨텐츠를 응답하지 않도록 설정해두는 것이 필요하다.

 

 

 

ⓓ 동영상 플레이어

 

미디어 서버에서 최종적으로 만든 HLS 형식은 모바일이라면 안드로이드, 아이폰 구분 없이 내장된 플레이어를 통해 문제없이 재생할 수 있다. 그리고 HLS 가 Apple에서 만든 방식인 만큼 맥 OS에서도 재생을 지원합니다.

 

그런데 Windows OS에서 HLS를 재생하려면 별도의 외부 플레이어가 필요하다. Chrome이나 Edge 같이 MSE (Media Source Extensions)를 지원하는 최신 브라우저라면 Javascript 로 구현된 플레이어를 사용할 수 있. 대표적으로 hls.js, video.js 등이 있습니다. => 아! 비디오 플레이어 하면 video.js 추천하는 이유가 있었구나

 

동영상 플레이어를 사용할 때 브라우저의 보안적 제약으로 재생이 불가능한 상황이 발생할 수 있다.

서비스 페이지의 도메인과 영상이 전송되는 도메인이 다르면 재생이 되지 않는다. (아... CORS)

이를 위해 전송 서버나 미디어 서버에서 적절한 크로스 도메인 설정을 해주어야 한다.

또한 HTTPS 페이지 내에서 HTTP 프로토콜로 전송되는 영상을 재생을 하려고 할 때도 마찬가지로 재생이 되지 않을 수 있으니 영상도 HTTPS 프로토콜로 전송하는 것이 필요합니다.

 

 

그 외 추가적인 정보들

kollus라는 국내 스트리밍 기술 업체가 정리를 잘해두었으니 스트리밍 서비스에 관심이 있다면 읽어보자.

 

blog.kollus.com/

Kollus Blog

다음 블로그에서 streaming server에 대한 정보를 잘 정리해주셨다

linuxism.ustd.ip.or.kr/category/Project/Streaming%20Server

'Project/Streaming Server' 카테고리의 글 목록