'cmaf'에 해당되는 글 1건

이글은 CMAF에 대해서 공부하다가 Akamai 커뮤니티에 올라온

(https://community.akamai.com/customers/s/article/CMAF-What-it-is-and-why-it-may-change-your-OTT-future?language=en_US) 글을 번역한 글입니다.

제 생각은 전혀 들어가있지 않고 공부차 쓴글임을 참고해주세요.

Worldwide Developers Conference에서 HLS에 fragmented MP4 (fMP4) 지원을 추가 할 것이라는 애플의 6월 15일 발표는 온라인 비디오 스트리밍의 구조를 간소화하는 중요한 의미를 가집니다. fMP4는 새로운 CMAF (Common Media Application Format)의 전신이며 fMP4를 지원하려는 Apple의 계획은 OTT 서비스를 제공받는 모든 장치와 제공하는 업체들에 대한 재생 지원가능성을 높입니다. 궁극적인 목표는 비디오를 온라인으로 전송할 때의 복잡성을 줄이는 것입니다.

OTT 업체들은는 RTMP, MMS 및 RTP와 같은 독점적 인 미디어 프로토콜을 사용하는 것으로부터 HTTP/S를 사용하여 시청자에게 adaptive한 콘텐츠를 제공하는 방향으로 지난 5 년 동안 큰 변화가있었습니다. adaptive 세그먼트화 형식에는 단편화된 청크 방식을 지원하는 HLS, Smooth, HDS 및 MPEG DASH등이 있습니다. Smooth와 HDS의 사용이 중단되고 DASH로 교체되는 경우에도 대부분의 컨텐츠 배포자는 HLS에 하나, DASH에 또 하나의 컨텐츠를 작성해야합니다.

HLS는 TS (전송 스트림) 파일 컨테이너의 사용을 지정하고,  DASH는 TS를 허용하지만 실제로는 ISO 기본 미디어 파일 형식(ISOBMFF)을 대부분 사용합니다. 앞서 언급 한 fragmented mp4로 알려진 변형입니다. 결과적으로 HLS 및 DASH 잠재 고객에게 도달하려는 콘텐츠 배포자는 동일한 오디오 및 비디오 데이터를 두 번 인코딩하고 저장해야합니다. HLS를 위해 TS 컨테이너에 랩핑 된 다음 다시 ISOBMFF로 래핑됩니다. 이 동일한 파일은 동일한 컨텐츠를 나타내지만 패키징 비용이 두 배가됩니다. 원래에 저장용량의 두 배를 차지하며 Akamai 의 Edge서버들의 캐시 운용효율이 떨어집니다.

캐시 효율성 문제를 극복하기 위해 시장은 Edge또는 스트리밍 중간 계층에서 TS 및 ISO 세그먼트 (HDS 용)의 복잡한 합성을 필요로하는 수많은 솔루션을 출시했습니다. 콘텐츠를 제공하기 전에 콘텐츠를 제작해야하는 이러한 서버는 단순히 전달할 수있는 서버보다 처리량이 낮을 수밖에 없습니다. 따라서 파일 컨테이너 다양성은 서버의 처리량을 제한 할뿐만 아니라 고객의 컨텐츠 준비, workflow 관리 및 배달 비용을 높이게 됩니다.  또 어떤경우의 고객은 여러 버전의 컨텐츠를 저장하게 되어 저장 용량을 추가로 사용할 수도 있습니다.

2015 년 중반에 Microsoft 와 Apple이 모여 새로운 미디어 파일 포맷을 통해 이 비효율을 종식시킬 계획을 세웠습니다. 이 포맷은 당시 Common Media File Format으로 불렸지 만 지금은 CMAF (Common Media Application Format)로 불리웁니다. Microsoft와 Apple은 Akamai와 많은 파트너와 협력하여 제안을 반복했습니다. 2016 년 2월에 회사 그룹은 표준화 기구인 MPEG에 공동 제출을 준비했습니다.

CMAF는 미디어 산업에 흥미를 줄 많은 속성을 가지고 있습니다.

 - ISOBMFF, fMP4 컨테이너, 특히 ISO / IEC 14496-12:201  전송 스트림은 방송 및 케이블 산업의 목적에 부합하여 지속적인 데이터 흐름을 제공하지만 분할 된 미디어 전달 및 전환에 적합하지 않으므로 fmp4보다 높은 오버 헤드 / 페이로드 비율이 발생합니다. fmp4는 DASH, Smooth 및 HDS에서 이미 사용되는 가벼운 추가 기능을 위해 확장 가능하며 인코딩, 조작, 디버깅 및 분석을위한 강력한 도구 세트가있는 ISO 표준입니다.

 - 공통 암호화 (CENC) - ISO / IEC 23001-7 : 2016 - AES-128 비트 암호화를 사용하여 미디어 컨텐트 페이로드를 암호화 한 다음 동시에 여러DRM 시스템을 사용하여 컨텐트를 해독할 수 있도록 헤더 정보를 제공하는 표준 방법입니다.

 - 기준 상호 운용성을 보장하여 AVC (ISO / IEC 14496-10), AAC (ISO / IEC 14496-3) 및 HEVC (ISO / IEC 23008-2) 코덱의 MPEG 코덱 제품군을 지원하고, 다른 코덱 (예 : VP9 또는 멀티 채널 오디오) 신호를 보낼 수 있습니다.

 - 현재 WebVTT (http://www.w3.org/TR/webvtt1)와 IMSC-1 (http://www.w3.org/TR/ttml-imsc1)의 두 가지 유형의 자막 형식을 허용합니다.

 - 세그먼트는 키 프레임으로 시작해야하며 비트 전송률에 걸쳐 정확한 세그먼트 맞춤이 있어야합니다. 이렇게하면 플레이어의 비트 전송률을 쉽게 전환 할 수 있습니다.

 - 독립적인 (다중화되지 않은) 오디오 및 비디오 세그먼트가 필요합니다.

 - 저 레이턴시 모드가 제공되므로 지상 및 위성 방송 분배를위한 임계치 이하의 OTT 라이브 스트림 대기 시간을 줄일 수 있습니다.

 - HLS 재생 목록 (.m3u8)과 DASH 매니페스트 (.mpd)에서 모두 참조하도록 설계되었습니다.

CMAF는 DASH가 이미 현재 사용하고있는 파일 컨테이너와 매우 유사한 구조를 가지고있으므로 DASH 관점에서볼땐 CMAF를 채택 할 경우 Encode나 workflow 또는 플레이어를 거의 변경하지 않아도됩니다. 그러나 Apple 및 HLS 커뮤니티의 경우 새로운 유형의 컨테이너를 구문 분석해야합니다. iOS10, macOS 및 tvOS에서 HLS에서 fMP4를 지원한다는 Apple의 발표가 있었으니 이로인해 CMAF는 통합 형식으로 자리 매김 할 것입니다.

 CMAF의 출현은 OTT 전달을위한 TS 컨테이너 방식이 종식됨을 알립니다. TS가 장기간 지속될 수 있었지만 한 번 인코딩하고, 한 번 포장하고, 한 번 캐싱하고, 한 가지 유형의 플레이어를 만드는 장점은 너무 매력적입니다.

그러나 장점만 있는것은 아닙니다. Apple, Android 및 Microsoft 운영 체제와 장치가 CMAF를 신속하게 지원하더라도 현장 기반 업그레이드가 불가능한 많은 기존 장치가있어 TS 기반 HLS가 한동안은 필요합니다. 또한 공통 암호화는 생각만큼 일반적이지 않습니다. 실제로 CBC 대 CTR 사양에 의해 허용되는 여러 암호화 블록 모드가 있습니다. CMAF 초안은이 두 가지를 계속 지원하지만 모든 장치에 대한 단일 컨텐트의 전망은 아직 불투명합니다. CMAF는 또한 HLS m3u8 매니페스트 및 DASH .mpd 매니페스트가 모두 생성되어야하므로 매니페스트 조각화 문제를 아직은 해결하지 못합니다.

이러한 문제가 있지만 CMAF는 수년간 업계가 조화롭고 하나된 미래로 나아가는 데있어 가장 큰 발전을 거두었습니다. 아마도 시장은 CMAF를 선택할 것이고(코덱, 캡션, 암호화 모드 및 프리젠 테이션 형식등으로 고려해) CMAF를 사실상의 OTT 미디어 표준으로 빠르게 자리 매김 할 것으로 기대할 수 있습니다.

Akamai는 인스턴스화를 통해 CMAF에 전념했으며 CMAF 지원이 Media Services On Demand 및 Media Services Live 제품의 일류임을 보장하기 위해 적극적으로 노력하고 있습니다.