본문 바로가기
플랫폼 작업노트

CMAF의 현황, 효율화 아니면 또 다른 포맷이 될것인가?

by 친절한 재민 2019. 11. 26.

스트리밍기술에서 중요한 요소 중에 하나는 모든 대상 엔드 포인트에 안전하게 제공 할 수있는 단일 파일 세트를 가지는 것입니다. 이를 달성하는 데 가장 도움이되는 후보는 CMAF(Common Media Application Format)입니다. CMAF는 모든 고객의 문제를 아직 다 해결할 수 없지만 표준화를 통한 노력으로 많은 변화의 노력들이 이루어지고 있습니다. 

CMAF 가 무엇이죠?

CMAF는 ISO / IEC 23000-19로 공식화 된 세그먼트 미디어 전송을 위한 표준입니다. 특히 CMAF는 공통 암호화 (CENC)와 함께 ISO BMFF (ISO Base Media File Format) 컨테이너를 사용합니다. H.264, HEVC 및 기타 코덱 지원, WebVTT (Web Video Text Tracks Format) 및 IMSC-1 캡션을 지원합니다. DASH 및 HTTP 라이브 스트리밍 (HLS)과 달리 CMAF는 프레젠테이션 형식이 아닙니다. 여러 프레젠테이션 형식 및 DRM에 대한 매니페스트 파일과 함께 오디오 / 비디오 파일 집합을 포함 할 수있는 컨테이너 형식입니다.

CMAF의 현황, 효율화 아니면 또 다른 포맷이 될것인가?


CMAF 는 2018 년 10 월 로스앤젤레스에서 열린 WAVE Boot Camp 에서 제기된 문제를 해결하기 위해 고안되었습니다. 현재 모든 엔드 포인트에 적합합 스트리밍을 제공하려면 HLS, DASH, Smooth Streaming 및 HTTP Dynamic Streaming (HDS)의 네 가지 형식으로 제공되는 파일이 필요합니다. 

HLS 는 애플에서 시작되었고 DASH 는 많은 새로운 기기들에서 사용되는 MPEG 의 표준이며 Smooth 는 MS 기반의 서비스 HDS 는 Adobe 를 근간으로 하고 있습니다. 국내에서는 가장 보편적으로 HLS, DASH 를 사용하고 있고 서비스의 단순한 사용을 위해 HLS 를 사용하기도 합니다. 스트리밍 서비스를 쉽게 하기 위해서 Wowza 를 통해서 서비스하거나 플랫폼에서 제공하는 스트리밍 서비스를 이용하기 때문에 플랫폼에 비용을 지불하는 고객의 입장에서는 지나칠 수 있는 부분이지만 효율화를 위해서는 파편화된 스트리밍의 포맷을 통일하는 것이 이상적이다. 

초창기 스트리밍서비스는 트랜스코딩과 캐시를 활성화하기 위해 청크와 매니페스트를 스토리지에 배포하여 CDN을 통해 서비스하였다. 지금도 쉽게 스트리밍 서비스를 할 수 있는 방법이다. 그러나 위와 같은 4가지 포맷을 고려하면 4개의 파일세트와 스토리지를 낭비하게 된다. 그렇기 때문에 이를 통합하는 CMAF 표준을 사용하게 되면 하나의 비디오 오디오 파일세트를 통해 모든 엔드포인트의 서비스를 지원할 수 있게 된다. 무려 75%의 스토리지 절감효과를 가져다 준다.

참고한 기사의 원문은 다음 링크를 통해 확인할 수 있습니다. 

 

 

https://www.streamingmedia.com/Articles/Editorial/Featured-Articles/The-State-of-CMAF-The-Holy-Grail-or-Just-Another-Format-135142.aspx

 

The State of CMAF: The Holy Grail or Just Another Format?

It's all the buzz on the conference circuit, but deployment challenges mean CMAF hasn't taken over the streaming world yet. Here's why it's getting so much attention.

www.streamingmedia.com

CMAF 는 필수인가?

그러나 단순히 스토리지 절감효과를 본다면 다른 기술을 사용할 수도 있다. just-in-time (JIT) 패키저는 하나의 MP4 를 사용하여 실시간으로 타겟에 맞는 매니페스트를 패키징하는 기술이다. 이를 통해 스토리지 절감에 대한 부분을 유도할 수 있다. 실시간으로 패키징 처리를 하는 것은 정적인 파일을 유지하는 것보다 10% 정도의 CPU 사용률이 고려되지만 대안은 있다. 서버에서 뿐만 아니라 플레이어 단에서도 HLS 를  DASH 로 변환하는 라이브러리가 있다. 이런 대안들이 있기 때문에 CMAF 가 아직 필수적인 대안으로 고려되는 추세는 아니다.

DRM  에 대한 부분도 고려가 필요합니다. 애플의 페어플레이는 CBCS 형식의 DRM 을 사용하지만 Google 과 MS 는 CTR 형태를 사용합니다. CBCS 를 지원하기 위해서는 하드웨어가 DRM 을 지원하는 기반이 되어야 하지만 업그레이드하지 않은 구형 모델들은 지원에 대해 알 수가 없습니다. 그럼으로 콘텐츠를 서비스하는 입장에서는 쉽게 DRM 을 표준화하기 어렵습니다. 시간이 지나면서 구형 기기들의 호환성을 무시하게 되겠지만 아직까지는 고려대상입니다. 뿐만 아니라 MS 의 IE 브라우저에서도 호환되지 않는 DRM 이슈들이 있습니다. 이를 고려할 때에 CMAF 의 DRM 방식을 적용하기 어려운 부분이 있습니다.

CMAF 는 아직 또 하나의 표준으로 추가적인 가공이 필요한 영역으로 취급되고 있습니다. CDN 에서 다양한 포맷을 취급한다는 것은 그만큼 CDN 의 캐싱 용량과 효율을 저하하게 만듭니다. 이것은 JIT 을 통해 서버에서 매니페스트의 변환이 이루어진다고 해도 CDN 의 엣지에 캐싱되는 형태가 다른 형상이기 때문에 피할 수 없습니다. CDN 을 사용하는 트래픽의 비용적인 측면에서 손해를 보지는 않겠지만 CDN 의 전반적인 효율은 분명 저하되고 그로 인해 리버퍼링의 확률은 올라가게 될 것입니다.

연구에 따르면 서비스에서 사용하는 84% 의 플레이어가 CMAF 를 지원할 때에 CDN 의 비용효율적인 운영이 이루어진다고 소개되고 있습니다. 어찌보면 CMAF 는 당장 콘텐츠 사업자보다 CDN 의 영역에서 더 필요한 변화일지도 모르겠습니다. CMAF 는 5년내에 시장에 안착될 것이라고 전망이 되고 있는만큼 그 효율성과 방향을 주목할 필요가 있습니다.

 

 

댓글