Lav ventetid er en universel ambition i medierne. Når et firma som Wowza fremstiller det perfekte diagram til forklaring af streaming-teknologier med lav latenstid, skal du tage hatten af for dem og bruge diagrammet med tilskrivning og nogle mindre ændringer. Jeg præsenterede det nævnte diagram som figur 1; lad os diskutere i den rækkefølge, der er udpeget af de fremhævede tal, som jeg har tilføjet.
1. Ansøgninger om lav forsinkelse
PRODUKTGUIDE
Bedste PTZ-kameraer til live streaming
Bare for at sikre, at vi alle er på samme side, betyder forsinkelse i forbindelse med live streaming forsinkelsen mellem glas og glas. Det første glas er kameraet ved den aktuelle live-begivenhed, det andet er den skærm, du ser. Latency er forsinkelsen mellem når det vises i kameraet, og når det vises på din telefon. Bidrag til latenstid er faktorer som kodningstid (ved begivenheden), transporttid til skyen, transkodningstid i skyen (for at oprette kodningsstigen), leveringstid og kritisk, hvor mange sekunder din afspiller bufferer, før du begynder at spille.
Det øverste lag viser typiske applikationer og deres krav til ventetid. Populære applikationer, der mangler lav latens og næsten realtidslatens, er hasardspil og auktionssider.
Inden du dykker ind i vores teknologidiskussion, skal du forstå, at jo lavere ventetid på din live stream er, desto mindre elastisk er strømmen til afbrydelser af båndbredde. For eksempel, ved hjælp af standardindstillinger, afspilles en HLS-stream gennem mere end 15 sekunders afbrudt båndbredde, og hvis den gendannes på det tidspunkt, kan seeren muligvis aldrig vide, at der var et problem. I modsætning hertil stopper en stream med lav latenstid afspilning næsten umiddelbart efter en afbrydelse. Så fordelen ved opstartstid med lav latenstid skal altid afbalanceres mod det negative ved stop i afspilning. Hvis du ikke absolut har brug for lav latenstid, er det måske ikke værd at ofre modstandsdygtighed for at få det.
Når det er sagt, er det nyttigt at opdele ventetid i tre kategorier som følger.
PRO NYHEDSBREVAudio + Video + IT. Vores redaktører er eksperter i at integrere lyd / video og IT. Få daglig indsigt, nyheder og professionelt netværk. Abonner på Pro AV Today.
- Rart at have - Hurtigere er altid bedre, men hvis du live-stream et Board of Education-møde eller high-school fodboldkamp, kan du beslutte, at strømstyrke er vigtigere end lav ventetid, især hvis mange seere ser på forbindelser med lav bithastighed.
- Konkurrencefordel - I nogle tilfælde giver lav latenstid en konkurrencemæssig fordel, eller langsom latens betyder en konkurrencemæssig ulempe. Du bemærker i diagrammet, at den typiske ventetid for kabel-tv er omkring fem sekunder. Hvis din streamingtjeneste konkurrerer mod kabel, skal du være inden for dette interval med lavere latenstid, der giver en beskeden konkurrencemæssig fordel.
- Kommunikation i realtid - Hvis du er et spil- eller auktionsside, eller hvis din applikation ellers kræver kommunikation i realtid, skal du absolut levere lav ventetid.
- Guide til sammenligning af live streaming
- Sådan forudsiges codec-succes
Nu hvor vi kender kategorierne, skal vi se på den mest effektive måde at levere det nødvendige niveau med lav latenstid på.
2/3 Rart at have lav forsinkelse
Nummeret 2 viser, at Apple HLS og MPEG-DASH, der er implementeret ved hjælp af deres standardindstillinger, resulterer i ca. 30 sekunders ventetid. Tallene er enkle; hvis du bruger ti sekunders segmentstørrelser og kræver, at tre segmenter er i afspillerbufferen, før afspilningen starter, er du på tredive sekunder. I virkeligheden ændrede Apple deres krav fra ti sekunder til seks sekunder for et par år siden, og de fleste DASH-producenter bruger 4-6 sekunders segmenter, så standardnummeret er virkelig tættere på 20 sekunder.
Alligevel viser nummer 3, HLS Tuned og DASH Tuned, latenstid på omkring 6-8 sekunder. I det væsentlige betyder tuning at skifte fra 10 sekunders segmenter til 2 sekunders segmenter, som ved anvendelse af samme matematik leverer 6-8 sekunders latenstid. Så når latens er rart at have, kan du reducere latens dramatisk uden udviklingstid eller omkostninger eller væsentligt øget leveringsrisiko.
4. Konkurrencemæssig fordel - HTTP-teknologier med lav latens
Når der er behov for lav latens som en konkurrencemæssig fordel, gør det bare ikke at skære segmentstørrelser; du bliver nødt til at implementere en ægte teknologi med lav latens. Her er der to klasser; HTTP-teknologier som HLS med lav latens og CMAF med lav latens til DASH og løsninger baseret på andre teknologier som WebSockets og WebRTC.
For de fleste producenter med applikationer i denne klasse tilbyder HTTP-teknologier med lav latens den bedste blanding af overkommelige priser, bagudkompatibilitet, fleksibilitet og funktionssæt. Så jeg vil dække Low Latency HLS og Low-Latency CMAF for DASH i dette afsnit og andre teknologier i det næste.
Alle HLS / DASH / CMAF-baserede systemer med lav latens fungerer på samme grundlæggende måde som vist i figur 2. Det vil sige i stedet for at vente til et komplet segment er kodet, hvilket typisk tager mellem 6-10 sekunder (øverst i figur 2) , opretter koderen meget kortere klumper, der overføres til CDN, så snart de er færdige (nederst i figur 2).
Som et eksempel, hvis din encoder producerede seks sekunders segmenter, ville du have mindst seks sekunders latenstid; tredobbelt, hvis de normale tre segmenter skulle modtages af seeren, før afspilningen begynder. Hvis din indkoder dog skubbede klumper ud hver 200 millisekund, og afspilleren blev konfigureret til at starte afspilning med det samme, burde ventetid være meget, meget mindre. En vigtig fordel ved dette skema er bagudkompatibilitet; da segmenter stadig oprettes, skal spillere, der ikke er kompatible med skemaet med lav latenstid, stadig være i stand til at spille segmenterne, omend med længere latenstid. Disse segmenter er også øjeblikkeligt tilgængelige for VOD-præsentationer fra live stream.
Ud over disse fordele understøtter HTTP-teknologier med lav latenstid de fleste af funktionerne i deres normale latenstens søskende, herunder kryptering, reklameindsættelse og undertekster, som ikke er universelt understøttet i WebRTC- og WebSockets-baserede teknologier. Du kan sandsynligvis implementere din valgte teknologi med lav latens ved hjælp af din eksisterende afspiller og leveringsinfrastruktur, hvilket minimerer udviklings- og andre teknologiomkostninger.
Valg af en HTTP Low Latency Technology
Der er to hovedstandarder for HTTP Adaptive Streaming, HLS og DASH plus et samlende containerformat, CMAF. Når Apple annoncerede sin Low Latency HLS-løsning, fortrængte det øjeblikkeligt flere græsrodsindsatser og blev den valgte teknologi til at levere lav latenstid til HLS. Selvom specifikationen stadig er relativt ny, understøttes den allerede af teknologileverandører som Wowza og WMSPanel med deres Nimble Streamer-produkt.
Der er en DVB-standard for DASH med lav latenstid, og DASH Industry Forum har godkendt adskillige Low-Latency Modes for DASH, der skal medtages i deres næste retningslinjer for interoperabilitet. I henhold til alle disse specifikationer har encoder- og afspillerudviklere og indholdsleveringsnetværk arbejdet i flere år for at sikre interoperabilitet, så alle DASH / CMAF-applikationer med lav latens skulle komme i gang.
Som et eksempel demonstrerede Harmonic og Akamai sammen CMAF med lav latens så langt tilbage som NAB og IBC 2017 og viste live OTT-levering med en latens under fem sekunder. Siden da har Harmonic integreret DASH-funktion med lav latenstid i deres apparatbaserede produkter (Packager XOS og Electra XOS) og SaaS-løsninger (VOS Cluster og VOS260). Mange andre indkoder- og afspillerleverandører har gjort det samme.
Uanset om du vælger at implementere HLS med lav latens eller lav latens til DASH eller begge dele, skal overgangen fra din eksisterende HLS- og / eller DASH-leveringsarkitektur være relativt problemfri og billig.
5. Kommunikation i realtid
WebRTC er typisk motoren til en integreret pakke, der inkluderer koderen, afspilleren og leveringsinfrastrukturen. Eksempler på WebRTC-baserede streaming-løsninger i stor skala inkluderer Real Time fra Phenix, Limelight Realtime Streaming og Millicast fra CoSMo Software og Influxis (figur 3). Du kan også få adgang til WebRTC-teknologi i værktøjer som Wowza Streaming Engine, CoSMO Software og Red 5 Pro Server. Ventetid for teknologier i denne klasse spænder fra 0,5 sekunder til 71% af streams (Phenix), under 500 millisekunder (Red5 Pro), til under et sekund (Limelight). Hvis du har brug for latenstid på to sekunder, er WebRTC en mulighed, du skal overveje.
Hvis du har brug for kommunikation i realtid, skal du sandsynligvis enten implementere en WebRTC- eller Websockets-baseret løsning. WebRTC blev formuleret til browser-til-browser-kommunikation og understøttes af alle større desktop-browsere på Android, iOS, Chrome OS, Firefox OS, Tizen 3.0 og BlackBerry 10, så det skal køre uden downloads på nogen af disse platforme. Som navnet antyder, er WebRTC en protokol til levering af live streams til hver seer, enten peer-to-peer eller server til peer.
WebSockets er en protokol i realtid, der opretter og opretholder en vedvarende forbindelse mellem en server og klient, som begge parter kan bruge til at overføre data. Denne forbindelse kan bruges til at understøtte både videoudlevering og anden kommunikation, så det er praktisk, hvis din applikation har brug for interaktivitet. Ligesom WebRTC-implementeringer tilbydes tjenester, der bruger WebSockets, typisk som en tjeneste, der inkluderer afspiller og CDN, og du kan bruge enhver indkoder, der kan transportere streams til serveren via RTMP eller WebRTC. Eksempler inkluderer Nanocosmos 'nanoStream Cloud og Wowzas Streaming Cloud With Ultra Low Latency. Wowza hævder sub-3 sekunders latenstid for deres løsning, mens Nanocosmos hævder omkring et sekund, glas til glas.
Andre teknologier med lav latens
Der er en fjerde kategori af produkter, der bedst kaldes “andet”, der bruger forskellige teknologier til at give lav latenstid. Denne kategori inkluderer THEO Technologies High Efficiency Streaming Protocol (HESP), en proprietær HTTP-adaptiv streamingprotokol, der ifølge THEO leverer sub-100 millisekund latenstid, samtidig med at båndbredden reduceres med ca. 10% sammenlignet med andre teknologier med lav latens. HESP bruger standardkodere og CDN'er, men kræver brugerdefineret support i pakker og afspiller (figur 4). Du kan læse mere om HESP i en hvidbog, der kan downloades her.
Her er en liste over spørgsmål, du bør overveje, når du beslutter, hvilken teknologi med lav latens, der skal implementeres, og hvordan du gør det.
Byg eller køb?
Hvis du selv implementerer teknologien, skal du sørge for at besvare alle nedenstående spørgsmål, inden du vælger en teknologi. Hvis du vælger en tjenesteudbyder, skal du bruge dem til at sammenligne de forskellige tjenesteudbydere.
Vælger du en standard eller en partner?
Vi har skitseret de forskellige teknologier til opnåelse af lav latenstid ovenfor, men implementeringer varierer fra tjenesteudbyder til tjenesteudbyder. Så ikke alle LL HLS-implementeringer vil omfatte ABR-levering, i det mindste ikke først. De fleste traditionelle broadcast-lignende applikationer vil sandsynligvis migrere mod HTTP-baserede standarder som HLS / DASH / CMAF med lav latens, mens applikationer, der kræver ultra-lav latens som væddemål og auktioner, vil drage mod andre teknologier. I begge tilfælde er det vigtigere at afgøre, om de kan opfylde dine teknologiske og forretningsmæssige mål, end hvilken teknologi de faktisk implementerer, når du vælger en tjenesteudbyder.
Kan den skaleres og til hvilken pris?
En af fordelene ved HTTP-baserede teknologier er, at de skaleres til standardpriser ved hjælp af de fleste CDN'er. I modsætning hertil kræver de fleste WebRTC- og WebSocket-baserede teknologier en dedikeret leveringsinfrastruktur implementeret af tjenesteudbyderen. Af denne grund kan ikke-HTTP-baserede tjenester være dyrere at levere end HLS / DASH / CMAF. Når du sammenligner tjenesteudbydere, skal du fastslå suppen til omkostningerne ved begivenhederne, herunder indtrængen, omkodning, båndbredde, oprettelse af VOD-filer, engangskonfigurationer eller konfigurationer pr. Begivenhed og lignende.
Implementeringsrelaterede problemer?
Stil følgende spørgsmål relateret til implementering og brug af teknologien.
- Hvad er den ventetid, der kan opnås på en skala, der er relevant for din målgruppestørrelse og geografiske fordeling?
- Er der nogen kvalitetsbegrænsninger - nogle teknologier kan være begrænset til visse maksimale opløsninger eller H.264-profiler.
- Vil pakkerne passere gennem en firewall? HTTP-baserede systemer bruger HTTP-protokoller, som er firewall-venlige. Andre bruger UDP, som muligvis ikke automatisk går gennem firewalls. Hvis der er UDP, er der nogen backchannels at levere til blokerede seere?
- Hvilke platforme understøttes? Formentlig computere og mobile enheder, men hvad med STB'er, dongler, OTT-enheder og smart-tv?
- Kan systemet skaleres til at opfylde dine målvisningsnumre? Er CDN-infrastrukturen privat, og i så fald kan den levere til alle relevante seere på alle relevante markeder? Hvad er de forventede omkostninger ved skalering?
- Kan du bruge din egen afspiller, eller skal du bruge systemets afspiller? Hvis dine egne, hvilke ændringer er nødvendige, og hvor meget koster det?
- Hvad skal der bruges til mobilafspilning? Vil streamene afspilles i en browser, eller kræves der en app? Hvis der kræves en app (eller ønskelig), er der SDK'er tilgængelige?
- Hvilke kodere kan systemet bruge? De fleste skal bruge en hvilken som helst encoder, der kan understøtte RTMP-forbindelser til cloudtranscoderen, men kontroller om der er behov for andre protokoller.
- Kan indholdet genbruges til VOD, eller kræves genkodning? Ikke en kæmpe aftale, da det koster omkring $ 20 / time video at omkode til en rimelig kodningsstige, men dyr for hyppige udsendelser.
- Hvad er redundansmulighederne, og hvad er omkostningerne? Til missionskritiske udsendelser vil du vide, hvordan du kopierer kodnings- / udsendelsesarbejdsprocessen, hvis en systemkomponent går ned under begivenheden. Understøttes denne redundans, og hvad er prisen?
Hvilke funktioner er tilgængelige og i hvilken skala?
Der vil være en bred vifte af funktionstilbud fra de forskellige leverandører, som måske eller ikke inkluderer:
- ABR-streaming - hvor mange streams, og er der nogen relevante bithastighed eller opløsningsbegrænsninger?
- Hvad med DVR-funktioner? Kan seerne stoppe og genstarte afspilningen uden at miste noget indhold.
- Videosynkronisering - Kan systemet synkronisere alle seere til det samme punkt i strømmen? Streams kan glide over placeringer og enheder, og uden denne mulighed kan brugere på nogle forbindelser have en fordel for auktioner eller spil.
- Hvilken indholdsbeskyttelse er tilgængelig? Hvis du er en førende indholdsproducent, har du muligvis brug for ægte DRM. Andre kan klare sig med godkendelse eller andre lignende teknikker.
- Er billedtekster tilgængelige? Undertekster er lovligt krævet for nogle udsendelser, men generelt gavnlige for alle.
- Hvad med reklameindsættelse eller andet skema for indtægtsgenerering? Understøtter teknologi / tjenesteudbyder dette?
Generelt, hvis du er en streamingbutik, der søger at møde eller slå udsendelsestider i området 5 til 6 sekunder, er en standardbaseret HTTP-teknologi sandsynligvis din bedste chance, da den kommer tættest på at understøtte den samme funktion, der sætter dig ' bruger i øjeblikket som indholdsbeskyttelse, billedtekster og indtægtsgenerering. Hvis du har et program, der kræver meget lavere ventetid, har du sandsynligvis brug for en WebRTC- eller Websockets-baseret løsning eller en beskyttet HTTP-teknologi. I begge tilfælde kan det at stille de nævnte spørgsmål hjælpe dig med at identificere den teknologi og / eller tjenesteudbyder, der bedst opfylder dine behov.