스트리밍 프로토콜 이해하기(feat.네이버 V라이브)

 

스트리밍 프로토콜에 대해 간단히 이야기 하자면,  한 장치에서 다른 장치로 '콘텐츠'를 전송하는 특정 방법을 의미한다.

웹 프로토콜 HTTP 와 같은 개념으로 '영상 콘텐츠'를 서비스하는데에도 규약(프로토콜)이 있다. 

이때 중요한 것은, 서버(콘텐츠를 제공) 와 클라이언트(콘텐츠를 소비) 측 모두 해당 규약을 지원하는 PC여야한다. 

예를 들어 서버는 MPEG-DASH 로 스트림을 하고 있는 반면 클라이언트 측이 MPEG-DASH를 지원하지 않으면 안된다. 따라서 스트리밍 프로토콜의 규격화를 해야만 이런 불편함이 해소될 것이다. 

 

대표적으로는 아래와 같은 프로토콜들이 있다. 

• MPEG-DASH   : 적응형비트적용률(ABR)사용, HTTP 웹 서버를 사용, RTP 같은 기존 스트리밍 구현보다 기술적 어려움 적음.
• Apple HLS : 애플 사의 실시간 스트리밍 서비스에 최적화된 프로토콜, 오늘날 가장 많이쓰이고 위와같이 HTTP,ABR 사용. 
• RTP/RTCP : IETF 표준, 별도의 스트리밍 서버가 필요, UDP 프로토콜.
• Microsoft Smooth Streaming : playready DRM(저작권 방지) 지원, 별도의 Silverlight 플러그인 프레임워크에서만 배포가능.
• Flash / RTMP: Adobe 사의 프로토콜. 비쌈. 요즘은 많이 안쓴다고함.

 

 

과거에는 영상을 전체 파일 다운로드를 해야만 플레이가 가능했으나, 애플에서 선보인 'Progressive Download' 기법을 사용하면 점진적으로 비디오를 다운로드받고, 따라서 송신 측 네트워크 대역폭이 수신 측 비트 레이트보다 크다면 끊김없이 영상을 재생시킬 수 있다. 가장 뒤에 있던 영상 메타데이터(플레이를 위해 반드시 필요한 요소들)가 가장 앞으로 오게되어 이 기술이 가능해졌다고 한다. 또한 HTTP 웹서버를 사용가능하고 CDN 인프라도 활용가능하다는 장점이 있으나, 단점으로는 대역폭 활용의 문제점이 있다. 그리고 라이브 스트리밍이 불가하다는 매우 큰 허점을 가지고 있다.  Youtube도 2010년대 초엔 이 기술을 채택했으나, 현재는 거의 대부분의 프로토콜들이  Adaptive Streaming(사용자의 네트워크, CPU 등의 상태를 모니터링하여 상황에 최적화된 화질을 전송해주는 방법)를 지원하는 방식으로 바뀌었다.

또 한가지의 메리트는 시청 중이던 현재 콘텐츠 전체를 굳이 다운로드 받지않아도 다음 영상을 시청해도 되어 자원을 아낄 수 있다. 

 

 

* 네이버 V Live 스펙을 살펴보자.

• 

프로토콜을 살펴보면, HLS, MPEG-DASH, RTMP(동기화 streaming) 등의 프로토콜을 채택해서 사용하는 것 같다. 

다음으론 'Codecs'라는게 있는데, 여기서 코덱(Codec)이란 컴프레져/디컴프레져(Compressor/Decompressor),코더/디코더(Coder/Decoder) 등으로 해석할 수 있다.  동영상이나 소리 등을 인코딩 또는 디코딩 할 수 있는 하드웨어나 소프트웨어를 의미하는데, 사용시 장점은 저장 공간을 절약하고 처리 시간을 향상 시킨다는 점이다. 몇 초 동안 해당 프레임의 변화가 거의 없다면 이런 것들을 감지하여 생략하고 크기를 줄여주는 알고리즘을 기반하여 스트리밍에선 빠질 수 없는 기술 스펙 중 하나이다. mpeg-2,h264,h265,Prores 등이 있는데 여기선 h.264를 사용하는걸 알 수 있다. (영상의경우) 

Bitrate는 지원 해상도, 대역폭 등 과 관련있는 것이고 보다시피 위에서 이야기했던 HLS Apdaptive 방식을 지원한다. 

 

현재 대기업이 어떤 기술 스펙을 채택하는지 보면 동향을 살피기에 좋고 스트리밍 기술에 대한 이해를 하는데 있어 전반적인 틀을 잡아 주기 때문에 활용을 많이 하는 편이다.