라이브 스트리밍(Live Streaming ) 이해하기

스트리밍(Streaming)   

인터넷에서 음성이나 영상, 애니메이션 등의 파일을 다운받는 기존 방식과 달리, 실시간으로 영상을 재생하는 기법.

전송되는 데이터가 마치 물이 흐르는 것처럼 처리된다고 해서 스트리밍(streaming)이라 부른다.

선택된 콘텐츠파일은 하드디스크 드라이브에 다운 받아 재생하는 절차 없이, 실시간 시청 분량만큼을 조금씩 흘려준다.

동영상 파일 등은 용량이 커서 한꺼번에 파일 전체를 보내는 것은 시간이 많이 걸리기 때문에 파일의 일부를 조금씩 실시간으로 전송하여 주는 것이 스트리밍이다.

 

<< 라이브 스트리밍 구조 >> 영상 -> 라이브 인코더 -> 미디어 서버 -> 전송 서버 -> 동영상 플레이어

 

미디어 서버 

몇kb 정도의 작은 용량의 문서인 HTML(Hyper Text Markup Language)을 전송하는 서버를 웹 서버라 한다.

보통 동영상은 일반적으로 수십 kb에서 몇 백 kb까지 비교적 용량이 큰 용량의 파일이다.

일반적인 웹 서버는 이러한 대용량의 파일 전송을 목적으로 하지 않기에, 동영상 파일을 전송하는 것을 목적으로 하는 미디어 서버가 따로 필요하다.

미디어 서버는 동영상 서비스를 위해 필요한 서버라고 생각하면 된다. 보통 전송 서버의 역할도 함께 한다.

 

- Nginx-rtmp (오픈 소스)

   nginx(Web Server)의 모듈로 동작하는 미디어 스트리밍 서버이다.

   RTMP 소스를 Pull 혹은 Push 방식으로 입력받을 수 있고 RTMP/HLS/MPEG-DASH 출력을 지원한다.

   여기에 ffmpeg 을 연동하면 트랜스코딩을 비롯하여 기타 다양한 기능들을 구현할 수 있다.

 

참고 :

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

 

Latency의 문제 

• Encoding & packaging - 해상도, 전송 비트레이트, 압축 표준 선택이 중요하고, 전송 프로토콜에 따라 패키징하는 시간과 주기등을 결정해야 한다.

• Uploading (First mile upload) - 녹화 후 인코딩된 패킷을 Ingestion단으로 전송을 해야 한다. 이 부분이 불안정할 경우 방송 중단 및 방송사고로 이어질 수 있는 중요한 부분이다. 현재 산업계에서 많이 사용하는 프로토콜은 RTMP, RTSP, RTP, SRT등을 사용한다. 최근에는 이 단계의 낮은 latency 및 안정적인 연결을 위한 UDP기반의 프로토콜들에 많은 관심이 쏠리고 있다.

• Ingestion server - 통상 산업계에서 CDN에서 직접 접속하기전에 Wowza, Red5 pro같은 스트리밍서버를 중간 설치하여 녹화, 알람, 불법 콘텐츠 모니터링등에 이용한다. 이 단계에서 캐쉬를 너무 크게 잡거나  latency 조정을 잘못할 경우 지연시간이 길어 질 수 밖에 없다.

• Cache (or CDN) - 최근에는 치열한 CDN가격으로 고맙게도 CDN 비용이 많이 낮아졌다. 그러나, 각 CDN업체들도 실시간 비디오 스트리밍에 난제라 latency를 줄이기 위하여 많은 노력을 하고 있다. 특히 CDN은 캐쉬(Cache)기능을 하다 보니 latency에 가장 민감할 수 밖에 없고, 서비스가 대규모가 될 경우 캐쉬의 효율적인 운영을 위하여 쉐도우(shadow)라는 2중 캐쉬를 사용한다. 이경우 latency는 더 길어질 수 밖에 없다. CDN 사업자를 선정할 때는 서비스 지역과 가격 및 안정성을 고려하여 선정하는 것이 좋다. CDN사업자를 잘못 선정하여 큰 라이브 이벤트를 망치는 경우도 종종 목격했다.

• Last mile delivery - 인터넷으로 전송하는 단계이며 공공망이라 통제 가능한 부분이 사실상 없다. 하지만 실시간 Adaptive Streaming, 적절한 프로토콜 선정(HLS, RTMP, MPEG-DASH, SDP 등)을 적극 고려하는 것이 좋다.

• Media player buffer - 미디어 플레이어의 버퍼링을 얼마큼 해야하는지는 결정은 항상 엔지니어들의 머리를 가장 아프게 하는 난제 중 난제이다. 많은 회사들이 직관적으로 최대한 짧게 잡으려고 한다.  최대한 짧게 잡게 되면 그 만큼 재생 중간에 버퍼링이 발생할 확률이 높아진다. 특히, 라디오 방송이나 음악 방송 같은 경우 중간에 버퍼링이 발생하면 치명적이다.  버퍼링에 대한 절대적이고 완벽한 답은 없기 때문에 서비스의 특성, 콘텐츠의 특성, 사용자들의 성향에 따라 정량화된 데이터를 기반으로 튜닝작업이 많이 필요하다. 

참고 : https://www.popit.kr/%EB%9D%BC%EC%9D%B4%EB%B8%8C-%EB%B9%84%EB%94%94%EC%98%A4-%EC%84%9C%EB%B9%84%EC%8A%A4-%EA%B5%AC%EC%B6%95%EC%9D%84-%EC%9C%84%ED%95%9C-%EB%85%B8%ED%95%98%EC%9A%B0-1%ED%9A%8C/