유로 2024 기간에 1,150만이 넘는 영국 가정이 BT의 광대역망을 통해 영국 구성국 대표팀 경기를 최소 한 경기 이상 스트리밍으로 시청했습니다. BT는 이후 BBC와 ITV에서 오는 트래픽이 평소 주간 물량의 30배 이상으로 치솟았고, 두 방송사가 잠시 동안 Netflix, Facebook, YouTube를 제치고 자사 망에서 가장 큰 콘텐츠 소스가 되었다고 밝혔습니다. 대회에서 가장 높았던 단일 트래픽 정점은 콜 파머가 결승에서 동점골을 넣은 순간에 찾아왔습니다.
그 규모의 다음 시험은 불과 한 달 앞으로 다가왔습니다. 2026 FIFA 월드컵은 6월에 개막하며 미국, 캐나다, 멕시코에서 열립니다. 그 생중계 시청자는 같은 경기를 가정마다 별도의 스트림으로 보내도록 결코 설계되지 않은, 동일한 유선망과 모바일망에 그대로 내려앉게 됩니다.
그런 정점은 망이 흡수하기 어렵고, 그 이유는 구조적입니다. 오늘날 널리 쓰이는 모든 스트리밍 형식은 HLS와 DASH를 포함해 모두 유니캐스트 위에 세워져 있습니다. 시청자는 저마다 자기 세션을 열고 각 세그먼트의 자기 사본을 받아옵니다. 같은 채널의 시청자가 열 명이면 망을 가로지르는 동일한 스트림이 열 개입니다. 백만 명이면 동일한 스트림이 백만 개입니다. 콘텐츠는 모두에게 같은데, 망은 마치 사본 하나하나가 서로 다른 것인 양 그것을 실어 나릅니다.
보통 mABR로 줄여 부르는 Multicast ABR은 그 문제에 대한 스트리밍 업계의 주된 답입니다. 새로운 것이 아니고, 이미 표준화되어 있으며, 소수의 대형 통신사업자가 이미 상용 환경에서 운영하고 있습니다. 모든 것의 해결책으로 여기기 전에 이해해 둘 만한 실제적인 한계도 있습니다. 이 글은 mABR이 무엇인지, 어떻게 동작하는지, 실제로 무엇을 절약하는지, 어디서 부족한지, 누가 도입했는지, 그리고 GPAC와 Motion Spell이 이끄는 오픈 소스 작업이 왜 이 기술의 미래에 중요한지를 다룹니다.
Multicast ABR이란 무엇인가
Multicast ABR은 평범한 적응형 비트레이트 콘텐츠, 즉 일반 플레이어가 이미 기대하는 것과 같은 HLS 또는 DASH 세그먼트를, 유니캐스트가 아니라 IP 멀티캐스트로 전달합니다. 사업자의 관리망에서는 채널이 망을 통해 한 번만 멀티캐스트 스트림으로 보내지고, 얼마든지 많은 가정이 거기에 참여할 수 있습니다. 표준 유니캐스트 HTTP로 되돌리는 변환은 가정 안이나 그 근처에서 일어나므로, 기기와 그 플레이어는 무언가 바뀌었다는 것을 결코 알지 못합니다. 플레이어의 관점에서는 여전히 가까운 CDN 엣지처럼 보이는 것에 HTTP로 세그먼트를 요청하고 있을 뿐입니다.
핵심 발상은 단순합니다. 유니캐스트에서는 시청자 한 명이 스트림 하나를 뜻합니다. 멀티캐스트에서는 몇 가정이 보고 있든 채널 하나가 스트림 하나를 뜻합니다.
정확히 짚어 둘 점이 두 가지 있습니다. 첫째, mABR은 혼합형입니다. 멀티캐스트가 전달의 대부분을 맡고, 유니캐스트는 복구 경로이자 대체 경로로 회로 안에 남습니다. 둘째, mABR은 생중계와 선형 콘텐츠를 위해 설계되었습니다. Streaming Video Technology Alliance가 펴낸 기술 브리프, 즉 그 multicast ABR 문서가 Ericsson 엔지니어의 주도로 Comcast를 비롯한 사업자들의 기고를 받아 만들어진 업계 단체의 문서는 분명하게 말합니다. 주문형 비디오는 여전히 CDN에서 온다고요. mABR이 제값을 하는 것은 많은 사람이 같은 것을 같은 시간에 볼 때, 곧 생중계 스포츠와 생중계 뉴스입니다.
멀티캐스트 영상은 새롭지 않다, 특히 프랑스에서는
분명히 해 둘 가치가 있습니다. 텔레비전의 멀티캐스트 전달은 수십 년의 역사가 있고, 프랑스는 그것이 대규모로 작동하는 가장 좋은 사례 가운데 하나입니다. 2000년대 초, Free가 Freebox를 내놓았을 때, 이 사업자는 IP 멀티캐스트를 통한 텔레비전 전달을 자사의 분리 개방된 DSL 망에 직접 집어넣었습니다. 당시 기존 사업자의 DSLAM은 제공하지 않던 것이었습니다. 2008년에 Free는 세계 최대 IPTV 사업자 1위에 올라 있었습니다. 멀티캐스트가 셈이 맞은 이유였습니다. 각 채널의 사본은, 그것을 보는 Freebox 가정이 얼마나 많든, 망을 한 줄기만 흘렀습니다.
Free는 그 멀티캐스트 피드를 Multiposte라는 서비스를 통해 가입자에게 직접 노출하기도 했습니다. 이를 통해 텔레비전과 나란히 컴퓨터에서 Freebox TV 채널을, VLC에서 채널 재생목록을 열어 볼 수 있었습니다. 스트림은 단순한 IP 멀티캐스트로, Freebox를 거쳐 운반되고 IGMP로 참여하며, 셋톱박스는 전혀 관여하지 않았습니다. 프랑스 광대역 사용자의 한 세대가 사실상 PC에서 멀티캐스트 텔레비전 수신기를 돌리고 있었던 셈입니다.
도구 역시 결코 별난 것이 아니었습니다. Multiposte가 의지하던 바로 그 플레이어인 VLC는, 유니캐스트 스트림을 입력으로 받아 하나의 스트림 출력 설정으로 UDP나 RTP 위의 멀티캐스트 주소로 다시 내보낼 수 있습니다. 유니캐스트 피드 하나를 멀티캐스트 피드로 바꾸는 것은, 그 자체로 평범하고 오래전에 풀린 문제입니다.
그렇다면 멀티캐스트가 오래되었고 도구가 어디에나 있다면, Multicast ABR에 정말로 새로운 것은 무엇일까요? 고전적인 멀티캐스트 IPTV, 곧 Freebox 모델은, 고정된 연속 전송 스트림을 사업자 자신의 셋톱박스로 실어 날랐습니다. mABR은 대신 현대적인 적응형 비트레이트 콘텐츠, 즉 모든 휴대전화, 태블릿, 스마트 TV, 스트리밍 스틱이 이미 말하는 HLS와 DASH 세그먼트를 실어 나르며, 그것을 하나의 독점 박스가 아니라 파편화된 기기 생태계 전체를 겨냥합니다. mABR의 어려운 부분은 멀티캐스트 자체가 아닙니다. 세그먼트화되고 적응형이며 여러 기기에 걸친 스트리밍을 위해 멀티캐스트를 하는 것, 그것이 요구하는 게이트웨이와 랑데부와 복구의 기계 장치까지 갖춰서 하는 것이 어려운 부분입니다.
mABR은 어떻게 동작하는가
DVB Project가 개발하고 ETSI가 TS 103 769로 펴낸 DVB-MABR 명세는, 이름이 붙은 작은 기능 묶음으로 구성된 참조 아키텍처를 정의합니다.
- 멀티캐스트 서버. CDN 오리진이나 엣지에서 표준 ABR 콘텐츠를 받아들여, 각 세그먼트를 하나 이상의 멀티캐스트 전송 객체에 대응시키고, IP 멀티캐스트로 송출합니다. 사업자는 설정 API를 통해 어떤 스트림을 잡아 어떻게 보낼지 알려 줍니다.
- 멀티캐스트 게이트웨이. 멀티캐스트 스트림을 받아 로컬 플레이어를 위해 평범한 HTTP로 다시 변환합니다. 작은 로컬 캐시이자 HTTP 프록시처럼 동작합니다.
- 멀티캐스트 랑데부 서비스. 플레이어의 첫 요청을 HTTP 리디렉션으로, 사업자의 서비스 플랜과 비즈니스 규칙에 따라 알맞은 게이트웨이로 보냅니다.
- 유니캐스트 복구. 멀티캐스트 패킷이 손실되면, 게이트웨이는 빠진 조각을 유니캐스트로, 보통 HTTP 바이트 범위 요청을 써서 채워 와 재생이 끊기지 않게 합니다.
게이트웨이가 동작하는 위치
명세는 멀티캐스트 게이트웨이가 어디에 자리하는지에 대해 의도적으로 유연합니다. 사업자의 망 안, 가정용 게이트웨이나 라우터, 광 회선 종단 장치, 또는 셋톱박스 안에서 바로 동작할 수 있습니다. 게이트웨이와 플레이어가 같은 기기에 있을 때, DVB 명세는 둘 사이의 인터페이스가 단순한 로컬 API여도 된다고 말합니다. SVTA 브리프는 같은 구성 요소를 멀티캐스트 클라이언트라 부르며, 셋톱박스, 가정용 게이트웨이, ONT, 또는 사업자의 엣지 캐시 안에 배치할 수 있는 것으로 설명했습니다. 마지막 선택지는 그 자체로 유용합니다. CDN 엣지에 끼워 넣은 mABR 클라이언트는 멀티캐스트로 캐시를 채우고 오리진으로 되돌아가는 요청을 줄일 수 있습니다.
전송 프로토콜
그 아래에서 mABR은 단방향 멀티캐스트를 위해 만들어진 파일 전달 프로토콜을 씁니다. DVB-MABR은 그중 둘을 필수로 합니다. FLUTE(File Delivery over Unidirectional Transport, RFC 6726)는 3GPP의 세계에서 왔습니다. ROUTE(Real-Time Object Delivery over Unidirectional Transport, RFC 9223)는 ATSC 3.0에서 왔습니다. 2023년 명세 개정은 선택적 프로토콜 둘을 더했습니다. NORM(NACK-Oriented Reliable Multicast, RFC 5740)과 MSYNC입니다. 모두 UDP 위에서 동작하며, 전방 오류 정정과 함께 세그먼트화된 콘텐츠를 실어 나릅니다.
유용한 성질이 하나 있습니다. mABR은 포맷, 코덱, DRM에 구애받지 않습니다. HLS든 DASH든, MPEG-TS든 CMAF든, 암호화되었든 아니든 실어 나르고, 아무것도 다시 인코딩하지 않습니다. 바이트가 어떻게 이동하는지를 바꿀 뿐, 그것이 무엇인지는 바꾸지 않습니다.
Multicast ABR의 장점
규모 확장, 바로 그것이 핵심
mABR을 지지하는 핵심 논거는, 인기 있는 생중계 채널의 망 비용이 시청자와 함께 늘어나기를 멈춘다는 것입니다. SVTA 기술 브리프는 이를 두 가지 액세스 망 사례로 보여 줍니다. DOCSIS 케이블 망에서는 유니캐스트 ABR에 필요한 채널 수가 시청자가 합류하면서 직선으로 늘지만, mABR에서는 잠깐 올라갔다가 시청자들이 같은 멀티캐스트 스트림을 공유하므로 평탄해집니다. GPON 광섬유 망에 대해 브리프는 이렇게 추정합니다. 500개의 선형 채널을 운영하는 사업자에서 시청자의 80퍼센트가 편성의 10퍼센트를 본다면, 코어 망의 대역폭 절감은 PON당 32가입자에서 약 50퍼센트에 이르고, 시청자당 대역폭 요구량은 시청자가 수만에 이르는 순간 유니캐스트 수치의 3퍼센트 아래로 떨어진다고요. 브리프는 직설적으로 요약합니다. mABR은 극도로 인기 있는 생중계 행사에 대해 망 가장자리의 대역폭 요구량을 페타바이트 규모에서 메가바이트 규모로 낮출 수 있다고요.
모델링된 추정치가 아니라 사업자에게서 곧바로 나온 수치가 하나 있습니다. 2025년 3월, BT Group은 MAUD, 곧 자사가 Multicast-Assisted Unicast Delivery라 부르는 것의 첫 시험 성공을 보고했습니다. 이는 BBC Two의 생중계 콘텐츠를 상용망의 EE 셋톱박스로 전달하는 것이었습니다. 피크 시간대에 이 시험은 트래픽의 60퍼센트 이상을 유니캐스트에서 멀티캐스트로 전환했습니다.
경험 품질
mABR은 최선노력형 서비스가 아니라 관리형 서비스로 제공됩니다. SVTA 브리프는 이것이 재생 지터를 완화한다고 지적합니다. 사업자가 오리진과 시청자 사이의 열린 인터넷에 의지하는 대신 경로를 통제하기 때문입니다. 생중계 결승에서는, 보고 있는 모두에게 고른 전달이 순수한 대역폭 절감만큼이나 중요합니다.
이미 있는 것을 재사용한다
SVTA 브리프는 mABR의 인프라 비용이 다른 확장 선택지보다 낮을 수 있다고 강조합니다. 관련된 라우터와 망 요소 대부분이 이미 사업자의 망에 배치되어 있기 때문입니다. mABR은 또한 CDN 캐싱을 대체하는 것이 아니라 보완하며, 엣지 캐시를 채우는 콘텐츠 소스로 작동할 수 있습니다.
Multicast ABR의 단점
늘어나는 지연
멀티캐스트 게이트웨이는 세그먼트를 제공할 수 있게 되기 전에 그것을 받아 다시 조립해야 하며, 이는 원본 ABR 스트림 위에 지연을 더합니다. Techne Digitale가 펴낸 한 기술 분석은, mABR이 전형적인 OTT 전달 위에 약 두 세그먼트의 지연을 더해, 종단 간 수치를 약 8초에서 약 12초로 밀어 올린다고 추정합니다. SVTA 브리프는, 더 짧은 세그먼트 길이와 CMAF 청크 전송을 포함한 세심한 설계로 mABR을 순수 유니캐스트 ABR과 견줄 만한 수준, 혹은 그보다 낮은 수준으로 유지할 수 있다고 주장합니다. 어느 쪽이든 지연은 생중계 스포츠에서 실제적인 고려 사항입니다. 동작이 자기 화면에 닿기 전에 이웃의 반응을 듣는 시청자는 그것을 알아챌 테니까요.
클라이언트 생태계 문제
SVTA 브리프는 배치된 클라이언트 생태계의 부재를 mABR의 더 넓은 채택을 가로막는 가장 큰 장벽이라고 부릅니다. 오래된 가정용 게이트웨이와 ONT는 멀티캐스트 클라이언트를 돌릴 CPU와 메모리가 없는 경우가 많습니다. 더 새로운 하드웨어는 할 수 있지만, 기기 제조사는 그것을 쓸 인프라가 없는 한 멀티캐스트 클라이언트 소프트웨어를 만들고 시험하고 유지할 이유가 거의 없고, 사업자는 기기가 그것을 쓸 수 없는 한 인프라를 배치할 이유가 거의 없습니다. 2023년 초 CSI Magazine 행사에서 BT의 TV 아키텍트 사이먼 존스는, BT가 10년 넘게 멀티캐스트 텔레비전을 운영해 왔지만 그것을 텔레비전에만 전달하고 연결된 기기에는 전달하지 않았으며, BT가 기존 인프라로는 월드컵 같은 것을 전달할 수 없을 것이라고 언급했습니다. DAZN의 영상 재생 및 전달 아키텍트 밥 해넌트는 같은 논의에서 시장이 아직 "정말로 미성숙하다"고 말했습니다. 두 사람 모두 Google과 Apple 같은 기기 제조사의 지원 부족을 가장 큰 걸림돌로 꼽았습니다.
관리망에서만 동작한다
공공 인터넷에는 멀티캐스트가 없습니다. mABR은 단일 사업자의 관리망 안에서, 사업자가 운영하는 멀티캐스트 서버와 사업자가 통제하는 게이트웨이 사이에서 동작합니다. Netflix 같은 순수 OTT 서비스는 mABR을 종단 간으로 혼자 배치할 수 없습니다. ISP에 지원을 요청할 수는 있지만, 각 ISP에 개별적으로 의존합니다.
파편화
mABR은 망마다 국지적이기 때문에, 그것이 동작하는 ISP만큼만 효과적입니다. 어떤 시청자층을 담당하는 ISP의 절반이 그것을 지원하더라도, 나머지 절반의 시청자는 여전히 유니캐스트 경험과 같은 혼잡을 겪습니다. 유니캐스트 CDN과 달리, 단일 기업이 시청자 전체에게 종단 간 mABR 경험을 전달할 수는 없습니다.
현대 망에서는 문제가 줄어들고 있을지도 모른다
Techne Digitale의 분석은, 1대 64 분기로도 가정마다 초당 수십 메가비트를 남기는 현대 GPON 광섬유에서는, mABR이 겨냥해 설계된 마지막 마일의 대역폭 병목이 아예 존재하지 않을 수도 있으며, mABR이 가장 의미 있는 곳은 더 오래된 케이블 망이라고 주장합니다. SVTA 브리프 자체도 비슷한 물음을 던지며, 여러 해에 걸친 CDN 엣지 증설, HEVC와 AV1과 VVC 같은 더 나은 코덱, 그리고 새로운 전송 프로토콜이 이미 업계를 성장 곡선보다 앞서게 해 온 것은 아닌지 묻습니다. Comcast 자신의 초기 mABR 프로젝트가, 2015년 무렵 자사 VIPER 연구 그룹에 의해 진행되었으면서도 끝내 배치에 이르지 못했다는 점은 떠올릴 가치가 있습니다.
여러 변형이 절감을 갉아먹는다
사업자가 제공하려는 포맷, 비트레이트 사다리, DRM 변형 하나하나를 따로따로 멀티캐스트해야 합니다. 관여하는 기기 종류와 콘텐츠 보호가 많을수록 필요한 병렬 멀티캐스트 스트림이 많아지고, 효율의 순이득은 작아집니다.
실제로 누가 mABR을 쓰는가
mABR은 실험실 단계를 지났습니다. 가장 분명한 공개 사례는 자기 관리 액세스 망을 운영하는 통신사업자들에게서 나옵니다.
- 영국의 BT Group이 이에 대해 가장 솔직했습니다. BT는 2024년에 MAUD 이니셔티브를 발표했고, 2025년 3월에 첫 생중계 시험 성공을 보고했습니다. 이는 BBC Two를 EE 셋톱박스로 전달하며 피크 트래픽의 60퍼센트 이상을 멀티캐스트로 전환했습니다. BT는 목표가 대규모 시청자의 생중계 행사를 감당하는 것이라고 밝혔으며, 업계 보도는 방송사들이 2026 FIFA 월드컵을 위해 MAUD를 평가하고 있다고 전했습니다.
- 스페인의 Orange는 자사 고객에게, 가장 시청자가 많은 생중계 행사에 mABR 스트리밍을 제공하는 자국 최초의 사업자라고 알렸으며, LaLiga, 포뮬러 1, MotoGP를 들고, 그것을 셋톱박스를 넘어 가정 내 다른 기기로 확장하고 있습니다.
- 이탈리아의 TIM은 자사 기술지에, 2021년부터 ETSI의 M-ABR 표준을 따르는 멀티캐스트 콘텐츠 배포 플랫폼을 운영하고 있으며, 스포츠 같은 대규모 생중계 행사에 확장성을 더하는 데 쓰고, 기존 유니캐스트 모델과 자동 폴백으로 통합했다고 썼습니다.
- 프랑스의 Bouygues Telecom은 2023년부터 mABR로 상용 스트리밍을 하는 최초의 프랑스 사업자로 업계 언론에 소개되었습니다.
모든 사업자가 확신하는 것은 아닙니다. Deutsche Telekom은 mABR을 장기적인 목적지가 아니라, 인프라가 아직 순수 유니캐스트를 감당하지 못하는 곳에서 유용한 과도기 기술로 공개적으로 자리매김했습니다.
이 배치들을 관통하는 한 가지 패턴이 두드러집니다. 그것들은 거의 모두 상호 운용 가능한 표준 기반 스택이 아니라, 단일 벤더의 같은 독점 구현, 곧 Broadpeak의 nanoCDN 위에 세워졌습니다. 이는 기술적 보증이 아니라 시장의 사실입니다. DVB-MABR 명세는 공개되어 있지만, 여러 해 동안 그 위에 무언가를 만들고 그것에 대해 시험할 수 있는 중립적이고 공개적으로 이용 가능한 구현이 존재하지 않았기에, 상용으로 mABR을 원하는 사업자에게는 공급자의 실질적인 선택지가 거의 없었습니다.
기기 쪽
하드웨어 쪽에서는 셋톱박스와 CPE 제조사가 사업자만큼이나 중요합니다. CommScope는 DVB와 CableLabs 표준 양쪽의 일부에 기반한다고 설명하는 Multicast ABR 솔루션을 제공하며, 그 클라이언트는 셋톱박스나 가정용 게이트웨이에 내장되어 동작할 수 있고, 회사는 가정 내 스트리밍 기기에 어떤 변경도 필요 없다고 밝힙니다. Vantiva, 옛 Technicolor는 멀티캐스트 ABR 클라이언트 소프트웨어를 통합한 셋톱박스를 출하해 왔습니다. Broadcom 같은 공급사의 셋톱박스 칩셋은 망 수준에서 IP 멀티캐스트 지원을 제공하지만, mABR 자체는 기기에서 동작하는 소프트웨어로 구현되어 있으며, 이름이 붙은 칩셋 기능이 아닙니다.
그 격차는 가장 큰 기기 플랫폼에서 가장 잘 보입니다. 기본 Android TV는 유니캐스트만 지원하므로, 그 기기들에서의 multicast ABR은 멀티캐스트 클라이언트를 더하는 사업자 등급의 통합에 의존합니다. Google 자신의 플레이어 라이브러리인 ExoPlayer와 Media3는 multicast ABR을 기본으로 제공하지 않으며, 그것을 요청하는 미해결 기능 요청이 있습니다.
표준은 존재한다. 어려운 부분은 상호 운용성이다.
mABR이 빠진 표준 때문에 발목을 잡혔다는 것은 흔한 가정입니다. 사실이 아닙니다.
CableLabs는 2014년 무렵 IP 멀티캐스트 ABR에 대한 초기 아키텍처 작업을 했습니다. DVB Project는 2018년에 multicast ABR 참조 아키텍처를 업계 의견 수렴을 위해 공개했고, 그 Steering Board는 2020년 초에 완전한 명세를 승인했으며, 그것은 2020년 11월에 ETSI 표준 TS 103 769로 공개되었습니다. 그 이후 여러 차례 개정되었는데, 그중 2023년 업데이트는 선택적 전송 프로토콜인 NORM과 MSYNC, 그리고 보고, 진위 확인, 변조 방지 기능을 더했습니다. 그 배후의 DVB 작업 그룹 MCAST는 BBC R&D의 리처드 브래드버리가 의장을 맡고 있습니다. 실재하고 공개되었으며 국제적으로 인정받은 표준이 있고, DVB-MABR 구현 지침과 DVB-I 서비스 발견 명세 같은 동반 작업도 함께 있습니다. 모바일 쪽에서는 3GPP가 자기 나름의 평행한 길을 가고 있는데, Release 17의 5G Multicast-Broadcast Services 아키텍처는 같은 FLUTE와 ROUTE의 프로토콜 계보를 공유합니다.
빠져 있던 것은 실제에서의 상호 운용성입니다. 오늘날까지의 거의 모든 상용 mABR 배치는 같은 독점 스택, 곧 Broadpeak의 nanoCDN 위에서 동작합니다. 2023년에 DVB-MABR에 편입된 선택적 전송 프로토콜 중 하나인 MSYNC는, 명세에 들어오기 전에는 Broadpeak의 프로토콜로 시작했습니다. 대부분 한 벤더에 의해 구현되는 표준은 종이 위의 표준입니다. 종이 명세를 여러 벤더가 작동하는 시장으로 바꾸는 것은, 누구나 그 위에 만들고 그것에 대해 시험할 수 있는 중립적인 구현입니다.
GPAC와 Motion Spell이 들어오는 지점
이것이 진정한 표준화로 가는 길을 가리키는, mABR 이야기의 부분입니다.
GPAC는 오래 이어져 온 오픈 소스 멀티미디어 프레임워크로, LGPL 라이선스로 배포되며 상업 파트너인 Motion Spell과 함께 개발됩니다. Telecom Paris의 학술 연구에 뿌리를 두고 있고, 거의 1억 번 다운로드되었습니다. GPAC는 여러 해 전에 ATSC 3.0을 위해 ROUTE 프로토콜을 구현했고, 그 작업은 2018년에 NAB 혁신상을 받았습니다. 그리고 GPAC는 DVB-MABR의 두 필수 전송 프로토콜인 ROUTE와 FLUTE를 모두 지원하는 유일한 오픈 소스 프로젝트입니다. 2024년에는 DVB-MABR을 위한 FLUTE 지원을 특별히 추가했습니다. GPAC의 미디어 서버는 이미 멀티캐스트에서 ABR로 가는 게이트웨이로 동작할 수 있으며, 멀티캐스트 세션을 일반 HTTP 스트리밍 서비스로 노출하고, 유니캐스트 복구와 구성 가능한 타임시프트 창을 갖추고 있습니다.
이어서 DVB는 DVB-MABR 구현을 검증하고 확인하기 위한 오픈 소스 도구의 제안 요청을 냈습니다. 그 결과인 DVB-MABR Reference Tools는 GPAC와 Motion Spell 위에 세워졌습니다. 그것은 오픈 소스이고, GPAC 라이브러리 위에 Python으로 작성되었으며, 두 가지 모드로 동작합니다. HTTP 소스에서 멀티캐스트 스트림을 만들어 내는 서버 모드와, 멀티캐스트를 받아 HTTP 복구를 포함해 HTTP로 다시 제공하는 게이트웨이 모드입니다. 그것은 DVB 자신의 GitHub 조직에 공개되어 있으며, 멀티캐스트 서버, 게이트웨이, 표준 DASH 플레이어가 실제로 상호 운용되는지 확인해야 하는 엔지니어, 통합 담당자, 검증 팀을 겨냥합니다.
그래서 이 작업은 또 하나의 제품 출시보다 더 큰 의미가 있습니다. 로열티가 없고 공개적으로 이용 가능한 참조 구현은, 모든 사업자, 기기 제조사, 소프트웨어 벤더에게 공통의 기준선을 줍니다. 그것은 DVB-MABR이 단일 벤더 배치의 시장에서 여러 벤더에 걸친 진정한 상호 운용성으로 옮겨 갈 수 있게 하는 실질적인 메커니즘이며, 그것이 바로 공개된 표준과 생태계 전체가 실제로 쓸 수 있는 표준의 차이입니다. GPAC의 참여는 또한 mABR을 더 넓은 연구, 곧 더 지속 가능한 영상 전달에 매달리는 SMART-CD 컨소시엄의 작업과 연결하며, 그곳에는 Telecom Paris, Ateme, Viaccess-Orca 같은 파트너가 함께합니다.
곁가지 메모: 피어 투 피어는 같은 문제를 반대쪽 끝에서 공략한다
인기 있는 생중계 스트림이 시청자 한 명당 한 번씩 보내지는 것을 막는 방법은 mABR만이 아닙니다. 피어 투 피어 전달은 같은 낭비를 반대 방향에서 공략합니다. 사본 하나를 관리망에 들여보낸 뒤 가정 가까이에서 부채꼴로 펼치는 대신, 피어 투 피어 계층은 시청자 자신의 기기들이 서로 세그먼트를 나누게 합니다. 각 플레이어는 첫 바이트를 CDN에서 가져온 다음, 같은 것을 보고 있는 다른 플레이어들과 직접 청크를 주고받고, 어쩔 수 없을 때만 CDN으로 되돌아갑니다.
프랑스 기업 Quanteec이 한 사례입니다. 학술 연구로 시작한 그 기술은, 기존 HLS 또는 DASH 워크플로 위에 피어 보조 계층을 더하며, CDN과 DRM에 구애받지 않습니다. Quanteec은 수십만 명의 동시 시청자를 감당한 France Télévisions와의 배치가 평균적으로 트래픽의 약 75퍼센트를 CDN에서 덜어 냈으며, 50퍼센트가 넘는 에너지 절감과 순수 유니캐스트보다 적은 재버퍼링을 보였다고 보고합니다.
mABR과의 중요한 대비는 망입니다. mABR에는 관리 액세스 망과 사업자의 협조가 필요합니다. 피어 투 피어는 공공 인터넷 위에서, 기기 사이에서, 사업자의 어떤 관여도 없이 동작하며, 그것이 바로 mABR이 닿을 수 없는 빈틈입니다. 절충점은, 피어 투 피어가 충분한 수의 동시 시청자가 있는지에 의존하고, 또 소비자 기기의 업로드 용량과 행동에 의존한다는 것입니다. 두 접근법은 서로 배타적이지 않습니다. 마지막 마일을 통제하지 못하는 방송사는 오늘 당장 피어 투 피어를 쓸 수 있고, 자기 망을 통제하는 사업자는 mABR을 쓸 수 있으며, 큰 플랫폼은 둘 다에 기댈 수도 있습니다.
이것이 사업자에게 뜻하는 것
mABR은 만병통치약이 아니고 새롭지도 않습니다. 그것은 하나의 구체적이고 비용이 큰 문제를 위한, 초점이 분명한 도구입니다. 곧 같은 생중계 스트림을 관리망에서 매우 큰 시청자에게, 사본마다 비용을 치르지 않고 전달하는 것입니다. 큰 스포츠 결승을 실어 나르는 사업자에게 그 문제는 현실이고, 시즌마다 더 심해집니다. 마지막 마일을 통제하지 못하는 순수 OTT 서비스에게 mABR은, ISP에 지원을 요청할 수는 있어도 혼자 만들어 낼 수는 없는 것입니다.
정직한 요약은 이렇습니다. 기술은 작동하고, 표준은 존재하며, 배치는 현실이지만 여전히 단일 벤더의 독점 스택에 집중되어 있고, 지연과 기기 생태계는 현실의 제약으로 남아 있으며, GPAC와 Motion Spell이 이끄는 오픈 소스 참조 작업이 그 집중을 바꿀 가장 신뢰할 만한 길이라는 것입니다.
iReplay.TV는 방송과 스트리밍 엔지니어들의 집단이므로, mABR과 피어 투 피어와 평범한 유니캐스트 CDN 전달 사이의 절충은 그 구성원들이 정기적으로 저울질하는 종류의 것입니다. Multicast ABR은 여러 지렛대 가운데 하나이고, 관리망 안에서만 도움이 됩니다. 시청자가 열린 인터넷을 거쳐 당신에게 닿는다면, 절감은 다른 곳에서 와야 합니다. 피어 보조 전달, 더 영리한 오리진 설계, 더 나은 코덱 선택, 그리고 더 단단한 CDN 구성입니다. 자기 숫자를 들여다보고 싶은 사람을 위해, 사이트에는 무료 CDN 비용 최적화 도구가 있습니다.
출처 및 더 읽을거리
- DVB, "Adaptive media streaming over IP multicast" (DVB-MABR 명세 페이지): dvb.org
- DVB, "DVB-I and DVB-MABR published as ETSI standards": dvb.org/news
- DVB, "DVB publishes updated Multicast ABR specification and guidelines" (2023년 업데이트): dvb.org/news
- DVB, "DVB-MABR Reference Tools": dvb.org
- GPAC, "MABR: Multicast Adaptive BitRate": gpac.io
- Motion Spell, "DVB-MABR Open-Source Tool" (소스 코드 저장소): github.com/MotionSpell
- Streaming Video Technology Alliance, "The Viability of Multicast ABR in Future Streaming Architectures": svta.org
- BT Group, "BT delivers first successful trial of new live streaming technology": newsroom.bt.com
- CommScope, Multicast Adaptive Bitrate (MABR) Solution: commscope.com
- IETF: FLUTE (RFC 6726), ROUTE (RFC 9223), NORM (RFC 5740), rfc-editor.org에서 이용 가능