Matala viive on yleinen pyrkimys mediassa. Kun Wowzan kaltainen yritys tuottaa täydellisen kaavion selittämään matalaviiveisiä suoratoistotekniikoita, sinun on otettava hattu heille ja käytettävä kaaviota attribuutiolla ja pienillä muutoksilla. Esitän mainitun kaavion kuviona 1; keskustellaan lisättyjen korostettujen numeroiden osoittamassa järjestyksessä.
1. Alhaisen viiveen sovellukset
TUOTEOPAS
Parhaat PTZ-kamerat suoratoistoa varten
Vain varmistaaksemme, että olemme kaikki samalla sivulla, viiveaika suoratoiston yhteydessä tarkoittaa lasista lasiin -viivettä. Ensimmäinen lasi on varsinaisen live-tapahtuman kamera, toinen on katselemasi näyttö. Viive on viive kameran ilmestymisen ja puhelimen näkymisen välillä. Latenssiin vaikuttavat tekijät, kuten ajan koodaus (tapahtumassa), kuljetusaika pilveen, transkoodaamisaika pilvessä (koodausportaiden luomiseksi), toimitusaika ja kriittisesti se, kuinka monta sekuntia pelaaja puskuroi ennen pelaamisen aloittamista.
Yläkerros näyttää tyypilliset sovellukset ja niiden viivevaatimukset. Suosittuja sovelluksia, joista puuttuu matala viive ja lähes reaaliaikainen viive, ovat uhkapeli- ja huutokauppasivustot.
Ennen kuin sukellat tekniikkakeskusteluihimme, ymmärrä, että mitä alhaisempi suoratoiston viive, sitä vähemmän joustava virta on kaistanleveyden keskeytyksiin. Esimerkiksi oletusasetuksia käyttämällä HLS-virta toistetaan yli 15 sekunnin ajan keskeytetyllä kaistanleveydellä, ja jos se palautetaan siinä vaiheessa, katsoja ei ehkä koskaan tiedä, että ongelmassa oli. Sen sijaan matalaviiveinen virta lopetetaan melkein heti keskeytyksen jälkeen. Joten matalan latenssin käynnistysajan edut on aina tasapainotettava toiston pysähtymisten negatiivisuuteen. Jos et tarvitse ehdottomasti matalaa viivettä, ei ehkä kannata uhrata joustavuutta sen saamiseksi.
Tästä huolimatta on hyödyllistä jakaa viive kolmeen luokkaan seuraavasti.
PRO-UUTISKIRJEÄäni + Video + IT. Toimittajamme ovat asiantuntijoita audio / video ja IT-integroinnissa. Hanki päivittäisiä oivalluksia, uutisia ja ammattimaista verkostoitumista. Tilaa Pro AV tänään.
- Kiva omistaa - Nopeampi on aina parempi, mutta jos suoratoistat suoratoistoa Board of Education -kokouksesta tai lukion jalkapallopeleistä, voit päättää, että suoratoisto on tärkeämpää kuin matala viive, varsinkin jos monet katsojat katsovat matalan bittinopeuden yhteyksiä.
- Kilpailuetu - Joissakin tapauksissa matala viive tarjoaa kilpailuedun, tai hidas viivästys kilpailuetua. Huomaa kaaviossa, että kaapeli-tv: n tyypillinen viive on noin viisi sekuntia. Jos suoratoistopalvelusi kilpailee kaapelin kanssa, sinun on oltava tällä alueella, ja pienempi viive tarjoaa vaatimattoman kilpailuedun.
- Reaaliaikainen viestintä - Jos olet uhkapeli- tai huutokauppasivusto tai jos sovelluksesi vaatii muuten reaaliaikaista viestintää, sinun on ehdottomasti toimitettava pieni viive.
- Suoratoiston suoratoiston vertailuopas
- Kuinka ennustaa koodekin menestys
Nyt kun tiedämme luokat, katsotaanpa tehokkain tapa tuottaa tarvittava matalan viiveen taso.
2/3 Mukava olla matala latenssi
Numero 2 osoittaa, että Apple HLS ja MPEG-DASH, jotka on otettu käyttöön oletusasetuksillaan, viivästyvät noin 30 sekunnissa. Numerot ovat yksinkertaisia; Jos käytät kymmenen sekunnin segmenttikokoja ja tarvitset kolmen segmentin olevan soittimen puskurissa ennen toiston aloittamista, olet 30 sekunnissa. Todellisuudessa Apple muutti vaatimuksiaan kymmenestä sekunnista kuudeksi sekunniksi muutama vuosi sitten, ja useimmat DASH-tuottajat käyttävät 4-6 sekunnin segmenttejä, joten oletusluku on todella lähempänä 20 sekuntia.
Silti numero 3, HLS Tuned ja DASH Tuned, näyttää viiveen noin 6-8 sekuntia. Pohjimmiltaan, viritys tarkoittaa siirtymistä 10 sekunnin segmenteistä 2 sekunnin segmenteiksi, jotka soveltavat samaa matematiikkaa, antavat 6-8 sekunnin viiveen. Joten kun viive on mukava saada, voit vähentää viivästystä dramaattisesti ilman kehitysaikaa tai kustannuksia tai merkittävästi lisääntynyttä toimitusriskiä.
4. Kilpailuetu - matalan viiveen HTTP-tekniikat
Kun matalaa viivettä tarvitaan kilpailueduksi, segmenttien kokojen leikkaaminen ei onnistu; sinun on toteutettava todellinen matalaviiveinen tekniikka. Tässä on kaksi luokkaa; HTTP-tekniikat, kuten matalan viiveen HLS ja matalan viiveen CMAF DASH: lle, sekä muihin tekniikoihin perustuvat ratkaisut, kuten WebSockets ja WebRTC.
Useimmille tuottajille, joilla on tämän luokan sovelluksia, matalaviiveiset HTTP-tekniikat tarjoavat parhaan yhdistelmän kohtuuhintaisuutta, taaksepäin yhteensopivuutta, joustavuutta ja ominaisuusjoukkoja. Joten katan DASH: n matalaviiveisen HLS: n ja matalaviiveisen CMAF: n tässä osiossa ja muut tekniikat seuraavassa.
Kaikki HLS / DASH / CMAF-pohjaiset matalaviiveiset järjestelmät toimivat samalla tavoin, kuten kuvassa 2 on. Eli sen sijaan, että odotettaisiin, kunnes täydellinen segmentti koodataan, mikä kestää tyypillisesti 6-10 sekuntia (kuvan 2 yläosa) , kooderi luo paljon lyhyempiä palasia, jotka siirretään CDN: ään heti niiden valmistuttua (kuvan 2 alaosa).
Esimerkiksi, jos kooderi tuottaa kuuden sekunnin segmenttejä, sinulla on vähintään kuuden sekunnin viive; kolminkertainen, jos katsojan vaaditaan vastaanottavan kolme normaalia segmenttiä ennen toiston aloittamista. Jos kooderi kuitenkin työnsi palasia 200 millisekunnin välein ja soitin määritettiin aloittamaan toisto välittömästi, latenssin tulisi olla paljon, paljon vähemmän. Yksi tämän skeeman tärkeimmistä eduista on taaksepäin yhteensopivuus; koska segmenttejä luodaan edelleen, pelaajien, jotka eivät ole yhteensopivia matalaviiveisen skeeman kanssa, pitäisi silti pystyä toistamaan segmenttejä, vaikkakin pidemmällä viiveellä. Nämä segmentit ovat myös heti saatavilla VOD-esityksiä varten suorasta striimistä.
Näiden etujen lisäksi matalaviiveiset HTTP-tekniikat tukevat useimpien normaalien viiveiden sisarustensa ominaisuuksia, mukaan lukien salaus, mainosten lisääminen ja tekstitys, joita ei yleisesti tueta WebRTC- ja WebSockets-pohjaisissa tekniikoissa. Voit todennäköisesti toteuttaa valitun matalaviiveisen tekniikan olemassa olevan soittimen ja jakeluinfrastruktuurin avulla minimoiden kehitys- ja muut teknologiakustannukset.
HTTP-matalaviiveisen tekniikan valitseminen
HTTP-adaptiiviselle suoratoistolle on kaksi päästandardia, HLS ja DASH, sekä yhdistävä säilömuoto, CMAF. Kun Apple ilmoitti Low Latency HLS -ratkaisustaan, se syrjäytti välittömästi useita ruohonjuuritason ponnisteluja ja siitä tuli valittu tekniikka matalan viiveen toimittamiseksi HLS: lle. Vaikka tekniset tiedot ovat vielä suhteellisen uusia, sitä tukevat jo sellaiset tekniikan toimittajat kuin Wowza ja WMSPanel Nimble Streamer -tuotteellaan.
Matala-viiveiselle DASH: lle on DVB-standardi, ja DASH-teollisuusfoorumi on hyväksynyt useita DASH: n matalaviiveisiä toimintatiloja sisällytettäviksi seuraaviin yhteentoimivuusohjeisiinsa. Kaikkien näiden eritelmien mukaisesti enkooderien ja soittimien kehittäjät ja sisällön jakeluverkostot ovat työskennelleet useita vuosia varmistaakseen yhteentoimivuuden, jotta kaikkien DASH / CMAF-matalaviiveisten sovellusten pitäisi päästä kentälle.
Esimerkkinä Harmonic ja Akamai osoittivat yhdessä matalan viiveen CMAF: n jo NAB: n ja IBC 2017: n aikana, osoittamalla suoraa OTT-toimitusta alle viiden sekunnin viiveellä. Siitä lähtien Harmonic on integroinut matalaviiveisen DASH-toiminnallisuuden laitepohjaisiin tuotteisiinsa (Packager XOS ja Electra XOS) ja SaaS-ratkaisuihin (VOS Cluster ja VOS260). Monet muut kooderien ja soittimien toimittajat ovat tehneet saman.
Riippumatta siitä, otatko käyttöön matalan viiveen HLS: n tai matalan viiveen DASH: lle tai molemmille, siirtymisen nykyisestä HLS: stä ja / tai DASH: n toimitusarkkitehtuurista pitäisi olla suhteellisen saumaton ja edullinen.
5. Reaaliaikainen viestintä
WebRTC on tyypillisesti integroidun paketin moottori, joka sisältää kooderin, soittimen ja jakelun infrastruktuurin. Esimerkkejä WebRTC-pohjaisista laajamittaisista suoratoistoratkaisuista ovat Real Time from Phenix, Limelight Realtime Streaming ja Millicast CoSMo Software and Influxis (kuva 3). Voit käyttää WebRTC-tekniikkaa myös sellaisissa työkaluissa kuin Wowza Streaming Engine, CoSMO Software ja Red 5 Pro Server. Tämän luokan tekniikoiden latenssiajat vaihtelevat .5 sekunnista 71%: lle virroista (Phenix), alle 500 millisekunnin (Red5 Pro), alle sekuntiin (Limelight). Jos tarvitset alle kahden sekunnin viiveen, WebRTC on harkittava vaihtoehto.
Jos tarvitset reaaliaikaista viestintää, sinun on todennäköisesti toteutettava joko WebRTC- tai Websockets-pohjainen ratkaisu. WebRTC on muotoiltu selaimen ja selaimen väliseen viestintään, ja sitä tukevat kaikki suuret työpöydän selaimet, Android, iOS, Chrome OS, Firefox OS, Tizen 3.0 ja BlackBerry 10, joten sen pitäisi toimia ilman latauksia millään näistä alustoista. Kuten nimestä voi päätellä, WebRTC on protokolla suorien suoratoistojen toimittamiseksi jokaiselle katsojalle, joko vertaisverkolle tai palvelimelta toiselle.
WebSockets on reaaliaikainen protokolla, joka luo ja ylläpitää jatkuvaa yhteyttä palvelimen ja asiakkaan välillä, jota kumpikin osapuoli voi käyttää tiedonsiirtoon. Tätä yhteyttä voidaan käyttää sekä videotoimitusten että muun viestinnän tukemiseen, joten se on kätevää, jos sovelluksesi tarvitsee vuorovaikutteisuutta. Kuten WebRTC-toteutukset, WebSocketia käyttäviä palveluita tarjotaan yleensä palveluna, joka sisältää soittimen ja CDN: n, ja voit käyttää mitä tahansa kooderia, joka voi siirtää virtoja palvelimelle RTMP: n tai WebRTC: n kautta. Esimerkkejä ovat Nanocosmosin nanoStream Cloud ja Wowzan Streaming Cloud with Ultra Low Latency. Wowza väittää alle 3 sekunnin latenssin ratkaisulleen, kun taas Nanocosmos väittää noin sekunnin, lasista lasiin.
Muut matalan viiveen tekniikat
On olemassa neljäs tuoteryhmä, jota kutsutaan parhaiten nimellä “muut” ja jotka käyttävät erilaisia tekniikoita tarjoamaan matalan viiveen. Tähän luokkaan sisältyy THEO Technologies High Efficiency Streaming Protocol (HESP), oma HTTP-mukautuva suoratoistoprotokolla, joka THEO: n mukaan tuottaa alle 100 millisekunnin viiveen ja vähentää samalla kaistanleveyttä noin 10% verrattuna muihin matalaviiveisiin tekniikoihin. HESP käyttää vakiokoodereita ja CDN: itä, mutta vaatii mukautetun tuen pakkaajalla ja soittimella (kuva 4). Voit lukea lisää HESP: stä ladattavassa valkoisessa kirjassa täältä.
Tässä on luettelo kysymyksistä, jotka sinun tulisi ottaa huomioon, kun päätät matalan viiveen tekniikasta ja miten se tehdään.
Rakentaa tai ostaa?
Jos otat tekniikan käyttöön itse, muista vastata kaikkiin alla lueteltuihin kysymyksiin ennen tekniikan valitsemista. Jos valitset palveluntarjoajan, vertaa niitä eri palveluntarjoajien avulla.
Valitsetko standardin vai kumppanin?
Olemme edellä hahmotelleet eri tekniikoita matalan viiveen saavuttamiseksi, mutta toteutukset vaihtelevat palveluntarjoajittain. Joten kaikki LL HLS-toteutukset eivät sisällä ABR-toimitusta, ainakaan aluksi. Useimmat perinteiset lähetystyyppiset sovellukset siirtyvät todennäköisesti kohti HTTP-pohjaisia standardeja, kuten matalan viiveen HLS / DASH / CMAF, kun taas erittäin matalaa viivettä vaativat sovellukset, kuten vedonlyönti ja huutokaupat, etenevät kohti muita tekniikoita. Kummassakin tapauksessa palveluntarjoajaa valittaessa on tärkeämpää selvittää, pystyvätkö he saavuttamaan teknologiset ja liiketoimintatavoitteesi, kuin minkä tekniikan he todella toteuttavat.
Voiko se skaalata ja mihin hintaan?
Yksi HTTP-pohjaisten tekniikoiden eduista on, että ne skaalautuvat vakiohinnoitteluun käyttäen useimpia CDN-verkkoja. Sitä vastoin useimmat WebRTC- ja WebSocket-pohjaiset tekniikat edellyttävät palveluntarjoajan toteuttamaa erillistä toimitusinfrastruktuuria. Tästä syystä muiden kuin HTTP-pohjaisten palvelujen toimittaminen voi olla kalliimpaa kuin HLS / DASH / CMAF. Kun verrataan palveluntarjoajia, varmista keitto tapahtuman kustannuksista, mukaan lukien tunkeutuminen, koodaaminen, kaistanleveys, VOD-tiedostojen luominen, kertaluonteiset tai tapahtumakohtaiset kokoonpanot ja vastaavat.
Toteutukseen liittyvät kysymykset?
Esitä seuraavat tekniikan käyttöönottoon ja käyttöön liittyvät kysymykset.
- Mikä viive on saavutettavissa yleisön koon ja maantieteellisen jakauman kannalta merkityksellisessä mittakaavassa?
- Onko laaturajoituksia - Jotkut tekniikat voivat olla rajoitettuja tiettyihin maksimiresoluutioihin tai H.264-profiileihin.
- Kuljettavatko paketit palomuurin läpi? HTTP-pohjaiset järjestelmät käyttävät HTTP-protokollia, jotka ovat palomuuriystävällisiä. Toiset käyttävät UDP: tä, joka ei välttämättä kulje automaattisesti palomuurien läpi. Jos on UDP, onko takakanavia toimitettavaksi estetyille katsojille?
- Mitä alustoja tuetaan? Oletettavasti tietokoneet ja mobiililaitteet, mutta entä STB: t, dongles, OTT-laitteet ja älytelevisiot?
- Voiko järjestelmä skaalata vastaamaan kohdeyleisösi lukumääriä? Onko CDN-infrastruktuuri yksityinen, ja jos on, voiko se toimia kaikkien asiaankuuluvien katsojien kanssa kaikilla merkityksellisillä markkinoilla? Mitkä ovat skaalauksen odotetut kustannukset?
- Voitteko käyttää omaa soitinta vai onko sinun käytettävä järjestelmän soitinta? Jos omasi, mitä muutoksia tarvitaan ja kuinka paljon se maksaa?
- Mitä mobiililaitteiden toistoon tarvitaan? Toistetaanko suoratoistoja selaimessa vai tarvitaanko sovellusta? Jos vaaditaan (tai toivottavaa) sovellusta, ovatko SDK: t käytettävissä?
- Mitä koodereita järjestelmä voi käyttää? Useimpien tulisi käyttää mitä tahansa kooderia, joka tukee RTMP-yhteyksiä pilvitranskooderiin, mutta tarkista, tarvitaanko muita protokollia.
- Voiko sisältöä käyttää uudelleen VOD: n vai tarvitaanko koodausta uudelleen? Ei valtava juttu, koska videon muuntaminen kohtuulliseen koodaus tikkaaseen maksaa noin 20 dollaria tunnissa, mutta kallis usein lähetyksiin.
- Mitkä ovat irtisanomisvaihtoehdot ja mitkä ovat kustannukset? Tehtäväkriittisiä lähetyksiä varten sinun on tiedettävä, kuinka kopioida koodaus / lähetystyönkulku, jos jokin järjestelmän komponentti menee alas tapahtuman aikana. Onko tämä irtisanominen tuettu ja mitkä ovat kustannukset?
Mitä ominaisuuksia on saatavilla ja missä mittakaavassa?
Eri toimittajat tarjoavat laajan valikoiman ominaisuustarjouksia, jotka voivat sisältää tai eivät:
- ABR-suoratoisto - kuinka monta virtaa ja onko asiaankuuluvia bittinopeutta tai tarkkuutta koskevia rajoituksia?
- Entä DVR-ominaisuudet? Voivatko katsojat pysäyttää ja aloittaa toiston menettämättä sisältöä.
- Videon synkronointi - Voiko järjestelmä synkronoida kaikki katsojat samaan pisteeseen streamissa? Virrat voivat kulkeutua sijaintien ja laitteiden yli, ja ilman tätä mahdollisuutta joidenkin yhteyksien käyttäjillä voi olla etu huutokaupoissa tai uhkapeleissä.
- Mitä sisältösuojaa on saatavilla? Jos olet ensiluokkainen sisällöntuottaja, saatat tarvita aitoa DRM: ää. Toiset voivat tulla toimeen todennuksella tai muilla vastaavilla tekniikoilla.
- Onko tekstityksiä saatavilla? Joillekin lähetyksille vaaditaan tekstitys, mutta ne ovat yleensä hyödyllisiä kaikille.
- Entä mainonnan lisäys tai muu kaupallistamismalli? Tukeeko teknologia / palveluntarjoaja tätä?
Yleensä jos olet suoratoistomyymälä, joka haluaa tavata tai voittaa lähetysajat 5–6 sekunnin sisällä, standardipohjainen HTTP-tekniikka on todennäköisesti paras vaihtoehto, koska se on lähinnä saman ominaisuusjoukon tukemista. käytämme tällä hetkellä, kuten sisällönsuojausta, tekstityksiä ja kaupallistamista. Jos sinulla on sovellus, joka vaatii paljon pienemmän viiveen, tarvitset todennäköisesti WebRTC- tai Websockets-pohjaisen ratkaisun tai oman HTTP-tekniikan. Kummassakin tapauksessa yllä lueteltujen kysymysten esittämisen pitäisi auttaa sinua tunnistamaan tarpeisiisi parhaiten vastaava teknologia- ja / tai palveluntarjoaja.