Düşük gecikmeli akış ortamı çözümlerini anlama

Düşük gecikme, medyada evrensel bir özlemdir. Wowza gibi bir şirket, düşük gecikmeli akış teknolojilerini açıklamak için mükemmel bir tablo oluşturduğunda , onlara şapka çıkarmalı ve tabloyu atıfta bulunarak ve bazı küçük değişikliklerle kullanmalısınız. Söz konusu grafiği Şekil 1 olarak sunuyorum; Eklediğim vurgulanan sayıların belirttiği sırayla tartışalım.

1. Düşük Gecikme Başvuruları

Hepimizin aynı sayfada olduğundan emin olmak için, canlı akış bağlamındaki gecikme, camdan cama gecikme anlamına gelir. İlk cam, gerçek canlı etkinlikteki kamera, ikincisi ise izlediğiniz ekrandır. Gecikme, kamerada görünmesi ile telefonunuzda görünmesi arasındaki gecikmedir. Gecikmeye katkıda bulunan faktörler, kodlama süresi (olayda), buluta taşıma süresi, bulutta kod dönüştürme süresi (kodlama merdivenini oluşturmak için), teslim süresi ve kritik olarak, oynatıcınızın oynamaya başlamadan önce kaç saniye ara belleğe aldığı gibi faktörlerdir.

Üst katman, tipik uygulamaları ve gecikme gereksinimlerini gösterir. Düşük gecikme ve neredeyse gerçek zamanlı gecikme nedeniyle eksik olan popüler uygulamalar, kumar ve açık artırma siteleridir.

Teknoloji tartışmamıza dalmadan önce, canlı yayınınızın gecikme süresi ne kadar düşükse, yayının bant genişliği kesintilerine karşı o kadar az dayanıklı olduğunu anlayın. Örneğin, varsayılan ayarlar kullanıldığında, bir HLS akışı 15+ saniyelik kesintili bant genişliği boyunca oynatılır ve bu noktada geri yüklenirse izleyici bir sorun olduğunu asla anlayamayabilir. Buna karşılık, düşük gecikmeli bir akış, bir kesintinin hemen ardından oynatmayı durdurur. Bu nedenle, düşük gecikmeli başlatma süresinin avantajı, oynatma sırasındaki duraklamaların olumsuzluğuna karşı her zaman dengelenmelidir. Kesinlikle düşük gecikmeye ihtiyacınız yoksa, onu elde etmek için esneklikten ödün vermeye değmeyebilir.

Bununla birlikte, gecikmeyi aşağıdaki gibi üç kategoriye ayırmakta fayda var.

• Olması güzel - Daha hızlı olmak her zaman daha iyidir, ancak bir Eğitim Kurulu toplantısını veya lise futbol maçını canlı yayınlıyorsanız, özellikle birçok izleyici düşükte izliyorsa akış sağlamlığının düşük gecikmeden daha önemli olduğuna karar verebilirsiniz. bit hızı bağlantıları.
• Rekabet avantajı - Bazı durumlarda, düşük gecikme, rekabet avantajı sağlar veya yavaş gecikme, rekabet açısından dezavantaj anlamına gelir. Tabloda, kablo TV için tipik gecikme süresinin yaklaşık beş saniye olduğunu göreceksiniz. Akış hizmetiniz kabloyla rekabet ediyorsa, mütevazı bir rekabet avantajı sağlayan daha düşük gecikmeyle bu aralıkta olmanız gerekir.
• Gerçek zamanlı iletişim - Bir kumar veya müzayede sitesiyseniz veya uygulamanız gerçek zamanlı iletişim gerektiriyorsa, kesinlikle düşük gecikme sağlamanız gerekir.

• Canlı yayın karşılaştırma kılavuzu
• Codec bileşeninin başarısı nasıl tahmin edilir?

Artık kategorileri öğrendiğimize göre, gereken düşük gecikme düzeyini sağlamanın en etkili yoluna bakalım.

2/3 Gecikmenin Düşük Olması Güzel

2 rakamı, Apple HLS ve MPEG-DASH'in varsayılan ayarları kullanılarak dağıtılmasının yaklaşık 30 saniye gecikmeyle sonuçlandığını gösterir. Rakamlar basit; on saniyelik segment boyutları kullanırsanız ve oynatma başlamadan önce üç segmentin oynatıcı arabelleğinde olmasını gerektiriyorsa, otuz saniyeye gelmişsinizdir. Gerçekte, Apple birkaç yıl önce gereksinimlerini on saniyeden altı saniyeye değiştirdi ve çoğu DASH üreticisi 4-6 saniyelik segmentler kullanıyor, bu nedenle varsayılan sayı gerçekten 20 saniyeye yakın.

Yine de 3 numara, HLS Ayarlı ve DASH Ayarlı, yaklaşık 6-8 saniyelik gecikme gösterir. Özünde ayarlama, 10 saniyelik dilimlerden 2 saniyelik dilimlere geçmek anlamına gelir ve bu, aynı matematiği uygulayarak 6-8 saniyelik gecikme sağlar. Bu nedenle, gecikmenin olması güzel olduğunda, geliştirme süresi veya maliyeti olmadan veya teslim edilebilirlik riskini önemli ölçüde artırmadan gecikmeyi önemli ölçüde azaltabilirsiniz.

4. Rekabet Avantajı - Düşük Gecikmeli HTTP Teknolojileri

Bir rekabet avantajı olarak düşük gecikmeye ihtiyaç duyulduğunda, yalnızca segment boyutlarını azaltmak bunu yapmayacaktır; gerçek bir düşük gecikmeli teknoloji uygulamanız gerekecek. Burada iki sınıf vardır; DASH için Düşük Gecikmeli HLS ve Düşük Gecikmeli CMAF gibi HTTP teknolojileri ve WebSockets ve WebRTC gibi diğer teknolojilere dayalı çözümler.

Bu sınıftaki uygulamalara sahip çoğu üretici için, düşük gecikmeli HTTP teknolojileri uygun fiyat, geriye dönük uyumluluk, esneklik ve özellik setinin en iyi karışımını sunar. Bu nedenle, bu bölümde DASH için Düşük Gecikmeli HLS ve Düşük Gecikmeli CMAF'yi ve bir sonraki bölümde diğer teknolojileri ele alacağım.

Tüm HLS/DASH/CMAF tabanlı düşük gecikmeli sistemler, Şekil 2'de gösterildiği gibi aynı temel yolla çalışır. Yani, tipik olarak 6-10 saniye süren (Şekil 2'nin üst kısmı) tam bir segment kodlanana kadar beklemek yerine , kodlayıcı, tamamlanır tamamlanmaz CDN'ye aktarılan çok daha kısa parçalar oluşturur (Şekil 2'nin alt kısmı).

Örnek olarak, kodlayıcınız altı saniyelik bölümler üretiyorsa en az altı saniyelik gecikmeniz olur; Oynatma başlamadan önce izleyici tarafından normal üç bölümün alınması gerekiyorsa bunun üç katı. Bununla birlikte, kodlayıcınız parçaları her 200 milisaniyede bir dışarı ittiyse ve oynatıcı oynatmayı hemen başlatacak şekilde yapılandırıldıysa, gecikme çok çok daha az olacaktır. Bu şemanın önemli faydalarından biri geriye dönük uyumluluktur; Segmentler hala oluşturulmakta olduğundan, düşük gecikmeli şemayla uyumlu olmayan oyuncular, daha uzun gecikmeyle de olsa segmentleri oynatabilmelidir. Bu bölümler, canlı akıştan VOD sunumları için de anında kullanılabilir.

Bu avantajların ötesinde, düşük gecikmeli HTTP teknolojileri, WebRTC ve WebSockets tabanlı teknolojilerde evrensel olarak desteklenmeyen şifreleme, reklam ekleme ve altyazı dahil olmak üzere normal gecikmeli kardeşlerinin özelliklerinin çoğunu destekler. Geliştirme ve diğer teknoloji maliyetlerini en aza indirerek, seçtiğiniz düşük gecikmeli teknolojiyi muhtemelen mevcut yürütücü ve dağıtım altyapınızı kullanarak uygulayabilirsiniz.

Bir HTTP Düşük Gecikme Teknolojisini Seçme

HTTP Adaptive Streaming, HLS ve DASH için iki ana standart ve ayrıca birleştirici bir kapsayıcı biçimi olan CMAF vardır. Apple, Düşük Gecikmeli HLS (yeni sekmede açılır) çözümünü duyurduktan sonra, birkaç temel çabanın yerini anında aldı ve HLS'ye düşük gecikme sağlamak için tercih edilen teknoloji haline geldi. Spesifikasyon hala nispeten yeni olmasına rağmen, Nimble Streamer ürünleri ile Wowza ve WMSPanel gibi teknoloji sağlayıcıları tarafından zaten destekleniyor .

Düşük gecikmeli DASH için bir DVB standardı vardır ve DASH Endüstri Forumu , bir sonraki Birlikte Çalışabilirlik yönergelerine dahil edilmek üzere DASH için birkaç Düşük Gecikmeli Modu onayladı . Tüm bu spesifikasyonlara uygun olarak, kodlayıcı ve oynatıcı geliştiricileri ve içerik dağıtım ağları, tüm DASH/CMAF düşük gecikmeli uygulamalarının çalışır durumda olması için birlikte çalışabilirliği sağlamak için birkaç yıldır çalışıyor.

Örnek olarak, Harmonic ve Akamai birlikte, NAB ve IBC 2017'ye kadar uzanan düşük gecikmeli CMAF'yi gösterdiler ve beş saniyenin altında gecikmeyle canlı OTT teslimatını gösterdiler. O zamandan beri Harmonic, düşük gecikme süreli DASH işlevselliğini cihaz tabanlı ürünlerine (Packager XOS ve Electra XOS) ve SaaS çözümlerine (VOS Cluster ve VOS260) entegre etti. Diğer birçok kodlayıcı ve oynatıcı satıcısı da aynı şeyi yaptı.

DASH için Düşük Gecikmeli HLS veya Düşük Gecikmeli uygulamayı veya her ikisini birden uygulamayı seçseniz de, mevcut HLS ve/veya DASH dağıtım mimarinizden geçiş nispeten sorunsuz ve ucuz olmalıdır.

5. Gerçek Zamanlı İletişim

WebRTC is typically the engine for an integrated package that includes the encoder, player, and delivery infrastructure. Examples of WebRTC-based large scale streaming solutions include Real Time from Phenix, Limelight Realtime Streaming, and Millicast from CoSMo Software and Influxis (Figure 3). You can also access WebRTC technology in tools like the Wowza Streaming Engine, CoSMO Software, and Red 5 Pro Server. Latency times for technologies in this class range from .5 seconds for 71% of the streams (Phenix), under 500 milliseconds (Red5 Pro), to under one-second (Limelight). If you need sub-two second latency, WebRTC is an option you need to consider.

Gerçek zamanlı iletişime ihtiyacınız varsa, muhtemelen WebRTC veya Websockets tabanlı bir çözüm uygulamanız gerekecektir. WebRTC, tarayıcıdan tarayıcıya iletişim için formüle edildi ve Android, iOS, Chrome OS, Firefox OS, Tizen 3.0 ve BlackBerry 10'daki tüm büyük masaüstü tarayıcıları tarafından destekleniyor, bu nedenle bu platformların hiçbirinde indirme olmadan çalışmalıdır. Adından da anlaşılacağı gibi WebRTC, eşler arası veya sunucular arası her izleyiciye canlı akış sağlamak için kullanılan bir protokoldür.

WebSockets, her iki tarafın da veri iletmek için kullanabileceği bir sunucu ile istemci arasında kalıcı bir bağlantı oluşturan ve sürdüren gerçek zamanlı bir protokoldür. Bu bağlantı, hem video dağıtımını hem de diğer iletişimleri desteklemek için kullanılabilir; bu nedenle, uygulamanızın etkileşime ihtiyacı varsa kullanışlıdır. WebRTC uygulamaları gibi, WebSockets kullanan hizmetler de genellikle oynatıcı ve CDN içeren bir hizmet olarak sunulur ve akışları RTMP veya WebRTC aracılığıyla sunucuya taşıyabilen herhangi bir kodlayıcıyı kullanabilirsiniz. Örnekler arasında Nanocosmos'un nanoStream Cloud'u ve Wowza'nın Ultra Düşük Gecikmeli Akış Bulutu yer alır . Wowza, çözümü için 3 saniyenin altında gecikme olduğunu iddia ederken, Nanocosmos camdan cama yaklaşık bir saniye olduğunu iddia ediyor.

Diğer Düşük Gecikmeli Teknolojiler

Düşük gecikme sağlamak için farklı teknolojiler kullanan ve en iyi "diğer" olarak adlandırılan dördüncü bir ürün kategorisi vardır. Bu kategori, THEO'ya göre diğer düşük gecikmeli teknolojilere kıyasla bant genişliğini yaklaşık %10 oranında azaltırken 100 milisaniyenin altında gecikme sağlayan tescilli bir HTTP uyarlamalı akış protokolü olan THEO Technologies Yüksek Verimli Akış Protokolünü (HESP) içerir. HESP, standart kodlayıcılar ve CDN'ler kullanır ancak paketleyici ve oynatıcıda özel destek gerektirir (Şekil 4). HESP hakkında daha fazla bilgiyi buradan indirebileceğiniz teknik incelemede okuyabilirsiniz .

Hangi düşük gecikmeli teknolojinin uygulanacağına ve bunun nasıl yapılacağına karar verirken göz önünde bulundurmanız gereken soruların bir listesi aşağıda verilmiştir.

İnşa mı Satın mı?

Teknolojiyi kendiniz uyguluyorsanız, bir teknoloji seçmeden önce aşağıda listelenen tüm soruları yanıtladığınızdan emin olun. Bir hizmet sağlayıcı seçiyorsanız, farklı hizmet sağlayıcıları karşılaştırmak için bunları kullanın.

Bir standart mı yoksa ortak mı seçiyorsunuz?

Yukarıda düşük gecikme elde etmek için farklı teknolojileri özetledik, ancak uygulamalar hizmet sağlayıcıdan hizmet sağlayıcıya değişir. Bu nedenle, tüm LL HLS uygulamaları, en azından ilk başta ABR dağıtımını içermeyecektir. Geleneksel yayın benzeri uygulamaların çoğu muhtemelen düşük gecikme süreli HLS/DASH/CMAF gibi HTTP tabanlı standartlara geçerken, bahis ve müzayede gibi ultra düşük gecikme gerektiren uygulamalar diğer teknolojilere yönelecektir. Her iki durumda da, bir hizmet sağlayıcı seçerken, gerçekte hangi teknolojiyi uyguladıklarından çok teknolojik ve iş hedeflerinizi karşılayıp karşılayamayacaklarını belirlemek daha önemlidir.

Ölçeklenebilir mi ve ne pahasına?

HTTP tabanlı teknolojilerin avantajlarından biri, çoğu CDN kullanılarak standart fiyatlandırmada ölçeklendirilmeleridir. Buna karşılık, WebRTC ve WebSocket tabanlı teknolojilerin çoğu, hizmet sağlayıcı tarafından uygulanan özel bir dağıtım altyapısı gerektirir. Bu nedenle, HTTP tabanlı olmayan hizmetlerin sağlanması HLS/DASH/CMAF'tan daha pahalı olabilir. Hizmet sağlayıcıları karşılaştırırken, giriş, kod dönüştürme, bant genişliği, VOD dosyası oluşturma, tek seferlik veya olay başına yapılandırmalar ve benzerleri dahil olmak üzere olayın çorbadan kuruyemiş maliyetini belirleyin.

Uygulamayla ilgili sorunlar?

Teknolojiyi uygulama ve kullanma ile ilgili aşağıdaki soruları sorun.

• Hedef kitlenizin büyüklüğü ve coğrafi dağılımıyla alakalı bir ölçekte elde edilebilecek gecikme süresi nedir?
• Herhangi bir kalite sınırlaması var mı - bazı teknolojiler belirli maksimum çözünürlükler veya H.264 profilleri ile sınırlı olabilir.
• Paketler bir güvenlik duvarından geçecek mi? HTTP tabanlı sistemler, güvenlik duvarı dostu olan HTTP protokollerini kullanır. Diğerleri, güvenlik duvarlarından otomatik olarak geçemeyen UDP kullanır. UDP ise, engellenen izleyicilere iletilecek herhangi bir arka kanal var mı?
• Hangi platformlar desteklenir? Muhtemelen bilgisayarlar ve mobil cihazlar, peki ya STB'ler, dongle'lar, OTT cihazları ve akıllı TV'ler?
• Sistem, hedef izleyici sayılarınızı karşılayacak şekilde ölçeklenebilir mi? CDN altyapısı özel midir ve öyleyse, tüm ilgili pazarlardaki tüm ilgili izleyicilere teslim edebilir mi? Ölçeklendirmenin beklenen maliyetleri nelerdir?
• Kendi oynatıcınızı kullanabilir misiniz yoksa sistemin oynatıcısını mı kullanmak zorundasınız? Kendinize aitse, hangi değişiklikler gereklidir ve bunun maliyeti nedir?
• Mobil oynatma için ne gerekiyor? Akışlar bir tarayıcıda mı oynatılacak yoksa bir uygulama gerekli mi? Gerekli (veya arzu edilen) bir uygulama varsa, SDK'lar mevcut mu?
• Sistem hangi kodlayıcıları kullanabilir? Çoğu, bulut kod çözücüye RTMP bağlantılarını destekleyebilen herhangi bir kodlayıcı kullanmalıdır, ancak başka protokollerin gerekli olup olmadığını kontrol edin.
• İçerik, VOD için yeniden kullanılabilir mi yoksa yeniden kodlama gerekecek mi? Videonun kodunu makul bir kodlama merdivenine dönüştürmenin saatte yaklaşık 20 ABD dolarına mal olması, ancak sık yapılan yayınlar için pahalı olması nedeniyle büyük bir anlaşma değil.
• Fazlalık seçenekleri nelerdir ve maliyetleri nelerdir? Görev açısından kritik yayınlar için, olay sırasında herhangi bir sistem bileşeni arızalanırsa kodlama/yayın iş akışının nasıl kopyalanacağını bilmek isteyeceksiniz. Bu fazlalık destekleniyor mu ve maliyeti nedir?

Hangi özellikler mevcut ve hangi ölçekte?

Aşağıdakileri içerebilecek veya içermeyebilecek, farklı satıcılardan çok çeşitli özellik teklifleri olacaktır:

• ABR akışı - kaç akış var ve ilgili bit hızı veya çözünürlük sınırlamaları var mı?
• Peki ya DVR özellikleri? İzleyiciler herhangi bir içeriği kaybetmeden oynatmayı durdurabilir ve yeniden başlatabilir mi?
• Video senkronizasyonu - Sistem, tüm izleyicileri akışta aynı noktaya senkronize edebilir mi? Akışlar, konumlar ve cihazlar üzerinde sürüklenebilir ve bu yetenek olmadan, bazı bağlantılardaki kullanıcılar açık artırma veya kumar için avantaj elde edebilir.
• Hangi içerik koruması mevcuttur? Birinci sınıf bir içerik üreticisiyseniz, gerçek DRM'ye ihtiyacınız olabilir. Diğerleri, kimlik doğrulama veya diğer benzer tekniklerle idare edebilir.
• Altyazılar mevcut mu? Altyazılar, bazı yayınlar için yasal olarak zorunludur, ancak genel olarak herkes için faydalıdır.
• Reklam ekleme veya diğer para kazanma şeması ne olacak? Teknoloji/hizmet sağlayıcı bunu destekliyor mu?

Genel olarak, 5 ila 6 saniyelik aralıkta yayın sürelerini karşılamak veya geçmek isteyen bir akış mağazasıysanız, standart tabanlı bir HTTP teknolojisi muhtemelen en iyi seçiminizdir, çünkü sizinle aynı özellik setini desteklemeye en yakın olacaktır. şu anda içerik koruması, altyazılar ve para kazanma gibi özellikleri kullanıyoruz. Çok daha düşük gecikme gerektiren bir uygulamanız varsa, muhtemelen WebRTC veya Websockets tabanlı bir çözüme veya tescilli bir HTTP teknolojisine ihtiyacınız olacaktır. Her iki durumda da, yukarıda listelenen soruları sormak, ihtiyaçlarınızı en iyi şekilde karşılayan teknolojiyi ve/veya hizmet sağlayıcıyı belirlemenize yardımcı olacaktır.