Latența scăzută este o aspirație universală în mass-media. Când o companie precum Wowza produce graficul perfect pentru a explica tehnologiile de streaming cu latență scăzută, trebuie să vă scoateți pălăria și să utilizați graficul, cu atribuire și câteva modificări minore. Prezint graficul respectiv ca Figura 1; să discutăm în ordinea desemnată de numerele evidențiate pe care le-am adăugat.
1. Aplicații pentru latență scăzută
GHID PRODUS
Cele mai bune camere PTZ pentru streaming live
Doar pentru a ne asigura că suntem cu toții pe aceeași pagină, latența în contextul transmiterii în direct înseamnă întârzierea de la sticlă la sticlă. Primul pahar este camera la evenimentul live real, al doilea este ecranul pe care îl urmăriți. Latența este întârzierea dintre momentul în care apare în cameră și momentul în care apare pe telefon. Contribuind la latență sunt factori precum timpul de codare (la eveniment), timpul de transport către cloud, timpul de transcodare în cloud (pentru a crea scara de codare), timpul de livrare și, în mod critic, câte secunde jucătorul tău memorează înainte de a începe să joace.
Stratul superior arată aplicațiile tipice și cerințele lor de latență. Aplicațiile populare care lipsesc din latența scăzută și latența aproape în timp real sunt site-urile de jocuri de noroc și de licitații.
Înainte de a vă scufunda în discuția noastră despre tehnologie, înțelegeți că cu cât este mai mică latența fluxului live, cu atât fluxul este mai puțin rezistent la întreruperile lățimii de bandă. De exemplu, utilizând setările implicite, un flux HLS va reda peste 15 secunde de lățime de bandă întreruptă și, dacă este restaurat în acel moment, este posibil ca vizualizatorul să nu știe niciodată că a existat o problemă. În schimb, un flux cu latență scăzută se va opri din redare aproape imediat după o întrerupere. Deci, beneficiul timpului de pornire cu latență scăzută trebuie întotdeauna echilibrat cu negativul opririlor din redare. Dacă nu aveți absolut nevoie de o latență scăzută, este posibil să nu merite să sacrificați rezistența pentru ao obține.
Acestea fiind spuse, este util să împărțiți latența în trei categorii, după cum urmează.
NEWSLETTER PROAudio + Video + IT. Editorii noștri sunt experți în integrarea audio / video și IT. Obțineți informații zilnice, știri și rețele profesionale. Abonați-vă astăzi la Pro AV.
- Este bine sa ai - Mai rapid este întotdeauna mai bun, dar dacă transmiteți în direct o reuniune a Consiliului de învățământ sau un joc de fotbal la liceu, puteți decide că robustețea fluxului este mai importantă decât latența scăzută, mai ales dacă mulți spectatori urmăresc conexiuni cu viteză de biți redusă.
- Avantaj competitiv - În unele cazuri, latența redusă oferă un avantaj competitiv sau latența lentă înseamnă un dezavantaj competitiv. Veți observa în grafic că latența tipică pentru televiziunea prin cablu este de aproximativ cinci secunde. Dacă serviciul dvs. de streaming concurează împotriva cablului, trebuie să vă aflați în acea gamă, cu o latență mai mică oferind un avantaj competitiv modest.
- Comunicații în timp real - Dacă sunteți un site de jocuri de noroc sau de licitații sau dacă aplicația dvs. necesită comunicări în timp real, trebuie să furnizați o latență redusă.
- Ghid de comparație pentru streaming live
- Cum se prezice succesul codecului
Acum, că cunoaștem categoriile, să analizăm cel mai eficient mod de a oferi nivelul necesar de latență scăzută.
2/3 Îmi pare bine să ai o latență scăzută
Numărul 2 arată că Apple HLS și MPEG-DASH implementate folosind setările implicite au ca rezultat aproximativ 30 de secunde de latență. Numerele sunt simple; dacă utilizați dimensiuni de segment de zece secunde și aveți nevoie de trei segmente în memoria tampon pentru player înainte de începerea redării, sunteți la treizeci de secunde. Într-adevăr, Apple și-a schimbat cerințele de la zece secunde la șase secunde în urmă cu câțiva ani, iar majoritatea producătorilor de DASH utilizează segmente de 4-6 secunde, astfel încât numărul implicit este cu adevărat mai aproape de 20 de secunde.
Totuși, numărul 3, HLS Tuned și DASH Tuned, arată o latență de aproximativ 6-8 secunde. În esență, reglarea înseamnă schimbarea de la segmente de 10 secunde la segmente de 2 secunde care, aplicând aceeași matematică, oferă cele 6-8 secunde de latență. Deci, atunci când latența este plăcută, puteți reduce latența dramatic, fără niciun timp de dezvoltare sau cost, sau un risc de livrabilitate crescut semnificativ.
4. Avantaj competitiv - Tehnologii HTTP cu latență scăzută
Atunci când este nevoie de o latență scăzută ca avantaj competitiv, doar reducerea dimensiunilor segmentelor nu o va face; va trebui să implementați o adevărată tehnologie cu latență scăzută. Aici, există două clase; Tehnologii HTTP cum ar fi Low-Latency HLS și Low-Latency CMAF pentru DASH și soluții bazate pe alte tehnologii, cum ar fi WebSockets și WebRTC.
Pentru majoritatea producătorilor cu aplicații din această clasă, tehnologiile HTTP cu latență redusă oferă cel mai bun mix de accesibilitate, compatibilitate inversă, flexibilitate și set de caracteristici. Așadar, voi acoperi HLS cu latență scăzută și CMAF cu latență scăzută pentru DASH în această secțiune și alte tehnologii în următoarea.
Toate sistemele cu latență scăzută bazate pe HLS / DASH / CMAF funcționează în același mod de bază, așa cum se arată în Figura 2. Adică, mai degrabă decât să aștepte până când se codifică un segment complet, care durează de obicei între 6-10 secunde (partea de sus a Figura 2) , codificatorul creează bucăți mult mai scurte care sunt transferate pe CDN imediat ce sunt complete (partea de jos a Figura 2).
De exemplu, dacă codificatorul dvs. producea segmente de șase secunde, ați avea cel puțin șase secunde de latență; triplă decât dacă trebuiau primite cele trei segmente normale de către vizualizator înainte de a începe redarea. Cu toate acestea, dacă codificatorul dvs. a împins bucăți la fiecare 200 de milisecunde și playerul a fost configurat să înceapă redarea imediat, latența ar trebui să fie mult, mult mai mică. Un avantaj cheie al acestei scheme este compatibilitatea cu versiunile anterioare; deoarece segmentele sunt încă create, jucătorii care nu sunt compatibili cu schema cu latență scăzută ar trebui să poată reda segmentele, deși cu o latență mai lungă. Aceste segmente sunt, de asemenea, disponibile instantaneu pentru prezentări VOD din fluxul live.
Dincolo de aceste avantaje, tehnologiile HTTP cu latență scăzută acceptă majoritatea caracteristicilor fraților lor cu latență normală, inclusiv criptarea, inserarea publicității și subtitrarea, care nu sunt acceptate universal în tehnologiile WebRTC și WebSockets. Este posibil să implementați tehnologia selectată cu latență scăzută folosind playerul și infrastructura de livrare existente, minimizând costurile de dezvoltare și alte costuri tehnologice.
Alegerea unei tehnologii HTTP cu latență redusă
Există două standarde majore pentru HTTP Adaptive Streaming, HLS și DASH, plus un format de container de unificare, CMAF. Odată ce Apple și-a anunțat soluția HLS cu latență scăzută, a mutat instantaneu mai multe eforturi la nivel local și a devenit tehnologia de alegere pentru livrarea latenței scăzute către HLS. Deși specificația este încă relativ nouă, este deja susținută de furnizorii de tehnologie precum Wowza și WMSPanel cu produsul lor Nimble Streamer.
Există un standard DVB pentru DASH cu latență scăzută și DASH Industry Forum a aprobat mai multe moduri cu latență scăzută pentru DASH pentru a fi incluse în următoarele orientări de interoperabilitate. În conformitate cu toate aceste specificații, dezvoltatorii de codificatori și jucători și rețelele de livrare a conținutului au lucrat de câțiva ani pentru a asigura interoperabilitatea, astfel încât toate aplicațiile DASH / CMAF cu latență redusă să intre în funcțiune.
De exemplu, Harmonic și Akamai au demonstrat împreună CMAF cu latență scăzută încă din NAB și IBC 2017, prezentând livrare OTT live cu o latență sub cinci secunde. De atunci, Harmonic a integrat funcționalitatea DASH cu latență scăzută în produsele lor bazate pe dispozitive (Packager XOS și Electra XOS) și soluțiile SaaS (VOS Cluster și VOS260). Mulți alți furnizori de codificatori și jucători au făcut același lucru.
Indiferent dacă alegeți să implementați HLS cu latență scăzută sau cu latență scăzută pentru DASH sau ambele, tranziția de la arhitectura de livrare HLS și / sau DASH existentă ar trebui să fie relativ simplă și ieftină.
5. Comunicații în timp real
WebRTC este de obicei motorul unui pachet integrat care include codificatorul, playerul și infrastructura de livrare. Exemple de soluții de streaming pe scară largă bazate pe WebRTC includ Real Time de la Phenix, Limelight Realtime Streaming și Millicast de la CoSMo Software și Influxis (Figura 3). De asemenea, puteți accesa tehnologia WebRTC în instrumente precum Wowza Streaming Engine, CoSMO Software și Red 5 Pro Server. Timpii de latență pentru tehnologiile din această clasă variază de la 0,5 secunde pentru 71% din fluxuri (Phenix), sub 500 de milisecunde (Red5 Pro), până la sub o secundă (Limelight). Dacă aveți nevoie de latență sub-două secunde, WebRTC este o opțiune pe care trebuie să o luați în considerare.
Dacă aveți nevoie de comunicații în timp real, va trebui probabil să implementați fie o soluție WebRTC, fie bazată pe Websockets. WebRTC a fost formulat pentru comunicații de la browser la browser și este acceptat de toate browserele desktop majore, pe Android, iOS, Chrome OS, Firefox OS, Tizen 3.0 și BlackBerry 10, deci ar trebui să ruleze fără descărcări pe oricare dintre aceste platforme. După cum sugerează și numele, WebRTC este un protocol pentru livrarea de fluxuri live către fiecare vizualizator, fie peer-to-peer, fie de la server la egal.
WebSockets este un protocol în timp real care creează și menține o conexiune persistentă între un server și client pe care oricare dintre părți îl poate utiliza pentru a transmite date. Această conexiune poate fi utilizată pentru a sprijini atât transmiterea video, cât și alte comunicații, astfel încât sunt convenabile dacă aplicația dvs. are nevoie de interactivitate. La fel ca implementările WebRTC, serviciile care utilizează WebSockets sunt de obicei oferite ca un serviciu care include player și CDN și puteți utiliza orice codificator care poate transporta fluxuri către server prin RTMP sau WebRTC. Exemplele includ nanoStream Cloud de la Nanocosmos și Cloud de streaming Wowza cu latență foarte scăzută. Wowza revendică latența sub 3 secunde pentru soluția lor, în timp ce Nanocosmos pretinde aproximativ o secundă, sticlă pe sticlă.
Alte tehnologii cu latență scăzută
Există o a patra categorie de produse numită cel mai bine „altele” care utilizează diferite tehnologii pentru a oferi o latență scăzută. Această categorie include THEO Technologies High Efficiency Streaming Protocol (HESP), un protocol propriu de streaming adaptiv HTTP care, conform THEO, oferă o latență sub 100 de milisecunde, reducând în același timp lățimea de bandă cu aproximativ 10% în comparație cu alte tehnologii cu latență scăzută. HESP folosește codificatoare și CDN-uri standard, dar necesită suport personalizat în pachet și player (Figura 4). Puteți citi mai multe despre HESP într-o carte albă disponibilă pentru descărcare, aici.
Iată o listă de întrebări pe care ar trebui să le luați în considerare atunci când decideți ce tehnologie cu latență scăzută să implementați și cum să faceți acest lucru.
Construiți sau cumpărați?
Dacă implementați singur tehnologia, asigurați-vă că răspundeți la toate întrebările enumerate mai jos înainte de a alege o tehnologie. Dacă alegeți un furnizor de servicii, utilizați-i pentru a compara diferiții furnizori de servicii.
Alegeți un standard sau un partener?
Am prezentat mai sus diferite tehnologii pentru a obține o latență scăzută, dar implementările variază de la furnizor de servicii la furnizor de servicii. Deci, nu toate implementările LL HLS vor încorpora livrarea ABR, cel puțin nu la început. Majoritatea aplicațiilor tradiționale de tip difuzare vor migra probabil către standarde bazate pe HTTP, cum ar fi HLS / DASH / CMAF cu latență scăzută, în timp ce aplicațiile care necesită o latență foarte scăzută, cum ar fi pariurile și licitațiile, vor gravita către celelalte tehnologii. În ambele cazuri, atunci când alegeți un furnizor de servicii, este mai important să stabiliți dacă aceștia pot îndeplini obiectivele dvs. tehnologice și de afaceri decât ce tehnologie implementează de fapt.
Poate scala și cu ce cost?
Unul dintre avantajele tehnologiilor bazate pe HTTP este că acestea se ridică la prețuri standard folosind majoritatea CDN-urilor. În schimb, majoritatea tehnologiilor WebRTC și WebSocket necesită o infrastructură de livrare dedicată implementată de furnizorul de servicii. Din acest motiv, serviciile care nu sunt bazate pe HTTP pot fi mai scumpe de livrat decât HLS / DASH / CMAF. Când comparați furnizorii de servicii, stabiliți costul supei la nuci al evenimentului, inclusiv intrarea, transcodarea, lățimea de bandă, crearea fișierului VOD, configurațiile unice sau per eveniment și altele asemenea.
Probleme legate de implementare?
Puneți următoarele întrebări legate de implementarea și utilizarea tehnologiei.
- Care este latența realizabilă la o scară relevantă pentru dimensiunea publicului și distribuția geografică?
- Există limitări de calitate - unele tehnologii pot fi limitate la anumite rezoluții maxime sau profiluri H.264.
- Pachetele vor trece printr-un firewall? Sistemele bazate pe HTTP utilizează protocoale HTTP, care sunt compatibile cu firewall-urile. Alții folosesc UDP, care poate să nu treacă automat prin firewall-uri. Dacă este UDP, există canale de back-back pentru a fi livrate spectatorilor blocați?
- Ce platforme sunt acceptate? Probabil calculatoare și dispozitive mobile, dar ce zici de STB-uri, dongle-uri, dispozitive OTT și televizoare inteligente?
- Poate scala sistemul să corespundă numărului vizionatorului dvs. vizat? Infrastructura CDN este privată și, dacă da, se poate livra tuturor spectatorilor relevanți pe toate piețele relevante? Care sunt costurile anticipate ale scalării?
- Îți poți folosi propriul player sau trebuie să folosești playerul sistemului? Dacă este al tău, ce schimbări sunt necesare și cât va costa asta?
- Ce este necesar pentru redarea mobilă? Fluxurile vor fi redate într-un browser sau este necesară o aplicație? Dacă este necesară o aplicație (sau de dorit) sunt SDK-uri disponibile?
- Ce codificatoare poate utiliza sistemul? Majoritatea ar trebui să utilizeze orice codificator care poate accepta conexiuni RTMP în transcodorul cloud, dar verificați dacă sunt necesare alte protocoale.
- Conținutul poate fi reutilizat pentru VOD sau va fi necesară recodificarea? Nu este o afacere uriașă, deoarece costă aproximativ 20 USD / oră de transcodare pe o scară de codificare rezonabilă, dar costisitoare pentru difuzările frecvente.
- Care sunt opțiunile de redundanță și care sunt costurile? Pentru transmisiile critice pentru misiune, veți dori să știți cum să copiați fluxul de lucru de codificare / difuzare în cazul în care orice componentă a sistemului va ceda în timpul evenimentului. Este acceptată această redundanță și care este costul?
Ce caracteristici sunt disponibile și la ce scară?
Va exista o mare varietate de oferte de funcții de la diferiți furnizori, care pot include sau nu:
- Streaming ABR - câte fluxuri și există limitări relevante ale bitrate-ului sau rezoluției?
- Dar caracteristicile DVR? Pot spectatorii să oprească și să repornească redarea fără a pierde conținut.
- Sincronizare video - Sistemul poate sincroniza toți spectatorii în același punct din flux? Fluxurile pot trece peste locații și dispozitive și, fără această capacitate, utilizatorii care au anumite conexiuni pot avea un avantaj pentru licitații sau jocuri de noroc.
- Ce protecție de conținut este disponibilă? Dacă sunteți un producător de conținut premium, este posibil să aveți nevoie de DRM adevărat. Alții se pot descurca cu autentificarea sau alte tehnici similare.
- Sunt disponibile subtitrări? Subtitrările sunt obligatorii din punct de vedere legal pentru unele emisiuni, dar în general benefice pentru toți.
- Ce zici de inserția publicitară sau de altă schemă de generare de bani? Furnizorul de servicii / tehnologie acceptă acest lucru?
În general, dacă sunteți un magazin de streaming care caută să îndeplinească sau să depășească timpii de difuzare în intervalul de 5 până la 6 secunde, o tehnologie HTTP bazată pe standarde este probabil cel mai bun pariu, deoarece va fi cel mai aproape de a susține același set de caracteristici folosiți în prezent, cum ar fi protecția conținutului, subtitrări și generare de bani. Dacă aveți o aplicație care necesită o latență mult mai mică, probabil că veți avea nevoie de o soluție WebRTC sau Websockets sau de o tehnologie HTTP proprietară. În ambele cazuri, adresarea întrebărilor enumerate mai sus ar trebui să vă ajute să identificați tehnologia și / sau furnizorul de servicii care satisface cel mai bine nevoile dvs.