낮은 대기 시간은 미디어의 보편적인 열망입니다. Wowza와 같은 회사가 대기 시간이 짧은 스트리밍 기술을 설명하는 완벽한 차트를 생성할 때, 당신은 그들에게 경의를 표하고 특성 및 약간의 수정과 함께 차트를 사용해야 합니다. 나는 상기 차트를 그림 1로 제시합니다. 내가 추가한 강조표시된 번호로 지정된 순서대로 토론해 봅시다.
1. 저지연을 위한 애플리케이션
우리 모두가 같은 페이지에 있는지 확인하기 위해 라이브 스트리밍의 맥락에서 대기 시간은 유리 대 유리 지연을 의미합니다. 첫 번째 유리는 실제 라이브 이벤트의 카메라이고 두 번째 유리는 보고 있는 화면입니다. 대기 시간은 가 카메라에 나타나는 시점과 휴대폰에 나타나는 시점 사이의 지연입니다. 대기 시간에 기여하는 요소는 인코딩 시간(이벤트에서), 클라우드로의 전송 시간, 클라우드에서 트랜스코딩 시간(인코딩 래더 생성을 위해), 전송 시간, 그리고 결정적으로 재생을 시작하기 전에 플레이어가 버퍼링하는 시간(초)과 같은 요소입니다.
최상위 레이어는 일반적인 애플리케이션과 대기 시간 요구 사항을 보여줍니다. 짧은 대기 시간과 실시간에 가까운 대기 시간에서 누락된 인기 애플리케이션은 도박 및 경매 사이트입니다.
기술 논의를 시작하기 전에 라이브 스트림의 대기 시간이 짧을수록 대역폭 중단에 대한 스트림의 탄력성이 떨어집니다. 예를 들어, 기본 설정을 사용하면 HLS 스트림이 15초 이상의 중단된 대역폭을 통해 재생되며 해당 지점에서 복원되면 시청자는 문제가 있음을 전혀 모를 수 있습니다. 반대로 대기 시간이 짧은 스트림은 중단 직후에 재생이 중지됩니다. 따라서 대기 시간이 짧은 시작 시간의 이점은 항상 재생 중단의 단점과 균형을 이루어야 합니다. 낮은 대기 시간이 절대적으로 필요하지 않은 경우 이를 얻기 위해 복원력을 희생할 가치가 없을 수 있습니다.
즉, 대기 시간을 다음과 같이 세 가지 범주로 나누는 것이 유용합니다.
오디오 + 비디오 + IT. 우리의 편집자는 오디오/비디오와 IT를 통합하는 전문가입니다. 매일 통찰력, 뉴스 및 전문적인 네트워킹을 얻으십시오. 오늘 Pro AV를 구독하십시오 .
- 있으면 좋습니다 - 빠를수록 좋습니다. 하지만 교육 위원회 회의나 고등학교 축구 경기를 실시간 스트리밍하는 경우 특히 많은 시청자가 낮은 속도로 시청하는 경우 스트리밍 견고성이 짧은 대기 시간보다 더 중요하다고 결정할 수 있습니다. 비트레이트 연결.
- 경쟁 우위 - 경우에 따라 짧은 대기 시간은 경쟁 우위를 제공하거나 느린 대기 시간은 경쟁에서 불리함을 의미합니다. 차트에서 케이블 TV의 일반적인 대기 시간이 약 5초임을 알 수 있습니다. 스트리밍 서비스가 케이블과 경쟁하는 경우 지연 시간이 낮아 경쟁 우위를 제공하는 해당 범위에 있어야 합니다.
- 실시간 통신 - 도박 또는 경매 사이트이거나 애플리케이션에 실시간 통신이 필요한 경우 낮은 대기 시간을 제공해야 합니다.
카테고리를 알았으니 이제 필요한 수준의 낮은 대기 시간을 제공하는 가장 효율적인 방법을 살펴보겠습니다.
2/3 대기 시간이 짧아서 좋음
숫자 2는 기본 설정을 사용하여 배포된 Apple HLS 및 MPEG-DASH가 약 30초의 대기 시간을 초래한다는 것을 보여줍니다. 숫자는 간단합니다. 10초 세그먼트 크기를 사용하고 재생이 시작되기 전에 3개의 세그먼트가 플레이어 버퍼에 있어야 하는 경우 30초입니다. 사실 Apple은 몇 년 전에 요구 사항을 10초에서 6초로 변경했으며 대부분의 DASH 생산업체는 4-6초 세그먼트를 사용하므로 기본 숫자는 실제로 20초에 가깝습니다.
그래도 3번 HLS Tuned와 DASH Tuned는 6~8초 정도의 레이턴시를 보인다. 본질적으로 튜닝이란 10초 세그먼트에서 동일한 수학을 적용하여 6-8초의 대기 시간을 제공하는 2초 세그먼트로 변경하는 것을 의미합니다. 따라서 대기 시간이 있으면 개발 시간이나 비용 없이 대기 시간을 크게 줄이거 나 배달 가능성 위험이 크게 증가할 수 있습니다.
4. 경쟁 우위 - 대기 시간이 짧은 HTTP 기술
짧은 대기 시간이 경쟁 우위로 필요한 경우 세그먼트 크기를 줄이는 것만으로는 충분하지 않습니다. 진정한 저지연 기술을 구현해야 합니다. 여기에는 두 개의 클래스가 있습니다. Low-Latency HLS 및 DASH용 Low-Latency CMAF와 같은 HTTP 기술과 WebSockets 및 WebRTC와 같은 다른 기술을 기반으로 하는 솔루션.
이 등급의 애플리케이션을 사용하는 대부분의 생산자에게 대기 시간이 짧은 HTTP 기술은 경제성, 이전 버전과의 호환성, 유연성 및 기능 세트의 최상의 조합을 제공합니다. 따라서 이 섹션에서는 DASH용 Low Latency HLS 및 Low Latency CMAF를 다루고 다음 섹션에서는 기타 기술에 대해 설명하겠습니다.
모든 HLS/DASH/CMAF 기반 저지연 시스템은 그림 2와 같이 동일한 기본 방식으로 작동합니다. 즉, 일반적으로 6~10초가 소요되는 전체 세그먼트가 인코딩될 때까지 기다리지 않습니다(그림 2 상단). , 인코더는 완료되는 즉시 CDN으로 전송되는 훨씬 더 짧은 청크를 생성합니다(그림 2 하단).
예를 들어 인코더가 6초 세그먼트를 생성하는 경우 최소 6초의 대기 시간이 있습니다. 재생이 시작되기 전에 시청자가 일반 세 개의 세그먼트를 수신해야 하는 경우 세 배입니다. 그러나 인코더가 200밀리초마다 청크를 내보내고 플레이어가 즉시 재생을 시작하도록 구성했다면 대기 시간은 훨씬 더 짧아야 합니다. 이 스키마의 주요 이점 중 하나는 이전 버전과의 호환성입니다. 세그먼트가 아직 생성 중이므로 대기 시간이 짧은 스키마와 호환되지 않는 플레이어는 대기 시간이 더 길더라도 여전히 세그먼트를 재생할 수 있어야 합니다. 이러한 세그먼트는 라이브 스트림의 VOD 프레젠테이션에도 즉시 사용할 수 있습니다.
이러한 이점 외에도 대기 시간이 짧은 HTTP 기술은 WebRTC 및 WebSockets 기반 기술에서 보편적으로 지원되지 않는 암호화, 광고 삽입 및 자막을 포함하여 일반 대기 시간 형제의 기능 대부분을 지원합니다. 기존 플레이어 및 전달 인프라를 사용하여 선택한 저지연 기술을 구현하여 개발 및 기타 기술 비용을 최소화할 수 있습니다.
HTTP 저지연 기술 선택
HTTP Adaptive Streaming, HLS 및 DASH에 대한 두 가지 주요 표준과 통합 컨테이너 형식인 CMAF가 있습니다. Apple이 Low Latency HLS (새 탭에서 열림) 솔루션을 발표하자 여러 풀뿌리 노력을 즉시 대체하고 HLS에 짧은 지연 시간을 제공하기 위해 선택한 기술이 되었습니다. 사양은 아직 비교적 새롭지만 Nimble Streamer 제품을 통해 Wowza 및 WMSPanel 과 같은 기술 제공업체에서 이미 지원하고 있습니다.
대기 시간이 짧은 DASH에 대한 DVB 표준이 있으며 DASH Industry Forum은 다음 상호 운용성 지침에 포함될 DASH에 대한 몇 가지 저지연 모드를 승인했습니다. 이러한 모든 사양에 따라 인코더 및 플레이어 개발자와 콘텐츠 전송 네트워크는 모든 DASH/CMAF 저지연 애플리케이션이 순조롭게 실행될 수 있도록 상호 운용성을 보장하기 위해 수년간 노력해 왔습니다.
예를 들어, Harmonic과 Akamai는 NAB 및 IBC 2017까지 짧은 대기 시간 CMAF를 함께 시연하여 대기 시간이 5초 미만인 라이브 OTT 전송을 보여주었습니다. 그 이후로 Harmonic은 대기 시간이 짧은 DASH 기능을 어플라이언스 기반 제품(Packager XOS 및 Electra XOS)과 SaaS 솔루션(VOS Cluster 및 VOS260)에 통합했습니다. 다른 많은 인코더 및 플레이어 공급업체도 동일한 작업을 수행했습니다.
Low Latency HLS 또는 DASH용 Low Latency 또는 둘 다를 구현하기로 선택했는지 여부에 관계없이 기존 HLS 및/또는 DASH 제공 아키텍처로부터의 전환은 상대적으로 원활하고 저렴해야 합니다.
5. 실시간 커뮤니케이션
WebRTC는 일반적으로 인코더, 플레이어 및 전달 인프라를 포함하는 통합 패키지의 엔진입니다. WebRTC 기반 대규모 스트리밍 솔루션의 예로는 Phenix의 Real Time , Limelight Realtime Streaming , CoSMo Software 및 Influxis의 Millicast가 있습니다(그림 3). Wowza Streaming Engine , CoSMO Software 및 Red 5 Pro Server 와 같은 도구에서 WebRTC 기술에 액세스할 수도 있습니다 . 이 등급 기술의 지연 시간은 스트림의 71%(Phenix)에서 0.5초, 500밀리초 미만(Red5 Pro), 1초 미만(Limelight)까지 다양합니다. 2초 미만의 대기 시간이 필요한 경우 WebRTC를 고려해야 합니다.
실시간 통신이 필요한 경우 WebRTC 또는 Websockets 기반 솔루션을 구현해야 할 수 있습니다. WebRTC는 브라우저 간 통신을 위해 만들어졌으며 Android, iOS, Chrome OS, Firefox OS, Tizen 3.0 및 BlackBerry 10의 모든 주요 데스크톱 브라우저에서 지원되므로 이러한 플랫폼에서 다운로드 없이 실행되어야 합니다. 이름에서 알 수 있듯이 WebRTC는 피어 투 피어 또는 서버 투 피어로 각 시청자에게 라이브 스트림을 전달하기 위한 프로토콜입니다.
WebSockets is a real-time protocol that creates and maintains a persistent connection between a server and client that either party can use to transmit data. This connection can be used to support both video delivery and other communications so are convenient if your application needs interactivity. Like WebRTC implementations, services that use WebSockets are typically offered as a service that includes player and CDN, and you can use any encoder that can transport streams to the server via RTMP or WebRTC. Examples include Nanocosmos’ nanoStream Cloud and Wowza’s Streaming Cloud With Ultra Low Latency. Wowza claims sub-3 second latency for their solution while Nanocosmos claims around one second, glass to glass.
Other Low Latency Technologies
There is a fourth category of products best called “other” that use different technologies to provide low latency. This category includes THEO Technologies High Efficiency Streaming Protocol (HESP), a proprietary HTTP adaptive streaming protocol that according to THEO delivers sub 100-millisecond latency while reducing bandwidth by about 10% as compared to other low-latency technologies. HESP uses standard encoders and CDNs but requires custom support in the packager and player (Figure 4). You can read more about HESP in a white paper available for download, here.
Here are a list of questions you should consider when deciding which low-latency technology to implement and how to do so.
Build or Buy?
If you implement the technology yourself, be sure to answer all the questions listed below before choosing a technology. If you’re choosing a service provider, use them to compare the different service providers.
Are you choosing a standard or a partner?
We’ve outlined the different technologies for achieving low latency above, but implementations vary from service provider to service provider. So, not all LL HLS implementation will incorporate ABR delivery, at least not at first. Most traditional broadcast-like applications will likely migrate towards HTTP-based standards like low latency HLS/DASH/CMAF while applications requiring ultra-low latency like betting and auctions will gravitate towards the other technologies. In either case, when choosing a service provider it’s more important to determine if they can meet your technological and business goals than which technology they actually implement.
Can it scale and at what cost?
One of the advantages of HTTP-based technologies is that they scale at standard pricing using most CDNs. In contrast, most WebRTC and WebSocket-based technologies require a dedicated delivery infrastructure implemented by the service provider. For this reason, non-HTTP-based services can be more expensive to deliver than HLS/DASH/CMAF. When comparing service providers, ascertain the soup to nuts cost of the event, including ingress, transcoding, bandwidth, VOD file creation, one-time or per-event configurations, and the like.
Implementation-related issues?
Ask the following questions related to implementing and using the technology.
- What’s the latency achievable at a scale relevant to your audience size and geographic distribution?
- 품질 제한이 있습니까 ? 일부 기술은 특정 최대 해상도 또는 H.264 프로필로 제한될 수 있습니다.
- 패킷이 방화벽을 통과합니까? HTTP 기반 시스템은 방화벽 친화적인 HTTP 프로토콜을 사용합니다. 다른 사람들은 방화벽을 자동으로 통과하지 못할 수도 있는 UDP를 사용합니다. UDP인 경우 차단된 시청자에게 전달할 백채널이 있습니까?
- 어떤 플랫폼이 지원되나요? 컴퓨터와 모바일 기기가 있겠지만 STB, 동글, OTT 기기, 스마트 TV는 어떨까요?
- 목표 시청자 수에 맞게 시스템을 확장할 수 있습니까? CDN 인프라는 비공개이며, 그렇다면 모든 관련 시장의 모든 관련 시청자에게 제공할 수 있습니까? 스케일링의 예상 비용은 얼마입니까?
- 자신의 플레이어를 사용할 수 있습니까, 아니면 시스템의 플레이어를 사용해야 합니까? 귀하의 경우 어떤 변경이 필요하며 비용은 얼마입니까?
- 모바일 재생에 필요한 것은 무엇입니까? 스트림이 브라우저에서 재생됩니까, 아니면 앱이 필요합니까? 필요한(또는 바람직한) 앱이 있는 경우 SDK를 사용할 수 있습니까?
- 시스템에서 사용할 수 있는 인코더는 무엇입니까? 대부분은 클라우드 트랜스코더에 대한 RTMP 연결을 지원할 수 있는 인코더를 사용해야 하지만 다른 프로토콜이 필요한지 확인해야 합니다.
- 콘텐츠를 VOD에 재사용할 수 있습니까? 아니면 다시 인코딩해야 합니까? 합리적인 인코딩 사다리로 트랜스코딩하는 데 비디오 시간당 약 $20의 비용이 들지만 빈번한 방송에는 비용이 많이 들기 때문에 큰 문제는 아닙니다.
- 중복 옵션은 무엇이며 비용은 얼마입니까? 미션 크리티컬 브로드캐스트의 경우 이벤트 중에 시스템 구성 요소가 다운될 경우 인코딩/브로드캐스트 워크플로를 복제하는 방법을 알고 싶을 것입니다. 이 중복성이 지원되며 비용은 얼마입니까?
어떤 기능을 사용할 수 있으며 어떤 규모로 제공됩니까?
다음을 포함할 수도 있고 포함하지 않을 수도 있는 다양한 공급업체의 다양한 기능 제공이 있을 것입니다.
- ABR 스트리밍 - 얼마나 많은 스트림이 있으며 관련 비트 전송률 또는 해상도 제한이 있습니까?
- DVR 기능은 어떻습니까? 시청자가 콘텐츠 손실 없이 재생을 중지했다가 다시 시작할 수 있습니까?
- 비디오 동기화 - 시스템이 모든 뷰어를 스트림의 동일한 지점으로 동기화할 수 있습니까? 스트림은 위치 및 장치를 이동할 수 있으며 이 기능이 없으면 일부 연결의 사용자가 경매 또는 도박에 유리할 수 있습니다.
- 어떤 콘텐츠 보호를 사용할 수 있습니까? 프리미엄 콘텐츠 제작자라면 진정한 DRM이 필요할 수 있습니다. 다른 사람들은 인증 또는 기타 유사한 기술을 사용할 수 있습니다.
- 자막을 사용할 수 있나요? 캡션은 일부 방송에서는 법적으로 요구되지만 일반적으로 모두에게 유익합니다.
- 광고 삽입 또는 기타 수익 창출 스키마는 어떻습니까? 기술/서비스 공급자가 이를 지원합니까?
일반적으로 5~6초 범위의 방송 시간을 맞추거나 이기고자 하는 스트리밍 상점이라면 표준 기반 HTTP 기술이 가장 좋은 방법일 것입니다. 콘텐츠 보호, 캡션, 수익 창출 등 현재 사용 중입니다. 대기 시간이 훨씬 더 짧은 애플리케이션이 있는 경우 WebRTC 또는 Websockets 기반 솔루션이나 독점 HTTP 기술이 필요할 수 있습니다. 두 경우 모두 위에 나열된 질문을 하면 귀하의 필요에 가장 잘 맞는 기술 및/또는 서비스 공급자를 식별하는 데 도움이 됩니다.