Mažas vėlavimas yra visuotinis žiniasklaidos siekis. Kai tokia įmonė, kaip „Wowza“, sukuria puikų grafiką, kad paaiškintų žemos delsos srautines technologijas, turite nusimesti jiems skrybėlę ir naudoti diagramą su priskyrimu ir keletu nedidelių modifikacijų. Pateikiu minėtą diagramą kaip 1 paveikslą; aptarkime mano pridėtais paryškintais skaičiais nustatyta tvarka.
1. Žemos vėlavimo programos
GAMINIO VADOVAS
Geriausios PTZ kameros tiesioginiam srautui
Norint įsitikinti, kad visi esame tame pačiame puslapyje, tiesioginio srauto kontekste vėlavimas reiškia vėlavimą nuo stiklo iki stiklo. Pirmasis stiklas yra tikrojo tiesioginio įvykio kamera, antrasis - ekranas, kurį žiūrite. Vėlavimas - tai vėlavimas nuo to momento, kai jis pasirodo fotoaparate, iki jo pasirodymo telefone. Prie vėlavimo prisideda tokie veiksniai kaip laiko (renginio metu) kodavimas, laiko persiuntimas į debesį, laiko perkodavimas debesyje (norint sukurti kodavimo kopėčias), pristatymo laikas ir kritinė reikšmė, kiek sekundžių jūsų grotuvas buferiuoja prieš pradėdamas žaisti.
Viršutinis sluoksnis rodo tipines programas ir jų delsos reikalavimus. Populiarios programos, kurių trūksta mažo ir beveik realiuoju laiku, yra lošimų ir aukcionų svetainės.
Prieš pasinerdami į mūsų diskusijas apie technologijas, supraskite, kad kuo mažesnis jūsų tiesioginio srauto delsos laikas, tuo mažiau srautas yra atsparus pralaidumo pertraukimams. Pavyzdžiui, naudojant numatytuosius nustatymus, HLS srautas bus atkuriamas per 15 sekundžių pertraukiamą pralaidumą, o jei jis bus atkurtas tuo metu, žiūrovas niekada negalės žinoti, kad kilo problema. Priešingai, mažos delsos srautas nustos groti beveik iš karto po pertraukos. Taigi, mažo delsos paleidimo laiko nauda visada turi būti subalansuota su neigiamu atkūrimo sustabdymu. Jei jums visiškai nereikia mažos vėlavimo, gali būti neverta aukoti tamprumo, kad jį gautumėte.
Tai reiškia, kad naudinga suskirstyti delsą į tris kategorijas taip.
PRO NAUJIENŲ LAPELISGarso įrašas + Vaizdo įrašas + IT. Mūsų redaktoriai yra garso / vaizdo ir IT integravimo ekspertai. Gaukite kasdienių įžvalgų, naujienų ir profesionalių tinklų. Prenumeruokite „Pro AV“ šiandien.
- Malonu turėti - Greičiau visada yra geriau, bet jei tiesiogiai transliuojate švietimo tarybos posėdį ar vidurinės mokyklos futbolo varžybas, galite nuspręsti, kad srauto patikimumas yra svarbesnis už mažą vėlavimą, ypač jei daugelis žiūrovų stebi esant mažam pralaidumui.
- Konkurencinis pranašumas - Kai kuriais atvejais žemas vėlavimas suteikia konkurencinį pranašumą, arba lėtas vėlavimas reiškia konkurencinį trūkumą. Diagramoje pažymėsite, kad įprasta kabelinės televizijos vėlavimo trukmė yra maždaug penkios sekundės. Jei jūsų srautinio perdavimo paslauga konkuruoja su kabeliu, turite būti tame diapazone, o mažesnio delsimo laikas suteikia nedidelį konkurencinį pranašumą.
- Realaus laiko ryšiai - Jei esate lošimų ar aukcionų svetainė arba jūsų programai reikalingas ryšys realiuoju laiku, būtinai turite pateikti mažą vėlavimą.
- Tiesioginio srauto palyginimo vadovas
- Kaip numatyti kodeko sėkmę
Dabar, kai žinome kategorijas, pažvelkime į efektyviausią būdą pasiekti reikiamą žemos vėlinimo lygį.
2/3 malonu turėti mažą vėlavimą
Skaičius 2 rodo, kad naudojant „Apple HLS“ ir „MPEG-DASH“, įdiegtus naudojant numatytuosius nustatymus, vėluojama maždaug 30 sekundžių. Skaičiai yra paprasti; jei naudojate dešimties sekundžių segmentų dydžius ir reikalaujate, kad prieš atkūrimo pradžią grotuvo buferyje būtų trys segmentai, esate trisdešimt sekundžių. Tiesą sakant, prieš kelerius metus „Apple“ pakeitė reikalavimus nuo dešimties sekundžių iki šešių sekundžių, o dauguma DASH gamintojų naudoja 4–6 sekundžių segmentus, todėl numatytasis skaičius yra tikrai artimesnis 20 sekundžių.
Vis dėlto 3 numeris - „HLS Tuned“ ir „DASH Tuned“ - rodo maždaug 6–8 sekundžių vėlavimą. Iš esmės derinimas reiškia perėjimą iš 10 sekundžių į 2 sekundžių segmentus, kurie, taikant tą pačią matematiką, suteikia 6–8 sekundžių vėlavimą. Taigi, kai vėlavimas yra malonus, galite žymiai sumažinti vėlavimą be jokių kūrimo laiko ar išlaidų arba žymiai padidindami pristatymo riziką.
4. Konkurencinis pranašumas - mažo delsos HTTP technologijos
Kai reikalingas mažas uždelsimas kaip konkurencinis pranašumas, tai nebus padaryta tik pjaunant segmentų dydžius; turėsite įdiegti tikrą mažos vėlavimo technologiją. Čia yra dvi klasės; HTTP technologijos, tokios kaip „Low-Latency HLS“ ir „Low-Latency CMAF for DASH“, bei sprendimai, pagrįsti kitomis technologijomis, pvz., „WebSockets“ ir „WebRTC“.
Daugumai gamintojų, naudojančių šios klasės programas, mažos vėlinimo HTTP technologijos siūlo geriausią prieinamumo, atgalinio suderinamumo, lankstumo ir funkcijų rinkinio derinį. Taigi, šiame skyriuje aptarsiu DASH mažos latencijos HLS ir mažos latencijos CMAF, o kitoje - kitas technologijas.
Visos HLS / DASH / CMAF pagrįstos mažo delsos sistemos veikia tuo pačiu pagrindiniu būdu, kaip parodyta 2 paveiksle. Tai yra, o ne laukti, kol bus užkoduotas visas segmentas, kuris paprastai trunka nuo 6 iki 10 sekundžių (2 paveikslo viršuje). , koduotojas sukuria daug trumpesnes dalis, kurios perkeliamos į CDN, kai tik jos baigiasi (2 paveikslo apačia).
Pavyzdžiui, jei jūsų koduotojas gamino šešių sekundžių segmentus, vėlavimo laikas turėtų būti bent šešios sekundės; trigubai, jei prieš pradedant atkūrimą žiūrovas turėjo gauti įprastus tris segmentus. Jei jūsų koduotojas kas 200 milisekundžių išstumdavo gabalėlius ir grotuvas buvo sukonfigūruotas nedelsiant pradėti atkūrimą, vėlavimas turėtų būti daug, daug mažesnis. Vienas pagrindinių šios schemos privalumų yra atgalinis suderinamumas; kadangi segmentai vis dar kuriami, žaidėjai, nesuderinami su mažos delsos schema, vis tiek turėtų galėti žaisti segmentus, nors ir su didesniu delsos laiku. Šie segmentai taip pat iškart pasiekiami VOD pristatymams iš tiesioginio srauto.
Be šių pranašumų, mažo delsos HTTP technologijos palaiko daugumą jų įprastos delsos brolių ir seserų funkcijų, įskaitant šifravimą, reklamos įterpimą ir subtitrus, kurie nėra visuotinai palaikomi „WebRTC“ ir „WebSockets“ pagrįstose technologijose. Tikriausiai galite įdiegti pasirinktą mažos delsos technologiją naudodami esamą grotuvo ir pristatymo infrastruktūrą, sumažindami kūrimo ir kitas technologijas.
HTTP žemos delsos technologijos pasirinkimas
Yra du pagrindiniai „HTTP Adaptive Streaming“ standartai - HLS ir DASH, taip pat vienijantis konteinerio formatas CMAF. Kai „Apple“ paskelbė savo „Low Latency HLS“ sprendimą, ji iškart pakeitė keletą paprastų žmonių pastangų ir tapo pasirinkta mažo delsos perdavimo HLS technologija. Nors specifikacija vis dar yra gana nauja, ją jau palaiko tokie technologijų tiekėjai kaip „Wowza“ ir „WMSPanel“ su savo „Nimble Streamer“ produktu.
Yra DVB standartas, skirtas mažos delsos DASH, o DASH pramonės forumas patvirtino kelis DASH mažo delsos režimus, kurie bus įtraukti į kitas jų sąveikos gaires. Remiantis visomis šiomis specifikacijomis, kodavimo ir grotuvų kūrėjai bei turinio pristatymo tinklai jau kelerius metus stengiasi užtikrinti sąveikumą, kad visos DASH / CMAF mažo delsos programos turėtų pradėti veikti.
Pavyzdžiui, „Harmonic“ ir „Akamai“ kartu parodė mažo delsos CMAF dar NAB ir IBC 2017 m., Rodydami tiesioginį OTT pristatymą, kurio delsos trukmė buvo mažesnė nei penkios sekundės. Nuo tada „Harmonic“ integravo mažos delsos DASH funkcionalumą į savo prietaisų produktus („Packager XOS“ ir „Electra XOS“) ir „SaaS“ sprendimus („VOS Cluster“ ir „VOS260“). Tą patį padarė daugelis kitų kodavimo ir grotuvų pardavėjų.
Nesvarbu, ar nuspręsite įdiegti mažos vėlavimo HLS, ar mažos vėlavimo trukmę DASH, ar abu, perėjimas nuo esamos HLS ir (arba) DASH pristatymo architektūros turėtų būti gana sklandus ir nebrangus.
5. Ryšiai realiuoju laiku
„WebRTC“ paprastai yra integruoto paketo, kuriame yra koduotojas, grotuvas ir pristatymo infrastruktūra, variklis. „WebRTC“ pagrįstų didelio masto srautinio perdavimo sprendimų pavyzdžiai yra „Real Time“ iš „Phenix“, „Limelight Realtime Streaming“ ir „Millicast“ iš „CoSMo Software“ ir „Influxis“ (3 pav.). Taip pat galite pasiekti „WebRTC“ technologiją tokiuose įrankiuose kaip „Wowza Streaming Engine“, „CoSMO Software“ ir „Red 5 Pro Server“. Šios klasės technologijų delsos laikas svyruoja nuo .5 sekundžių 71% srautų („Phenix“) iki 500 milisekundžių („Red5 Pro“) iki mažiau nei vienos sekundės („Limelight“). Jei jums reikia dviejų sekundžių delsos, „WebRTC“ yra galimybė, kurią turite apsvarstyti.
Jei jums reikia ryšio realiuoju laiku, greičiausiai turėsite įdiegti „WebRTC“ arba „Websockets“ pagrįstą sprendimą. „WebRTC“ buvo sukurtas ryšiui tarp naršyklės ir jį palaiko visos pagrindinės darbalaukio naršyklės, skirtos „Android“, „iOS“, „Chrome“ OS, „Firefox OS“, „Tizen 3.0“ ir „BlackBerry 10“, todėl jis turėtų veikti be atsisiuntimų bet kurioje iš šių platformų. Kaip rodo pavadinimas, „WebRTC“ yra tiesioginių srautų pateikimo kiekvienam žiūrovui, tiek bendraamžių, tiek serverių.
„WebSockets“ yra realaus laiko protokolas, sukuriantis ir palaikantis nuolatinį ryšį tarp serverio ir kliento, kurį bet kuri šalis gali naudoti duomenims perduoti. Šis ryšys gali būti naudojamas palaikyti tiek vaizdo siuntimą, tiek kitus ryšius, todėl patogu, jei jūsų programai reikia interaktyvumo. Kaip ir „WebRTC“ diegimai, „WebSockets“ naudojančios paslaugos paprastai siūlomos kaip paslauga, apimanti grotuvą ir CDN, taip pat galite naudoti bet kurį kodavimo įrenginį, kuris srautus gali perkelti į serverį per RTMP arba „WebRTC“. Kaip pavyzdį galima paminėti „Nanocosmos“ „nanoStream Cloud“ ir „Wowza“ srautinį debesį su itin mažu delsos laiku. Wowza teigia, kad jų sprendimas yra 3 sekundes trumpesnis, o „Nanocosmos“ - apie vieną sekundę nuo stiklo iki stiklo.
Kitos mažo vėlavimo technologijos
Yra ketvirtoji produktų kategorija, geriausiai vadinama „kitais“, kurios naudoja skirtingas technologijas, kad užtikrintų mažą vėlavimą. Šiai kategorijai priklauso „THEO Technologies High Efficiency Streaming Protocol“ (HESP), patentuotas HTTP adaptyvus srautinio perdavimo protokolas, kuris, anot THEO, teikia 100 milisekundžių trukmės mažesnę vėlavimo trukmę, tuo pačiu sumažindamas pralaidumą maždaug 10%, palyginti su kitomis mažos vėlinimo technologijomis. HESP naudoja standartinius kodavimo įrenginius ir CDN, tačiau paketui ir grotuvui reikalingas pasirinktinis palaikymas (4 pav.). Daugiau apie HESP galite perskaityti baltojoje knygoje, kurią galite atsisiųsti, čia.
Čia pateikiamas klausimų, į kuriuos turėtumėte atsižvelgti, nuspręsdami, kurią mažos delsos technologiją įdiegti ir kaip tai padaryti, sąrašas.
Kurti ar pirkti?
Jei patys diegiate technologiją, prieš pasirinkdami technologiją būtinai atsakykite į visus žemiau pateiktus klausimus. Jei pasirenkate paslaugų teikėją, naudokite juos, kad palygintumėte skirtingus paslaugų teikėjus.
Ar renkatės standartą, ar partnerį?
Aukščiau apibūdinome skirtingas technologijas, kaip pasiekti mažą vėlavimą, tačiau diegimas priklauso nuo paslaugų teikėjo. Taigi, ne visuose LL HLS diegimuose bus ABR pristatymas, bent jau iš pradžių. Dauguma tradicinių į transliacijas panašių programų greičiausiai pereis prie HTTP pagrįstų standartų, pvz., Mažo delsos HLS / DASH / CMAF, o programos, kurioms reikalingas itin mažas delsimas, pavyzdžiui, lažybos ir aukcionai, pereis prie kitų technologijų. Bet kuriuo atveju, renkantis paslaugų teikėją, svarbiau nustatyti, ar jie gali pasiekti jūsų technologinius ir verslo tikslus, nei kurią technologiją jie iš tikrųjų įgyvendina.
Ar tai gali kainuoti ir kokia kaina?
Vienas iš HTTP pagrįstų technologijų pranašumų yra tas, kad jos keičiamos pagal standartinę kainą, naudojant daugumą CDN. Priešingai, daugumai „WebRTC“ ir „WebSocket“ pagrįstų technologijų reikia specialios paslaugų teikėjo įdiegtos pristatymo infrastruktūros. Dėl šios priežasties ne HTTP pagrįstas paslaugas gali būti brangiau teikti nei HLS / DASH / CMAF. Lygindami paslaugų teikėjus, išsiaiškinkite sriubos ir riešutų kainą už įvykį, įskaitant įsibrovimą, perkodavimą, pralaidumą, VOD failų kūrimą, vienkartines ar kiekvieno įvykio konfigūracijas ir panašiai.
Su įgyvendinimu susijusios problemos?
Užduokite šiuos klausimus, susijusius su technologijos diegimu ir naudojimu.
- Kokią vėlavimą galima pasiekti skalėje, atitinkančioje jūsų auditorijos dydį ir geografinį pasiskirstymą?
- Ar yra kokių nors kokybės apribojimų - kai kurios technologijos gali apsiriboti tam tikra maksimalia skiriamąja geba ar H.264 profiliais.
- Ar paketai praeis per užkardą? HTTP pagrįstose sistemose naudojami HTTP protokolai, kurie yra tinkami užkardai. Kiti naudoja UDP, kuri gali automatiškai nepereiti pro užkardas. Jei yra UDP, ar yra kokių nors antrinių kanalų, kuriuos reikia pateikti užblokuotiems žiūrintiesiems?
- Kokios platformos palaikomos? Ko gero, kompiuteriai ir mobilieji įrenginiai, bet kaip bus su STB, raktais, OTT įrenginiais ir išmaniaisiais televizoriais?
- Ar sistema gali atitikti tikslinių žiūrovų skaičių? Ar CDN infrastruktūra yra privati ir jei taip, ar ji gali tiekti visiems žiūrovams visose atitinkamose rinkose? Kokios yra numatomos mastelio keitimo išlaidos?
- Ar galite naudoti savo grotuvą, ar turite naudoti sistemos grotuvą? Jei reikia jūsų pačių, kokie pakeitimai reikalingi ir kiek tai kainuos?
- Ko reikia norint atkurti mobiliuosius? Ar srautai bus rodomi naršyklėje, ar reikalinga programa? Ar yra reikalingų (ar pageidaujamų) programų SDK?
- Kuriuos koduotojus sistema gali naudoti? Daugelis turėtų naudoti bet kurį kodavimo įrenginį, kuris gali palaikyti RTMP ryšius su debesies transkoderiu, tačiau patikrinkite, ar reikalingi kiti protokolai.
- Ar turinį galima pakartotinai naudoti VOD, ar reikės pakartotinio kodavimo? Tai nėra didelis pasiūlymas, nes perkodavimas į pagrįstas kodavimo kopėčias kainuoja apie 20 USD per valandą, tačiau brangus dažnai transliuojamoms transliacijoms.
- Kokios yra atleidimo iš darbo galimybės ir kokios yra išlaidos? Jei norite transliuoti kritines misijas, turėtumėte žinoti, kaip nukopijuoti kodavimo / transliavimo darbo eigą, jei įvykio metu sugestų koks nors sistemos komponentas. Ar palaikomas šis atleidimas ir kokia yra jo kaina?
Kokios funkcijos yra prieinamos ir kokiu mastu?
Skirtingi tiekėjai pasiūlys daug įvairių funkcijų, į kurias gali būti įtraukta:
- ABR srautas - kiek srautų ir ar yra kokių nors susijusių bitų spartos ar skiriamosios gebos apribojimų?
- Ką apie DVR funkcijas? Ar žiūrovai gali sustabdyti ir atnaujinti atkūrimą, neprarasdami turinio.
- Vaizdo įrašų sinchronizavimas - Ar sistema gali sinchronizuoti visus žiūrovus į tą patį srauto tašką? Srautai gali slinkti virš vietų ir įrenginių, o be šios galimybės kai kurių jungčių vartotojai gali turėti pranašumų aukcionuose ar lošimuose.
- Kokia turinio apsauga yra prieinama? Jei esate aukščiausio lygio turinio gamintojas, jums gali prireikti tikros DRM. Kiti gali susitvarkyti naudodamiesi autentifikavimu ar kitomis panašiomis technikomis.
- Ar yra antraščių? Kai kurioms transliacijoms teisiškai reikalingos antraštės, tačiau jos paprastai yra naudingos visiems.
- O reklamos įterpimas ar kita pajamų gavimo schema? Ar tai palaiko technologijų / paslaugų teikėjas?
Apskritai, jei esate srautinių parduotuvių parduotuvė, siekianti susitikti ar įveikti transliacijos laiką 5–6 sekundžių diapazone, standartinė HTTP technologija yra tikriausiai geriausias pasirinkimas, nes ji bus arčiausiai tos pačios funkcijos palaikymo “. šiuo metu naudojate, pvz., turinio apsaugą, antraštes ir pajamų gavimą. Jei turite programą, kuriai reikia daug mažesnės delsos, jums greičiausiai reikės „WebRTC“ ar „Websockets“ pagrįsto sprendimo arba patentuotos HTTP technologijos. Bet kuriuo atveju aukščiau išvardytų klausimų uždavimas turėtų padėti nustatyti geriausiai jūsų poreikius atitinkantį technologijų ir (arba) paslaugų teikėją.
