Zema latentība ir universāla tiekšanās plašsaziņas līdzekļos. Kad tāds uzņēmums kā Wowza ražo perfektu diagrammu, lai izskaidrotu zemas kavēšanās straumēšanas tehnoloģijas, jums ir jānoņem cepure pret viņiem un jāizmanto diagramma ar attiecinājumu un dažām nelielām izmaiņām. Es uzrādu minēto diagrammu kā 1. attēlu; apspriedīsimies secībā, kuru nosaka izceltie skaitļi, kurus esmu pievienojis.
1. Pieteikumi zemai latentumam
PRODUKTA VADĪBA
Labākās PTZ kameras tiešraides straumēšanai
Lai pārliecinātos, ka mēs visi atrodamies vienā lapā, latentums tiešraides straumēšanas kontekstā nozīmē aizkavi no stikla uz stiklu. Pirmais stikls ir faktiskā tiešraides notikuma kamera, otrais - ekrāns, kuru skatāties. Latentums ir kavēšanās starp brīdi, kad tas parādās kamerā, līdz brīdim, kad tas parādās jūsu tālrunī. Latentumu veicina tādi faktori kā laika kodēšana (pasākumā), transporta laiks uz mākoni, laika pārkodēšana mākonī (lai izveidotu kodēšanas kāpnes), piegādes laiks un kritiski tas, cik sekundes spēlētājs buferē, pirms sāk spēlēt.
Augšējais slānis parāda tipiskas lietojumprogrammas un to latentuma prasības. Populāras lietojumprogrammas, kuru trūkst zemā un gandrīz reālā laika latentuma, ir azartspēļu un izsoļu vietnes.
Pirms ienirstat mūsu tehnoloģiju diskusijās, saprotiet, ka jo zemāka ir jūsu tiešraides latentuma laiks, jo mazāk straume ir joslas platuma pārtraukumiem. Piemēram, izmantojot noklusējuma iestatījumus, HLS straume tiks atskaņota vismaz 15 sekundes ar pārtrauktu joslas platumu, un, ja tā tiks atjaunota tajā brīdī, skatītājs, iespējams, nekad nezinās, ka pastāv problēma. Turpretī zemas latentuma straumes atskaņošana tiks pārtraukta gandrīz uzreiz pēc pārtraukuma. Tātad ieguvums no zemas aizkavēšanās palaišanas laika vienmēr ir jālīdzsvaro ar negatīvo, ko rada atskaņošanas apstāšanās. Ja jums nav absolūti nepieciešama zema latentuma pakāpe, iespējams, nav vērts upurēt elastību, lai to iegūtu.
Tas nozīmē, ka ir lietderīgi sadalīt latentumu trīs kategorijās šādi.
PRO JAUNZIŅAAudio + Video + IT. Mūsu redaktori ir eksperti audio / video un IT integrēšanā. Saņemiet ikdienas ieskatus, jaunumus un profesionālus tīklus. Abonējiet Pro AV šodien.
- Patīkami - Ātrāk vienmēr ir labāk, taču, ja jūs tiešraidē straumējat Izglītības padomes sanāksmi vai vidusskolas futbola spēli, varat izlemt, ka straumes stabilitāte ir svarīgāka par zemu latentumu, it īpaši, ja daudzi skatītāji skatās ar zemu bitu pārraides ātrumu.
- Konkurences priekšrocības - Dažos gadījumos zems latentums nodrošina konkurences priekšrocības vai lēns latentums nozīmē konkurences trūkumu. Diagrammā atzīmēsit, ka kabeļtelevīzijas tipiskais latentuma laiks ir aptuveni piecas sekundes. Ja jūsu straumēšanas pakalpojums konkurē ar kabeli, jums jāatrodas šajā diapazonā, un zemāka kavēšanās nodrošina nelielas konkurences priekšrocības.
- Reāllaika komunikācija - Ja esat azartspēļu vai izsoles vietne vai jūsu lietojumprogrammai citādi ir nepieciešami reāllaika sakari, jums noteikti jānodrošina zems latentums.
- Tiešraides straumēšanas salīdzināšanas ceļvedis
- Kā prognozēt kodeku panākumus
Tagad, kad mēs zinām kategorijas, apskatīsim visefektīvāko veidu, kā nodrošināt nepieciešamo zemas latentuma līmeni.
2/3 Patīkami ar zemu latentumu
Numurs 2 rāda, ka Apple HLS un MPEG-DASH, kas izvietoti, izmantojot noklusējuma iestatījumus, rada aptuveni 30 sekundes latentumu. Skaitļi ir vienkārši; ja izmantojat desmit sekunžu segmentu izmērus un pirms atskaņošanas sākuma trīs segmentiem jābūt atskaņotāja buferī, jums ir trīsdesmit sekundes. Patiesībā pirms dažiem gadiem Apple mainīja savas prasības no desmit sekundēm uz sešām sekundēm, un lielākā daļa DASH ražotāju izmanto 4-6 sekunžu segmentus, tāpēc noklusējuma skaitlis patiešām ir tuvāk 20 sekundēm.
Tomēr 3. numurs - HLS Tuned un DASH Tuned - parāda latentumu aptuveni 6–8 sekundes. Būtībā noregulēšana nozīmē pāreju no 10 sekunžu segmentiem uz 2 sekunžu segmentiem, kas, piemērojot to pašu matemātiku, nodrošina 6-8 sekunžu latentumu. Tātad, kad latentums ir patīkams, jūs varat dramatiski samazināt latentumu, neizmantojot izstrādes laiku vai izmaksas vai ievērojami palielinot piegādes risku.
4. Konkurences priekšrocība - zema latentuma HTTP tehnoloģijas
Ja kā konkurences priekšrocība ir nepieciešama zema latentuma pakāpe, segmentu izmēru samazināšana to nedarīs; jums būs jāievieš īsta zema latentuma tehnoloģija. Šeit ir divas klases; HTTP tehnoloģijas, piemēram, Zema latentuma HLS un Zema latentuma CMAF DASH, un risinājumi, kuru pamatā ir citas tehnoloģijas, piemēram, WebSockets un WebRTC.
Lielākajai daļai ražotāju, kuriem ir šīs klases lietojumprogrammas, zemas kavēšanās HTTP tehnoloģijas piedāvā vislabāko pieejamo cenu, savietojamības ar atpakaļejošo spēku, elastību un funkciju kopumu. Tātad šajā sadaļā es aplūkošu DASH zemas latentuma HLS un zemas latentuma CMAF, kā arī citas tehnoloģijas.
Visas uz HLS / DASH / CMAF balstītas zemas latentuma sistēmas darbojas vienā un tajā pašā veidā, kā parādīts 2. attēlā. Tas ir, nevis gaidīšana, līdz tiek kodēts pilnīgs segments, kas parasti ilgst no 6 līdz 10 sekundēm (2. att. Augšdaļa) , kodētājs izveido daudz īsākus gabalus, kas tiek pārsūtīti uz CDN, tiklīdz tie ir pabeigti (2. attēla apakšdaļa).
Piemēram, ja jūsu kodētājs ražo sešu sekunžu segmentus, jums ir vismaz sešu sekunžu kavēšanās laiks; trīskārši, ja skatītājam bija jāsaņem parastie trīs segmenti pirms atskaņošanas sākuma. Tomēr, ja jūsu kodētājs ik pēc 200 milisekundēm izstumj gabalus un atskaņotājs tika konfigurēts tā, lai atskaņošana sāktos nekavējoties, latentumam jābūt daudz, daudz mazākam. Viens no galvenajiem šīs shēmas ieguvumiem ir atpakaļejoša saderība; tā kā segmenti joprojām tiek veidoti, spēlētājiem, kas nav saderīgi ar zemas aiztures shēmu, joprojām būtu jāspēj atskaņot segmentus, lai arī ar ilgāku latentumu. Šie segmenti ir uzreiz pieejami arī VOD prezentācijām no tiešraides.
Papildus šīm priekšrocībām zemas kavēšanās HTTP tehnoloģijas atbalsta lielāko daļu viņu parasto latentās brāļu un māsu funkciju, tostarp šifrēšanu, reklāmas ievietošanu un subtitrēšanu, kas WebRTC un WebSockets tehnoloģijās netiek vispārēji atbalstīts. Visticamāk, jūs varat ieviest izvēlēto zemas aizkaves tehnoloģiju, izmantojot esošo atskaņotāju un piegādes infrastruktūru, līdz minimumam samazinot izstrādes un citas tehnoloģijas izmaksas.
HTTP zema latentuma tehnoloģijas izvēle
HTTP adaptīvai straumēšanai ir divi galvenie standarti - HLS un DASH, kā arī vienojošais konteinera formāts CMAF. Kad Apple paziņoja par zemas latentuma HLS risinājumu, tas uzreiz nomainīja vairākus vietējos centienus un kļuva par izvēlēto tehnoloģiju, lai HLS piegādātu zemu latentumu. Lai gan specifikācija joprojām ir salīdzinoši jauna, to jau atbalsta tehnoloģiju nodrošinātāji, piemēram, Wowza un WMSPanel, ar savu Nimble Streamer produktu.
Zemas kavēšanās DASH ir DVB standarts, un DASH Rūpniecības forums ir apstiprinājis vairākus DASH zema latentuma režīmus, lai tos iekļautu nākamajās savietojamības vadlīnijās. Saskaņā ar visām šīm specifikācijām kodētāju un atskaņotāju izstrādātāji un satura piegādes tīkli vairākus gadus ir strādājuši, lai nodrošinātu savietojamību, lai visām DASH / CMAF zemas kavēšanās lietojumprogrammām būtu jādarbojas uz vietas.
Piemēram, Harmonic un Akamai kopā parādīja zemu latentuma CMAF jau NAB un IBC 2017, parādot tiešraides OTT piegādi ar latentumu zem piecām sekundēm. Kopš tā laika Harmonic ir integrējis zemas aiztures DASH funkcionalitāti viņu ierīcēs balstītos produktos (Packager XOS un Electra XOS) un SaaS risinājumos (VOS Cluster un VOS260). To darījuši daudzi citi kodētāju un atskaņotāju pārdevēji.
Neatkarīgi no tā, vai izvēlaties DASH ieviest zemu latentumu HLS vai zemu latentumu, vai abiem, pārejai no esošās HLS un / vai DASH piegādes arhitektūras jābūt samērā vienmērīgai un lētai.
5. Saziņa reāllaikā
WebRTC parasti ir integrētas pakotnes dzinējs, kas ietver kodētāju, atskaņotāju un piegādes infrastruktūru. Uz WebRTC balstītu liela mēroga straumēšanas risinājumu piemēri ir reāllaika no Phenix, Limelight reāllaika straumēšanas un Millicast no CoSMo programmatūras un Influxis (3. attēls). WebRTC tehnoloģijai var piekļūt arī tādos rīkos kā Wowza Streaming Engine, CoSMO Software un Red 5 Pro Server. Šīs klases tehnoloģiju latentuma laiks svārstās no .5 sekundēm 71% straumju (Phenix) līdz 500 milisekundēm (Red5 Pro) līdz mazāk nekā vienai sekundei (Limelight). Ja jums ir nepieciešams mazāk nekā divu sekunžu latentums, WebRTC ir iespēja, kas jums jāapsver.
Ja jums nepieciešama reāllaika komunikācija, visticamāk, jums būs jāievieš vai nu WebRTC, vai Websockets balstīts risinājums. WebRTC tika izstrādāts saziņai starp pārlūku un pārlūku, un to atbalsta visas galvenās darbvirsmas pārlūkprogrammas Android, iOS, Chrome OS, Firefox OS, Tizen 3.0 un BlackBerry 10, tāpēc tai vajadzētu darboties bez lejupielādēm nevienā no šīm platformām. Kā norāda nosaukums, WebRTC ir protokols tiešraides straumēšanas piegādei katram skatītājam - vienādranga vai servera.
WebSockets ir reāllaika protokols, kas izveido un uztur pastāvīgu savienojumu starp serveri un klientu, kuru jebkura puse var izmantot datu pārsūtīšanai. Šo savienojumu var izmantot, lai atbalstītu gan video piegādi, gan citus sakarus, tāpēc tas ir ērti, ja jūsu lietojumprogrammai nepieciešama interaktivitāte. Tāpat kā WebRTC ieviešana, arī pakalpojumi, kas izmanto WebSockets, parasti tiek piedāvāti kā pakalpojumi, kas ietver atskaņotāju un CDN, un jūs varat izmantot jebkuru kodētāju, kas var transportēt straumes uz serveri, izmantojot RTMP vai WebRTC. Piemēri ir Nanocosmos nanoStream Cloud un Wowza Streaming Cloud ar ļoti zemu latentumu. Wowza apgalvo, ka viņu šķīdums ir zem 3 sekunžu latentuma, savukārt Nanocosmos apgalvo, ka aptuveni viena sekunde ir stikls pret stiklu.
Citas zema latentuma tehnoloģijas
Ir ceturtā produktu kategorija, ko vislabāk sauc par “citiem” un kas izmanto dažādas tehnoloģijas, lai nodrošinātu zemu latentumu. Šajā kategorijā ietilpst THEO Technologies augstas efektivitātes straumēšanas protokols (HESP), patentēts HTTP adaptīvās straumēšanas protokols, kas saskaņā ar THEO sniedz zemāku par 100 milisekunžu latentumu, vienlaikus samazinot joslas platumu par aptuveni 10%, salīdzinot ar citām zemas kavēšanās tehnoloģijām. HESP izmanto standarta kodētājus un CDN, taču tas prasa pielāgotu atbalstu iesaiņotājā un atskaņotājā (4. attēls). Vairāk par HESP varat lasīt baltajā grāmatā, kas pieejama lejupielādei, šeit.
Šeit ir saraksts ar jautājumiem, kas jums jāņem vērā, izlemjot, kuru zemas kavēšanās tehnoloģiju ieviest un kā to izdarīt.
Veidot vai nopirkt?
Ja tehnoloģiju ieviešat pats, pirms tehnoloģijas izvēles noteikti atbildiet uz visiem zemāk uzskaitītajiem jautājumiem. Ja izvēlaties pakalpojumu sniedzēju, izmantojiet tos, lai salīdzinātu dažādus pakalpojumu sniedzējus.
Vai izvēlaties standartu vai partneri?
Iepriekš esam aprakstījuši dažādas tehnoloģijas, lai sasniegtu zemu kavēšanos, taču ieviešana dažādiem pakalpojumu sniedzējiem ir atšķirīga. Tātad, ne visos LL HLS ievieumos tiks iekļauta ABR piegāde, vismaz ne sākumā. Lielākā daļa tradicionālo apraidei līdzīgo lietojumprogrammu, visticamāk, pāries uz HTTP balstītiem standartiem, piemēram, zema latentuma HLS / DASH / CMAF, savukārt lietojumprogrammas, kurām nepieciešama īpaši zema latentuma pakāpe, piemēram, derības un izsoles, pievērsīsies citām tehnoloģijām. Jebkurā gadījumā, izvēloties pakalpojumu sniedzēju, ir svarīgāk noteikt, vai viņi var sasniegt jūsu tehnoloģiskos un biznesa mērķus, nevis to, kuru tehnoloģiju viņi faktiski ievieš.
Vai tas var mērogoties un par kādu cenu?
Viena no HTTP balstīto tehnoloģiju priekšrocībām ir tā, ka tās mērogojas pēc standarta cenām, izmantojot lielāko daļu CDN. Turpretim lielākajai daļai WebRTC un WebSocket balstīto tehnoloģiju ir nepieciešama īpaša piegādes infrastruktūra, ko ievieš pakalpojumu sniedzējs. Šī iemesla dēļ ar HTTP nesaistītus pakalpojumus var būt dārgāk piegādāt nekā HLS / DASH / CMAF. Salīdzinot pakalpojumu sniedzējus, pārliecinieties, vai zupa ir notikuma izmaksas, ieskaitot iekļūšanu, pārkodēšanu, joslas platumu, VOD failu izveidi, vienreizējas vai notikuma konfigurācijas un tamlīdzīgi.
Ar ieviešanu saistīti jautājumi?
Uzdodiet šādus jautājumus par tehnoloģijas ieviešanu un izmantošanu.
- Kāds latentums sasniedzams mērogā, kas atbilst jūsu auditorijas lielumam un ģeogrāfiskajam sadalījumam?
- Vai ir kādi kvalitātes ierobežojumi - dažas tehnoloģijas var aprobežoties ar noteiktām maksimālajām izšķirtspējām vai H.264 profiliem.
- Vai paketes izies cauri ugunsmūrim? Uz HTTP balstītās sistēmās tiek izmantoti HTTP protokoli, kas ir piemēroti ugunsmūrim. Citi izmanto UDP, kas, iespējams, automātiski neiziet cauri ugunsmūriem. Ja ir UDP, vai ir kādi kanāli, ko piegādāt bloķētajiem skatītājiem?
- Kādas platformas tiek atbalstītas? Iespējams, datori un mobilās ierīces, bet kā ir ar STB, atslēgām, OTT ierīcēm un viedajiem televizoriem?
- Vai sistēma var pielāgoties mērķa skatītāju skaitam? Vai CDN infrastruktūra ir privāta, un ja tā, vai tā var nodrošināt visus attiecīgos skatītājus visos attiecīgajos tirgos? Kādas ir paredzamās mērogošanas izmaksas?
- Vai jūs varat izmantot savu atskaņotāju vai arī jums ir jāizmanto sistēmas atskaņotājs? Kādas izmaiņas ir nepieciešamas un cik tas maksās, ja jūs pats?
- Kas nepieciešams atskaņošanai mobilajā ierīcē? Vai straumes tiks atskaņotas pārlūkprogrammā, vai ir nepieciešama lietotne? Ja ir nepieciešama (vai vēlama) lietotne, vai ir pieejami SDK?
- Kurus kodētājus sistēma var izmantot? Lielākajai daļai jāizmanto jebkurš kodētājs, kas var atbalstīt RTMP savienojumus mākoņa pārveidotājā, taču pārbaudiet, vai ir nepieciešami citi protokoli.
- Vai saturu var atkārtoti izmantot VOD, vai būs nepieciešama atkārtota kodēšana? Nav milzīgs piedāvājums, jo video pārkodēšana uz saprātīgām kodēšanas kāpnēm maksā aptuveni USD 20 stundā stundā, bet dārga bieži pārraidēm.
- Kādas ir atlaišanas iespējas un kādas ir izmaksas? Attiecībā uz misijai kritiskām apraidēm jūs vēlaties uzzināt, kā kopēt kodēšanas / apraides darbplūsmu, ja notikuma laikā kāds sistēmas komponents samazinās. Vai šī atlaišana tiek atbalstīta un kādas ir izmaksas?
Kādas funkcijas ir pieejamas un kādā mērogā?
Dažādiem piegādātājiem būs plašs funkciju piedāvājums, kas var ietvert vai ne:
- ABR straumēšana - cik straumju un vai ir kādi būtiski bitu pārraides ātruma vai izšķirtspējas ierobežojumi?
- Kā ar DVR funkcijām? Vai skatītāji var pārtraukt un atsākt atskaņošanu, nezaudējot saturu.
- Video sinhronizācija - Vai sistēma var sinhronizēt visus skatītājus vienā un tajā pašā straumes punktā? Straumes var novirzīties pāri vietām un ierīcēm, un bez šīs iespējas dažu savienojumu lietotājiem var būt priekšrocība izsolēs vai azartspēlēs.
- Kāda satura aizsardzība ir pieejama? Ja esat izcila satura producents, jums var būt nepieciešama patiesa DRM. Citi var iztikt ar autentifikāciju vai citām līdzīgām metodēm.
- Vai ir pieejami paraksti? Dažām pārraidēm ir obligāti nepieciešami paraksti, bet tie parasti ir izdevīgi visiem.
- Kā ir ar reklāmas ievietošanu vai citu monetizācijas shēmu? Vai tehnoloģiju / pakalpojumu sniedzējs to atbalsta?
Kopumā, ja esat straumēšanas veikals, kura mērķis ir sasniegt vai pārspēt apraides laikus 5–6 sekunžu diapazonā, iespējams, ka vislabākā izvēle ir uz standartiem balstīta HTTP tehnoloģija, jo tā būs vistuvāk tam, lai atbalstītu to pašu funkciju kopu, kuru jūs izmantojat. pašlaik izmantoju, piemēram, satura aizsardzību, parakstus un monetizāciju. Ja jums ir lietojumprogramma, kurai nepieciešams daudz mazāks latentums, jums, iespējams, būs nepieciešams WebRTC vai Websockets balstīts risinājums vai patentēta HTTP tehnoloģija. Jebkurā gadījumā iepriekš uzskaitīto jautājumu uzdošana varētu palīdzēt noteikt tehnoloģiju un / vai pakalpojumu sniedzēju, kas vislabāk atbilst jūsu vajadzībām.