Madal latentsus on meedias universaalne püüdlus. Kui Wowza-sugune ettevõte toodab madala latentsusega voogedastustehnoloogiate selgitamiseks ideaalse diagrammi, peate nende ees mütsi maha võtma ja kasutama graafikut koos omistamise ja mõningate väiksemate muudatustega. Esitan nimetatud diagrammi joonisel 1; arutame minu lisatud esiletõstetud numbritega määratud järjekorras.
1. Madala latentsusega rakendused
TOOTEJUHEND
Parimad PTZ-kaamerad otseülekande jaoks
Lihtsalt veendumaks, et oleme kõik ühel lehel, tähendab viivitus otseülekande kontekstis viivitust klaasist klaasi. Esimene klaas on tegeliku otseülekande kaamera, teine on ekraan, mida vaatate. Latentsus on viivitus kaamerasse ilmumise ja teie telefoni kuvamise vahel. Latentsusele aitavad kaasa sellised tegurid nagu aja (sündmusel) kodeerimine, pilve transportimise aeg, pilves oleva aja kodeerimine (kodeerimisredeli loomiseks), kohaletoimetamise aeg ja kriitiline, mitu sekundit teie mängija puhverdab enne mängima asumist.
Ülemine kiht näitab tüüpilisi rakendusi ja nende latentsusnõudeid. Populaarsed rakendused, mis puuduvad madala viivitusega ja peaaegu reaalajas latentsusega, on hasartmängude ja oksjonite saidid.
Enne meie tehnoloogiarutelusse sukeldumist mõistke, et mida väiksem on teie otseülekande latentsusaeg, seda vähem on voog ribalaiuse katkestuste suhtes vastupidavam. Näiteks vaikeseadete abil mängib HLS-voog katkematut ribalaiust vähemalt 15 sekundit ja kui see sel hetkel taastatakse, ei pruugi vaataja kunagi teada, et selles probleem oli. Seevastu madala latentsusega voog peatub pärast katkestamist peaaegu kohe. Niisiis, madala latentsusega käivitusaja kasu tuleb alati tasakaalustada taasesituse seiskamise negatiivse mõjuga. Kui te ei vaja tingimata madalat latentsusaega, ei pruugi selle saamiseks vastupanuvõimet ohverdada.
Sellest hoolimata on kasulik jagada latentsus kolme kategooriasse järgmiselt.
PRO UUDISKIRIAudio + video + IT. Meie toimetajad on eksperdid audio / video ja IT integreerimisel. Hankige igapäevaseid teadmisi, uudiseid ja professionaalset võrgustike loomist. Telli Pro AV täna.
- Tore, kui on - Kiirem on alati parem, kuid kui otse voogesitate haridusnõukogu koosolekut või keskkooli jalgpallimängu, võite otsustada, et voo robustsus on olulisem kui madal latentsus, eriti kui paljud vaatajad vaatavad madala bitikiirusega ühendusi.
- Konkurentsieelis - Mõnel juhul pakub madal latentsus konkurentsieelist või aeglane latentsus tähendab konkurentsieelist. Graafikus märkite, et kaabeltelevisiooni tüüpiline latentsusaeg on umbes viis sekundit. Kui teie voogesitusteenus konkureerib kaabli vastu, peate olema selles vahemikus ja madalama latentsusega pakkudes tagasihoidlikku konkurentsieelist.
- Reaalajas side - Kui olete hasartmängude või oksjonite sait või kui teie rakendus nõuab muul viisil reaalajas suhtlemist, peate tingimata pakkuma väikest latentsust.
- Otseülekande võrdlusjuhend
- Kuidas ennustada kodekite edukust
Nüüd, kui kategooriad on meile teada, uurime kõige tõhusamat viisi vajaliku madala latentsusega taseme pakkumiseks.
2/3 Tore, et latentsus on madal
Number 2 näitab, et nende vaikesätete abil juurutatud Apple HLS ja MPEG-DASH põhjustavad umbes 30 sekundilist viivitust. Numbrid on lihtsad; kui kasutate kümnesekundilisi segmentide suurusi ja nõuate, et mängija puhvris oleks enne taasesituse algust kolm segmenti, olete 30 sekundi kaugusel. Tegelikult muutis Apple paar aastat tagasi oma nõuded kümnelt sekundilt kuuele sekundile ja enamik DASH-i tootjaid kasutab 4–6-sekundilisi segmente, nii et vaikenumber on tõesti lähemal 20 sekundile.
Siiski näitab number 3, HLS häälestatud ja DASH häälestatud, latentsust umbes 6–8 sekundit. Sisuliselt tähendab häälestamine 10-sekundiliste segmentide vahetamist 2-sekundilisteks segmentideks, mis sama matemaatikat rakendades annab 6-8 sekundi pikkuse latentsuse. Seega, kui latentsus on tore, saate latentsust dramaatiliselt kärpida, ilma et oleks vaja arendusaega ega kulusid või oluliselt suureneks kohaletoimetamise risk.
4. Konkurentsieelis - madala latentsusega HTTP-tehnoloogiad
Kui konkurentsieelisena on vaja madalat latentsusaega, siis lihtsalt segmentide suuruste vähendamine seda ei tee; peate kasutama tõelist madala latentsusega tehnoloogiat. Siin on kaks klassi; HTTP-tehnoloogiad, nagu madala latentsusega HLS ja madala latentsusega CMAF DASH-i jaoks, ning muudel tehnoloogiatel põhinevad lahendused, nagu WebSockets ja WebRTC.
Enamiku selle klassi rakendustega tootjate jaoks pakuvad madala latentsusega HTTP-tehnoloogiad parimat segu taskukohasusest, tagurpidi ühilduvusest, paindlikkusest ja funktsioonidest. Niisiis käsitlen selles jaotises madala latentsusega HLS-i ja madala latentsusega CMAF-i DASH-i jaoks ning järgmisi tehnoloogiaid.
Kõik HLS / DASH / CMAF-põhised madala latentsusega süsteemid töötavad samal põhimõttel, nagu on näidatud joonisel 2. See tähendab, et selle asemel, et oodata täieliku segmendi kodeerimist, mis võtab tavaliselt aega 6–10 sekundit (joonise 2 ülaosa) , loob kooder palju lühemad tükid, mis kantakse CDN-i kohe, kui need on valmis (joonise 2 põhi).
Näiteks, kui teie kodeerija tootis kuuesekundilisi segmente, oleks teil latentsus vähemalt kuus sekundit; kolmekordne, kui vaataja peaks enne taasesituse algust saama kolm tavalist segmenti. Kui teie kooder lükkas tükid välja iga 200 millisekundi järel ja mängija oli konfigureeritud taasesitust kohe alustama, peaks latentsus olema palju, palju vähem. Selle skeemi üks peamine eelis on tagurpidi ühilduvus; kuna segmente alles luuakse, peaksid mängijad, kes ei ühildu madala latentsusaja skeemiga, siiski suutma segmente mängida, kuigi pikema latentsusega. Need segmendid on koheselt saadaval ka otseülekandes VOD-i esitluste jaoks.
Lisaks neile eelistele toetavad madala latentsusega HTTP-tehnoloogiad enamikku nende tavaliste latentsusega õdede-vendade funktsioonidest, sealhulgas krüpteerimist, reklaami sisestamist ja subtiitreerimist, mida WebRTC ja WebSockets-põhised tehnoloogiad üldiselt ei toeta. Tõenäoliselt saate rakendada valitud madala latentsusega tehnoloogiat, kasutades oma olemasolevat mängijat ja kohaletoimetamise infrastruktuuri, minimeerides arendus- ja muid tehnoloogiakulusid.
HTTP madala latentsusega tehnoloogia valimine
HTTP adaptiivse voogesituse jaoks on kaks peamist standardit: HLS ja DASH ning lisaks ühtlustav konteinervorming CMAF. Kui Apple teatas oma madala latentsusega HLS-lahendusest, tõrjus see koheselt mitu rohujuuretasandi jõupingutust ja sai valitud tehnoloogiaks madala latentsusajaga HLS-i edastamiseks. Kuigi spetsifikatsioon on veel suhteliselt uus, toetavad seda juba sellised tehnoloogia pakkujad nagu Wowza ja WMSPanel oma Nimble Streameri tootega.
Madala latentsusega DASH-i jaoks on olemas DVB standard ja DASH-i tööstusfoorum on heaks kiitnud mitmed DASH-i madala latentsusega režiimid nende järgmiste koostalitlusvõime suuniste lisamiseks. Kõigi nende spetsifikatsioonide kohaselt on kodeerijate ja mängijate arendajad ning sisu edastusvõrgud juba mitu aastat töötanud koostalitlusvõime tagamise nimel, et kõik DASH / CMAF madala latentsusajaga rakendused peaksid toimima.
Näitena näitasid Harmonic ja Akamai koos madala latentsusega CMAF-i juba NAB-i ja IBC 2017-ni, näidates OTT-i otseülekannet alla viie sekundi latentsusega. Sellest ajast alates on Harmonic integreerinud madala latentsusajaga DASH-funktsionaalsuse oma seadmetepõhistesse toodetesse (Packager XOS ja Electra XOS) ja SaaS-lahendustesse (VOS Cluster ja VOS260). Paljud teised kooderite ja mängijate müüjad on seda teinud.
Sõltumata sellest, kas otsustate rakendada DASH-i jaoks madala latentsusega HLS-i või madala latentsuse või mõlemat, peaks üleminek teie olemasolevalt HLS-i ja / või DASH-i kohaletoimetamise arhitektuurilt olema suhteliselt sujuv ja odav.
5. Reaalajas side
WebRTC on tavaliselt integreeritud paketi mootor, mis sisaldab kodeerijat, mängijat ja kohaletoimetamise infrastruktuuri. WebRTC-põhiste suuremahuliste voogesituslahenduste näited hõlmavad reaalaega Phenixist, Limelighti reaalajas voogesitust ja Millicasti CoSMo tarkvarast ja Influxist (joonis 3). WebRTC tehnoloogiale pääseb juurde ka sellistes tööriistades nagu Wowza voogedastusmootor, CoSMO tarkvara ja Red 5 Pro Server. Selle klassi tehnoloogiate latentsusaeg on vahemikus .5 sekundit 71% voogudest (Phenix), alla 500 millisekundi (Red5 Pro), kuni sekundini (Limelight). Kui vajate kahe sekundi pikkust latentsusaega, on WebRTC valik, mida peate kaaluma.
Kui vajate reaalajas sidet, peate tõenäoliselt rakendama kas WebRTC või Websockets-põhise lahenduse. WebRTC sõnastati brauserilt brauserile ja seda toetavad kõik suuremad töölauabrauserid - Android, iOS, Chrome OS, Firefox OS, Tizen 3.0 ja BlackBerry 10, seega peaks see töötama ilma ühegi nimetatud platvormi allalaadimiseta. Nagu nimest järeldada võib, on WebRTC protokoll otseülekannete edastamiseks igale vaatajale, kas võrdõigusvõrgustikule või serverilt teisele.
WebSockets on reaalajas protokoll, mis loob ja hoiab püsivat ühendust serveri ja kliendi vahel, mida kumbki pool saab andmete edastamiseks kasutada. Seda ühendust saab kasutada nii video edastamise kui ka muu side toetamiseks, nii et see on mugav, kui teie rakendus vajab interaktiivsust. Nagu WebRTC juurutused, pakutakse ka WebSocketsi kasutavaid teenuseid tavaliselt teenusena, mis sisaldab mängijat ja CDN-i, ning võite kasutada mis tahes kooderit, mis suudab vooge serverisse RTMP või WebRTC kaudu transportida. Näidete hulka kuuluvad Nanocosmose nanoStream Cloud ja Wowza Ultra Madala Latentsusega Streaming Cloud. Wowza väidab, et nende lahus on alla 3 sekundi latentsus, samas kui Nanocosmos väidab klaasist klaasini umbes sekundit.
Muud madala latentsusega tehnoloogiad
On neljas kategooria tooteid, mida nimetatakse kõige paremini „muudeks” ja mis kasutavad madala latentsuse tagamiseks erinevaid tehnoloogiaid. Sellesse kategooriasse kuulub THEO Technologies High Efficiency Streaming Protocol (HESP), mis on patenteeritud HTTP-adaptiivne voogesitusprotokoll, mis THEO andmetel pakub alla 100 millisekundilise latentsuse, vähendades samas ribalaiust umbes 10% võrreldes teiste madala latentsusega tehnoloogiatega. HESP kasutab standardseid koodereid ja CDN-e, kuid nõuab pakendis ja mängijas kohandatud tuge (joonis 4). HESP-i kohta saate lugeda allalaaditavast valgest raamatust siit.
Siin on loetelu küsimustest, mida peaksite arvesse võtma, otsustades, millist madala latentsusega tehnoloogiat rakendada ja kuidas seda teha.
Ehitada või osta?
Kui rakendate tehnoloogiat ise, vastake enne tehnoloogia valimist kindlasti kõigile allpool loetletud küsimustele. Kui valite teenusepakkuja, kasutage neid erinevate teenusepakkujate võrdlemiseks.
Kas valite standardi või partneri?
Oleme eespool kirjeldanud erinevaid viivitusvõimaluste saavutamise tehnoloogiaid, kuid rakendused on teenusepakkujalt erinevad. Nii et mitte kõik LL HLS-i rakendused ei sisalda ABR-i edastamist, vähemalt mitte esialgu. Enamik traditsioonilisi ringhäälingulaadseid rakendusi liiguvad tõenäoliselt HTTP-põhiste standardite suunas, nagu madala latentsusega viivitus HLS / DASH / CMAF, samas kui ülimadalat latentsust nõudvad rakendused, näiteks kihlveod ja oksjonid, liiguvad teiste tehnoloogiate poole. Mõlemal juhul on teenusepakkuja valimisel olulisem kindlaks teha, kas nad suudavad teie tehnoloogilisi ja ärilisi eesmärke täita, kui see, millist tehnoloogiat nad tegelikult rakendavad.
Kas seda saab skaalata ja mis hinnaga?
HTTP-põhiste tehnoloogiate üks eelis on see, et nende skaalat kasutatakse standardsete hindade järgi, kasutades enamikku CDN-sid. Seevastu enamus WebRTC ja WebSocket-põhiseid tehnoloogiaid vajavad teenuse pakkuja juurutatud spetsiaalset tarnetaristut. Sel põhjusel võib mitte-HTTP-põhiste teenuste osutamine olla kallim kui HLS / DASH / CMAF. Teenusepakkujate võrdlemisel veenduge, et supp ja sündmuse maksumus oleksid pähklid, sealhulgas sissetung, ümberkodeerimine, ribalaius, VOD-failide loomine, ühekordsed või sündmuse kohta konfiguratsioonid jms.
Rakendamisega seotud probleemid?
Esitage järgmised tehnoloogia rakendamise ja kasutamisega seotud küsimused.
- Milline on latentsus, mis on saavutatav teie vaatajaskonna suuruse ja geograafilise jaotuse seisukohast olulises ulatuses?
- Kas on mingeid kvaliteedipiiranguid - mõned tehnoloogiad võivad piirduda teatud maksimaalse eraldusvõime või H.264 profiiliga.
- Kas paketid läbivad tulemüüri? HTTP-põhised süsteemid kasutavad HTTP-protokolle, mis on tulemüürisõbralikud. Teised kasutavad UDP-d, mis ei pruugi tulemüüre automaatselt läbida. Kui on UDP, kas blokeeritud vaatajatele on ka mingeid tagakanaleid?
- Milliseid platvorme toetatakse? Eeldatavasti arvutid ja mobiilseadmed, aga kuidas on STB-de, donglite, OTT-seadmete ja nutiteleritega?
- Kas süsteem suudab teie vaatajaskonna numbriteni vastavusse viia? Kas CDN-i infrastruktuur on privaatne ja kas jah, kas see suudab pakkuda kõigile asjaomastele vaatajatele kõigil asjakohastel turgudel? Millised on skaala suurendamise eeldatavad kulud?
- Kas saate kasutada oma mängijat või peate kasutama süsteemi mängijat? Kui teie enda oma on, milliseid muudatusi on vaja teha ja kui palju see maksma läheb?
- Mida on vaja mobiilseks taasesituseks? Kas voogesitusi esitatakse brauseris või on rakendus vajalik? Kas on olemas vajalik (või soovitav) rakendus, kas SDK-d on saadaval?
- Milliseid koodereid süsteem saab kasutada? Enamik peaks kasutama mis tahes kooderit, mis toetab RTMP-ühendusi pilvetranskoodrisse, kuid kontrollige, kas on vaja muid protokolle.
- Kas sisu saab uuesti kasutada VOD-i jaoks või on vaja uuesti kodeerida? Pole just eriline tehing, kuna mõistliku kodeerimisredeli ümberkodeerimine maksab umbes 20 dollarit tunnis video, kuid sagedaste ülekannete jaoks on see kallis.
- Millised on koondamisvõimalused ja millised on kulud? Missioonikriitiliste ülekannete jaoks peaksite teadma, kuidas kopeerida kodeerimise / levitamise töövoog, kui mõni süsteemikomponent peaks sündmuse ajal langema. Kas seda koondamist toetatakse ja kui palju see maksab?
Millised funktsioonid on saadaval ja millises ulatuses?
Erinevatelt teenusepakkujatelt pakutakse palju erinevaid funktsioonide pakkumisi, mis võivad sisaldada järgmist:
- ABR voogesitus - mitu voogu ja kas on asjakohaseid bitikiiruse või eraldusvõime piiranguid?
- Aga DVR funktsioonid? Kas vaatajad saavad sisu peatamata taasesituse peatada ja uuesti alustada.
- Video sünkroonimine - Kas süsteem saab sünkroonida kõiki vaatajaid voo samasse punkti? Vood võivad levida asukohtade ja seadmete kohal ning ilma selle võimaluseta võivad mõne ühenduse kasutajatel olla oksjonitel või hasartmängudel eelised.
- Milline sisukaitse on saadaval? Kui olete esmaklassiline sisutootja, võib vaja minna tõelist DRM-i. Teised saavad autentimise või muude sarnaste võtetega hakkama.
- Kas pealdised on saadaval? Mõne saate jaoks on kohustuslikud pealdised, kuid see on üldiselt kasulik kõigile.
- Kuidas on lood reklaami sisestamise või muu monetiseerimisskeemiga? Kas tehnoloogia / teenuse pakkuja seda toetab?
Üldiselt, kui olete voogesituse pood, kes soovib 5–6 sekundi vahemikus eetriaegu täita või ületada, on teie parim valik tõenäoliselt standardipõhine HTTP-tehnoloogia, kuna see on kõige lähemal teie sama funktsioonikomplekti toetamisele. kasutame praegu sisu kaitset, subtiitreid ja monetiseerimist. Kui teil on rakendus, mis nõuab palju väiksemat latentsusaega, vajate tõenäoliselt WebRTC- või Websockets-põhist lahendust või patenteeritud HTTP-tehnoloogiat. Mõlemal juhul peaks ülaltoodud küsimuste esitamine aitama tuvastada teie vajadustele kõige paremini vastava tehnoloogia ja / või teenuse pakkuja.