GigaOM Radar Edge Platform Leader & Outperformer 2024 | 
광고 비용과 시청자가 기존 TV에서 벗어나면서 콘텐츠 소유자와 방송사는 OTT(Over-the-Top) 스트리밍을 통해 새로운 시청자를 유치하고 수익을 증대하기 위해 광고 지원 라이브 이벤트 스트리밍을 찾고 있습니다. OTT는 새로운 배포 기회를 제공함으로써, 이전에 방송 TV에서 볼 수 없었던 라이선스가 부여된 콘텐츠를 방송하고 수익을 창출할 수 있습니다. 그러나 게시자가 라이브 이벤트를 스트리밍하기 전에 스트리밍 비디오 워크플로우의 첫 번째 단계에서 기술적 장애물을 고려해야 합니다.
- 장소와 수집 지점 간의 연결 품질 및 대역폭 가용성은 워크플로우에서 약한 링크일 수 있습니다. 이중화 및 안정성이 내장되어야 합니다.
- 라이브 피드는 지연 시간을 최소화하면서 Apple HLS 및 MPEG-DASH와 같은 다양한 적응형 비트 전송률 형식 및 프로토콜로 인코딩되어야 합니다.
- 업로드 및 인코딩 솔루션은 4K 및 기타 고품질 포맷의 출현을 처리하기 위해 미래에 대비하고 안정적이며 확장 가능해야 합니다.
- 비디오 워크플로는 최고의 시청자 경험과 가장 적절한 수익 창출 전략을 위해 서버측 광고 삽입을 지원할 수 있어야 합니다.
이 기술 블로그에서는 게시자가 스트리밍 비디오 워크플로우의 첫 번째 단계를 최적화할 수 있도록 플랫폼을 구축한 방법을 살펴보고, 관련된 몇 가지 과제를 살펴보고, 라이브 스트림을 인코딩하여 고성능, 짧은 지연 시간, 광고 지원 라이브 스트리밍을 구현하는 방법을 설명합니다.
Background: 슬라이서
인코딩의 기술적 고려 사항에 다이빙하기 전에, 우리는 “슬라이서”라는 우리의 기술을 설명해야합니다. 강력한 소프트웨어 클라이언트인 슬라이서는 장소의 라이브 스트림을 클라우드 비디오 플랫폼으로 진입시킵니다. 유연성과 기능을 희생하지 않고 매우 복잡한 작업을 단순화합니다. 슬라이서는 방대한 기술 리소스를 보유한 방송사와 그렇지 않은 방송사가 Akamai 플랫폼을 활용하여 강력하고 차별화된 OTT 경험을 창출할 수 있는 주요 이유입니다.
슬라이서는 인코딩을 위해 콘텐츠를 준비하고 이상적인 인코딩 설정을 계산하며 광고 삽입 표시를 관리합니다. 보안 하드웨어에서 슬라이서를 실행하거나 SDI, IP 비디오, RTP/FEC 및 RTMP를 비롯한 다양한 형식을 지원하는 클라우드 독립적 위치의 비용 절감 및 확장성을 선택할 수 있습니다.
슬라이서는 콘텐츠를 작은 조각으로 쪼개서 암호화한 후 ISO 인증 클라우드 인코딩 스택으로 전송하므로 콘텐츠가 항상 안전하다는 것을 안심하고 사용할 수 있습니다. 간단한 원클릭 구성에서 선택한 프로그래밍 언어의 고급 스크립트, 알림, 작업 처리 및 머신 러닝 통합을 위한 워크플로우를 트리거하는 클라우드 기능 작성에 이르는 유연한 워크플로우를 제공합니다.
슬라이서의 한 버전인 “라이브 슬라이서”는 라이브 이벤트 스트리밍에 최적화되어 있습니다. HD-SDI 또는 IP 기반 피드는 원하는 최고 비트 전송률로 2초 또는 4초 암호화된 세그먼트로 빠르게 인제스트되고 청크링되어 대역폭 요구 사항이 1080p의 경우 3–5Mbps, 4K의 경우 약 15Mbps로 감소합니다. 당사의 프로세스는 대역내 및 대역외 메타데이터와 메시지를 자동으로 유지하여 프로그램 및 광고 중단을 트리거하거나 콘텐츠를 대체합니다. 당사의 플러그인 아키텍처를 사용하면 고유한 시그널링 이벤트 요구 사항을 처리하는 사용자 지정 스크립트를 만들 수 있습니다. 라이브 슬라이서는 또한 SCTE 35 / 104 메시지를 듣거나 광고 중단, 콘텐츠 시작 또는 차단 트리거를 삽입하는 API 호출을 수신할 수 있습니다.
OTT 스트림은 최소한의 선행 투자와 낮은 대역폭 요구 사항으로 라이브 리니어 피드에서 생성됩니다.
대역폭 최소화
이제 Slicer를 이해했으므로 이벤트에서 클라우드로 라이브 스트림을 이동하는 프런트 엔드 소프트웨어 구성 요소를 개발해야 하는 이유가 궁금할 것입니다. 예를 들어, 게시자가 RTMP(실시간 메시징 프로토콜) 스트림을 전송할 수 없는 이유는 무엇입니까? (원하는 경우 이 작업을 수행할 수 있지만 대부분의 고객은 슬라이서를 활용합니다.)이 대답은 라이브 공연장의 대역폭 문제를 해결하는 것과 마찬가지로 고품질 라이브 스트림에 대한 소비자의 기대와 관련이 있습니다. 그것은 많은 경쟁 요인에서 올바른 균형을 찾는 문제입니다. 한편으로는 고품질 포맷과 4K를 고려하여 원본 피드를 가능한 한 많이 보존해야 합니다. 반면, 개인화된 광고와 같은 추가 오버헤드로 인해 방해받지 않고 효율적으로 전달될 수 있도록 스트림을 최적화해야 합니다. 비디오 워크플로우의 이 단계에서 올바른 균형을 찾는 것이 중요합니다.
슬라이서가 필수적인 부분입니다. 위에서 언급했듯이, 사이트에서 가장 높은 비트레이트 프로필을 생성하고 해당 프로필을 클라우드로 전송하여 주어진 피드에 필요한 대역폭을 크게 줄입니다. 전 세계 수십억 명의 시청자에게 수백만 시간의 라이브 영상을 스트리밍하는 것을 기반으로 한 우리의 관찰에 따르면, 클라우드로 훨씬 큰 RTMP 스트림을 전송하는 대체 접근 방식은 시청 경험의 품질을 크게 향상시키지 않습니다. 그러나 대역폭이 크게 증가하여 비용이 증가합니다.
백홀 비용이 빠르게 증가할 수 있습니다. 귀하의 요구 사항이 위성 업링크가 필요하다면, 예를 들어 카 밴드 트럭은 하루에 약 2,000 달러의 임대료를 내고 대역폭은 시간당 약 400 달러입니다. 호텔, 컨퍼런스 센터 또는 전 세계 스포츠 경기장과 같은 일부 장소에서 일관되지 않고 대역폭이 제한되는 상황을 고려할 때, 시청자에게 방송과 같은 경험을 제공하면서 업로드 대역폭 요구 사항을 최대한 줄이는 것이 항상 좋은 생각이라는 것이 핵심입니다.
인코딩 장애물
라이브 비디오 피드가 장소를 벗어나면 워크플로의 다음 단계는 인코딩입니다. 여기에서 비디오 인코더는 다양한 비트 전송률, 해상도 및 품질 수준으로 오디오 및 비디오의 여러 버전 또는 변형을 만듭니다. 그런 다음 변형을 작은 파일 또는 미디어 세그먼트로 분할합니다. 변형의 미디어 세그먼트를 가리키는 URL 목록을 포함하는 각 변형에 대한 미디어 재생 목록을 만드는 것과 같은 몇 가지 추가 단계가 수행되어야 한다. 결과로 생성되는 마스터 플레이리스트는 플레이어가 디바이스에 가장 적합한 변형과 현재 측정되거나 사용 가능한 대역폭을 선택하는 것이다.
두 가지 주요 비디오 스트리밍 프로토콜은 복잡성을 가중시키고, 다른 프로토콜은 잠재적 인 재생 장치의 무수를 다루기 위해 지원되어야 할 수도 있습니다. HLS는 Apple에서 구현한 HTTP 기반 미디어 스트리밍 통신 프로토콜입니다. 모든 Apple 장치와 대부분의 Google, Android, Linux 및 Microsoft 브라우저와 장치에 대한 지원을 제공합니다. 대부분이지만 전부는 아닙니다. 또한 경쟁 HTTP 기반 미디어 스트리밍 프로토콜인 MPEG-DASH가 필요합니다. 게임 콘솔용 Microsoft Smooth Streaming에 대한 지원을 추가해야 할 수도 있습니다.
DRM은 또한 많은 청중의 요구 사항을 지원하기 위해 자체 다중 형식 세트를 요구함으로써 인코딩을 복잡하게 만들 수 있습니다. 예를 들어, DRM을 지원하지 않는 구형 플레이어는 HLS와 AES-128이 필요합니다. 이전 iOS 장비에는 HLS 및 FairPlay가 필요합니다. 최신 iOS 장비는 HLS 및 FairPlay 및 CMAF CBC를 지원합니다. 이전 Windows 및 Android는 CMAF CTR만 지원합니다. 최신 Android, Windows 및 iOS는 모든 CMAF 형식을 지원해야 합니다. 모든 장치에서 재생할 수 있도록 콘텐츠를 여러 형식으로 패키징해야 합니다.
이것이 많은 인코딩 작업처럼 들린다면, 당신이 옳습니다. 해상도가 증가하고 코덱이 복잡해짐에 따라 클라우드나 온프레미스 등 단일 시스템에서 완전한 ABR 인코딩 래더를 인코딩하기가 더욱 어려워집니다. 인코딩 하드웨어가 라이브 피드를 따라가지 못하는 경우 인코딩 사다리의 가로대 수를 줄여야 할 수 있으며, 이는 궁극적으로 청중의 경험에 영향을 미칠 수 있습니다.
보다 복잡한 인코딩 요구 사항에 보조를 맞추기 위해 기존 모델은 생산자가 속도와 품질을 유지하기 위해 새로운 하드웨어에 지속적으로 투자해야 한다는 것을 의미합니다. 궁극적으로 Edgio(구 Verizon Digital Media Services)와 같은 스트리밍 서비스의 경우 1:1 스트림-인코더 모델은 고객의 기대치를 충족하는 데 필요한 안정성, 유연성 및 확장성을 제공하지 못합니다.
대신, 우리는 필요한 만큼의 인코더를 사용할 수 있는 정교한 브로커링 시스템을 개발했으며, 모든 인코더는 클라우드 기반 인프라에서 실행됩니다. 브로커링 시스템은 슬라이서 인스턴스에서 콘텐츠 청크를 수신하여 가장 최적의 인코더로 이동합니다. 이 작업은 인코딩 프로세스가 특정 시스템에 과부하를 주지 않도록 하고 청크가 시스템을 통해 저장소로 이동하고 시청자에게 전송되도록 합니다.
브로커 프로세스는 클라우드 인코더 인프라를 원활하게 그리고 더 중요한 것은 자동으로 확장합니다.
구현에서 브로커 인스턴스는 슬라이서와 인코더 사이에서 통신하는 관리자 역할을 합니다. 브로커는 새 슬라이서가 데이터를 적절한 인코더로 라우팅하도록 하고 인코더가 워크로드를 처리할 수 있는지 확인합니다. 또한, 우리는 매우 유능한 확장 인프라를 가지고 있습니다. 인코딩이 필요한 백만 시간의 VOD 콘텐츠가 갑자기 버려지면 서버 인스턴스를 빠르게 늘리고 콘텐츠 처리를 시작할 수 있습니다. 또한 자원을 절약하기 위해 빠르게 확장할 수도 있습니다. 이 브로커 프로세스는 전체 클라우드 인프라를 원활하게 그리고 더 중요한 것은 자동으로 관리합니다.
상태 비저장 인코더
물론 중개 시스템은 슬라이서를 라이브 스트림의 요구를 따라가지 못할 수도 있고 따라가지 못할 수도 있는 단일 인코더를 가리키기만 하면 가치가 제한됩니다. 이는 4K의 심각한 문제입니다. 우리가 개발한 솔루션은 상태 비저장 인코더의 사용과 관련이 있습니다. 단일 시스템을 전체 스트림에 할당하는 대신 각 인코더는 한 번에 2 ~ 4 초의 비디오 세그먼트만 수신합니다. 각 세그먼트에는 인코더를 프라이밍하기에 충분한 정보가 포함되어 있으므로 인코더를 인코딩하여 리드 인 및 리드 아웃 정보와 같이 프라이밍에 불필요한 모든 정보를 폐기할 수 있습니다. 이 시점에서 전체 세그먼트가 완료되고 사용할 준비가 되어 인코더가 해제되어 다른 채널이나 다른 콘텐츠의 다른 부분을 인코딩하기 시작할 수 있습니다.
이 모델에는 시스템에 상당한 양의 중복성이 내장되어 있습니다. 예를 들어 세그먼트를 처리하는 동안 인코더가 충돌하면 동일한 세그먼트가 다른 컴퓨터에서 시작되어 스트림 내에서 문제가 발견되기 전에 제시간에 완료됩니다.
또한 이러한 접근 방식을 통해 보다 비용 효율적인 하드웨어를 사용할 수 있습니다. 예를 들어, 속도가 느린 시스템이 슬라이서에서 4초 분량의 파일을 처리하는 데 8초가 걸릴 수 있다는 것을 알고 있는 경우 아래와 같이 여러 인코더에 작업 부하를 분산할 수 있습니다. 서버 A는 슬라이스 1을, 서버 B는 슬라이스 2를 각각 가져오는 식입니다. 그런 다음 청크는 예측 가능한 시간에 모두 완료되었기 때문에 문제 없이 전달되었습니다. 아래 차트에 표시된 것처럼 이 예에서는 라이브 지연 시간이 16–20초 지연됩니다.
클라우드에서 여러 인코더를 사용하면 지연 시간이 최소화되고 라이브 피드를 따라가지 못하는 서버를 사용할 수 있습니다.
궁극적으로 클라우드의 서버 볼륨은 개별 서버가 느리더라도 인코딩 프로세스가 항상 라이브 수요를 충족할 수 있음을 의미합니다. 기존 모델을 사용하여 인코딩 인프라를 설정하려면 실시간 지원 없이 수신되는 비디오 전체를 처리할 수 있는 고가의 고성능 시스템이나 특수 하드웨어에 투자해야 합니다. 클라우드의 확장성을 활용함으로써 인코딩 비용을 크게 절감할 수 있습니다.
스테이트리스 클라우드 인코딩의 또 다른 이점은 특수 서버 요구 사항이 없기 때문에 워크로드를 대체 클라우드 공급업체로 쉽게 이동할 수 있다는 점입니다. 250Tbps가 넘는 용량의 네트워크를 통해 멀티 클라우드 접근 방식은 고유한 장점을 제공합니다.
비용 효율적인 라이브 스트리밍
라이브 콘텐츠 제작자의 경우 클라우드 스트리밍을 위해 라이브 비디오를 준비하기 위한 기술적 고려 사항은 막대한 장애물을 초래할 수 있습니다. 장소 대역폭 제한에서 인코더 및 스트리밍 프로토콜과 관련된 복잡한 질문에 이르기까지 다양한 문제에 직면하게 됩니다. 현장에서 일부 연결이 필요 없지는 않지만 프런트 엔드의 대역폭 요구 사항을 줄이고 워크플로우를 간소화하면 시청자가 기대하는 고품질 저지연 스트림을 제공하는 동시에 초기 및 지속적인 지출을 크게 줄일 수 있습니다.
