Lage latentie is een universeel streven in de media. Wanneer een bedrijf als Wowza de perfecte grafiek produceert om streamingtechnologieën met lage latentie uit te leggen, moet je je hoed voor hen afzetten en de grafiek gebruiken, met attributie en enkele kleine aanpassingen. Ik presenteer die grafiek als Figuur 1; laten we bespreken in de volgorde die wordt aangegeven door de gemarkeerde nummers die ik heb toegevoegd.
1. Toepassingen voor lage latentie
PRODUCTGIDS
Beste PTZ-camera's voor live streaming
Om er zeker van te zijn dat we allemaal op dezelfde pagina zitten, betekent latentie in de context van live streaming de glas-tot-glas vertraging. Het eerste glas is de camera bij het daadwerkelijke live-evenement, het tweede is het scherm waar je naar kijkt. Latency is de vertraging tussen het moment dat het in de camera verschijnt en het moment dat het op je telefoon verschijnt. Bijdragen aan latentie zijn factoren zoals coderingstijd (tijdens het evenement), transporttijd naar de cloud, transcoderingstijd in de cloud (om de coderingsladder te maken), levertijd en, kritisch, hoeveel seconden je speler buffert voordat hij begint te spelen.
De bovenste laag toont typische applicaties en hun latentievereisten. Populaire applicaties die ontbreken in lage latentie en bijna realtime latentie zijn gok- en veilingsites.
Voordat u in onze technologiediscussie duikt, moet u begrijpen dat hoe lager de latentie van uw livestream, hoe minder veerkrachtig de stream is voor bandbreedte-onderbrekingen. Als je bijvoorbeeld de standaardinstellingen gebruikt, speelt een HLS-stream meer dan 15 seconden onderbroken bandbreedte af, en als het op dat moment wordt hersteld, weet de kijker misschien nooit dat er een probleem was. Een stream met lage latentie zal daarentegen vrijwel onmiddellijk na een onderbreking stoppen met afspelen. Het voordeel van een opstarttijd met lage latentie moet dus altijd worden afgewogen tegen het negatief van onderbrekingen tijdens het afspelen. Als je niet absoluut een lage latentie nodig hebt, is het misschien niet de moeite waard om de veerkracht op te offeren om het te krijgen.
Dat gezegd hebbende, is het handig om de latentie als volgt in drie categorieën te verdelen.
PRO NIEUWSBRIEFAudio + video + IT. Onze redacteuren zijn experts in het integreren van audio / video en IT. Krijg dagelijkse inzichten, nieuws en professionele netwerken. Abonneer u vandaag nog op Pro AV.
- Goed om te hebben - Sneller is altijd beter, maar als je een Board of Education-vergadering of een middelbare schoolvoetbalwedstrijd live streamt, kun je besluiten dat stream-robuustheid belangrijker is dan lage latentie, vooral als veel kijkers kijken met verbindingen met een lage bitsnelheid.
- Concurrentie voordeel - In sommige gevallen levert een lage latentie een concurrentievoordeel op, of een langzame latentie een concurrentienadeel. In de grafiek ziet u dat de typische wachttijd voor kabeltelevisie ongeveer vijf seconden is. Als uw streamingdienst concurreert met de kabel, moet u zich binnen dat bereik bevinden, waarbij een lagere latentie een bescheiden concurrentievoordeel oplevert.
- Real-time communicatie - Als u een gok- of veilingsite bent, of uw aanvraag anderszins realtime communicatie vereist, moet u absoluut een lage latentie bieden.
- Vergelijkingsgids voor livestreaming
- Hoe codecsucces te voorspellen
Nu we de categorieën kennen, gaan we kijken naar de meest efficiënte manier om het benodigde niveau van korte wachttijd te bieden.
2/3 Leuk om een lage latentie te hebben
Het cijfer 2 laat zien dat Apple HLS en MPEG-DASH geïmplementeerd met hun standaardinstellingen resulteert in ongeveer 30 seconden latentie. De cijfers zijn eenvoudig; als je segmentgroottes van tien seconden gebruikt en er drie segmenten in de spelerbuffer moeten zijn voordat het afspelen begint, ben je op dertig seconden. In werkelijkheid heeft Apple een paar jaar geleden hun vereisten gewijzigd van tien seconden naar zes seconden, en de meeste DASH-producenten gebruiken segmenten van 4-6 seconden, dus het standaardaantal ligt echt dichter bij 20 seconden.
Toch vertoont nummer 3, HLS Tuned en DASH Tuned, een latentie van ongeveer 6-8 seconden. In wezen betekent afstemmen het veranderen van segmenten van 10 seconden naar segmenten van 2 seconden die, door dezelfde wiskunde toe te passen, de latentie van 6-8 seconden oplevert. Dus als latentie prettig is, kunt u de latentie drastisch verminderen zonder ontwikkeltijd of kosten, of een aanzienlijk verhoogd risico op afleverbaarheid.
4. Concurrentievoordeel - HTTP-technologieën met lage latentie
Wanneer een lage latentie nodig is als concurrentievoordeel, is het niet voldoende om segmentgroottes te verkleinen; u zult een echte technologie met lage latentie moeten implementeren. Hier zijn er twee klassen; HTTP-technologieën zoals Low-Latency HLS en Low-Latency CMAF voor DASH, en oplossingen gebaseerd op andere technologieën, zoals WebSockets en WebRTC.
Voor de meeste producenten met toepassingen in deze klasse bieden HTTP-technologieën met lage latentie de beste combinatie van betaalbaarheid, achterwaartse compatibiliteit, flexibiliteit en functieset. Dus ik zal Low Latency HLS en Low-Latency CMAF voor DASH in deze sectie behandelen, en andere technologieën in de volgende.
Alle op HLS / DASH / CMAF gebaseerde systemen met lage latentie werken op dezelfde basismanier, zoals weergegeven in figuur 2. Dat wil zeggen, in plaats van te wachten tot een compleet segment is gecodeerd, wat doorgaans tussen de 6-10 seconden duurt (bovenaan figuur 2) , maakt de encoder veel kortere brokken die naar het CDN worden overgebracht zodra ze zijn voltooid (onder in Afbeelding 2).
Als uw coderingsprogramma bijvoorbeeld segmenten van zes seconden produceerde, zou u een wachttijd van ten minste zes seconden hebben; driemaal zoveel als de normale drie segmenten door de kijker moesten worden ontvangen voordat het afspelen begint. Als je coderingsprogramma echter elke 200 milliseconden brokken heeft gepusht en de speler is geconfigureerd om het afspelen onmiddellijk te starten, zou de latentie veel, veel minder moeten zijn. Een belangrijk voordeel van dit schema is compatibiliteit met eerdere versies; aangezien er nog steeds segmenten worden gemaakt, moeten spelers die niet compatibel zijn met het schema met lage latentie de segmenten nog steeds kunnen afspelen, zij het met een langere latentie. Deze segmenten zijn ook direct beschikbaar voor VOD-presentaties vanuit de livestream.
Naast deze voordelen ondersteunen HTTP-technologieën met lage latentie de meeste functies van hun broers en zussen met normale latentie, waaronder versleuteling, het invoegen van advertenties en ondertiteling, die niet universeel worden ondersteund in op WebRTC en WebSockets gebaseerde technologieën. U kunt de door u geselecteerde technologie met lage latentie waarschijnlijk implementeren met uw bestaande speler- en leveringsinfrastructuur, waardoor ontwikkelings- en andere technologiekosten tot een minimum worden beperkt.
Een HTTP-technologie met lage latentie kiezen
Er zijn twee belangrijke standaarden voor HTTP Adaptive Streaming, HLS en DASH, plus een uniform containerformaat, CMAF. Toen Apple zijn Low Latency HLS-oplossing aankondigde, verdrong het onmiddellijk verschillende grassroots-inspanningen en werd het de technologie bij uitstek voor het leveren van lage latentie aan HLS. Hoewel de specificatie nog relatief nieuw is, wordt deze al ondersteund door technologieleveranciers zoals Wowza en WMSPanel met hun Nimble Streamer-product.
Er is een DVB-standaard voor DASH met lage latentie en het DASH Industry Forum heeft verschillende modi met lage latentie goedgekeurd om DASH in hun volgende interoperabiliteitsrichtlijnen op te nemen. Overeenkomstig al deze specificaties hebben ontwikkelaars van encoders en spelers en netwerken voor het leveren van inhoud al een aantal jaren gewerkt aan interoperabiliteit, zodat alle DASH / CMAF-toepassingen met lage latentie van de grond kunnen komen.
Als voorbeeld, Harmonic en Akamai toonden samen CMAF met lage latentie al in NAB en IBC 2017, waarbij live OTT-levering werd getoond met een latentie van minder dan vijf seconden. Sindsdien heeft Harmonic DASH-functionaliteit met lage latentie geïntegreerd in hun apparaatgebaseerde producten (Packager XOS en Electra XOS) en SaaS-oplossingen (VOS Cluster en VOS260). Veel andere leveranciers van encoders en spelers hebben hetzelfde gedaan.
Of u nu kiest voor Low Latency HLS of Low Latency voor DASH, of beide, de overgang van uw bestaande HLS- en / of DASH-bezorgingsarchitectuur moet relatief naadloos en goedkoop zijn.
5. Real-time communicatie
WebRTC is doorgaans de motor voor een geïntegreerd pakket dat de coderings-, speler- en leveringsinfrastructuur omvat. Voorbeelden van op WebRTC gebaseerde grootschalige streamingoplossingen zijn Real Time van Phenix, Limelight Realtime Streaming en Millicast van CoSMo Software en Influxis (Figuur 3). Je hebt ook toegang tot WebRTC-technologie in tools zoals de Wowza Streaming Engine, CoSMO Software en Red 5 Pro Server. Latentietijden voor technologieën in deze klasse variëren van 0,5 seconden voor 71% van de streams (Phenix), minder dan 500 milliseconden (Red5 Pro) tot minder dan een seconde (Limelight). Als u een latentie van minder dan twee seconden nodig heeft, is WebRTC een optie die u moet overwegen.
Als u realtime communicatie nodig heeft, moet u waarschijnlijk een op WebRTC of Websockets gebaseerde oplossing implementeren. WebRTC is geformuleerd voor browser-naar-browser-communicatie en wordt ondersteund door alle grote desktopbrowsers, op Android, iOS, Chrome OS, Firefox OS, Tizen 3.0 en BlackBerry 10, dus het zou zonder downloads op een van deze platforms moeten werken. Zoals de naam al doet vermoeden, is WebRTC een protocol voor het leveren van livestreams aan elke kijker, ofwel peer-to-peer of server-to-peer.
WebSockets is een real-time protocol dat een permanente verbinding tot stand brengt en onderhoudt tussen een server en client die beide partijen kunnen gebruiken om gegevens te verzenden. Deze verbinding kan worden gebruikt om zowel videolevering als andere communicatie te ondersteunen, dus het is handig als uw toepassing interactiviteit nodig heeft. Net als WebRTC-implementaties worden services die WebSockets gebruiken, doorgaans aangeboden als een service die speler en CDN omvat, en u kunt elke encoder gebruiken die streams naar de server kan transporteren via RTMP of WebRTC. Voorbeelden zijn onder meer Nanocosmos 'nanoStream Cloud en Wowza's Streaming Cloud met ultralage latentie. Wowza claimt een latentie van minder dan 3 seconden voor hun oplossing, terwijl Nanocosmos ongeveer een seconde claimt, glas tegen glas.
Andere technologieën met lage latentie
Er is een vierde categorie producten die het best 'andere' wordt genoemd en die verschillende technologieën gebruiken om een lage latentie te bieden. Deze categorie omvat THEO Technologies High Efficiency Streaming Protocol (HESP), een gepatenteerd HTTP adaptief streamingprotocol dat volgens THEO een latentie van minder dan 100 milliseconden levert terwijl de bandbreedte met ongeveer 10% wordt verminderd in vergelijking met andere technologieën met lage latentie. HESP gebruikt standaard encoders en CDN's, maar vereist aangepaste ondersteuning in de packager en speler (Figuur 4). U kunt hier meer lezen over HESP in een witboek dat u kunt downloaden.
Hier is een lijst met vragen waarmee u rekening moet houden wanneer u besluit welke technologie met lage latentie u wilt implementeren en hoe u dit moet doen.
Bouwen of kopen?
Als u de technologie zelf implementeert, moet u alle onderstaande vragen beantwoorden voordat u een technologie kiest. Als u een serviceprovider kiest, gebruikt u deze om de verschillende serviceproviders te vergelijken.
Kiest u voor een standaard of een partner?
We hebben de verschillende technologieën voor het bereiken van een lage latentie hierboven uiteengezet, maar implementaties variëren van serviceprovider tot serviceprovider. Dus niet alle LL HLS-implementaties zullen ABR-levering bevatten, althans niet in het begin. De meeste traditionele uitzendachtige applicaties zullen waarschijnlijk migreren naar HTTP-gebaseerde standaarden zoals HLS / DASH / CMAF met lage latentie, terwijl applicaties die ultralage latentie vereisen, zoals weddenschappen en veilingen, naar de andere technologieën zullen neigen. In beide gevallen is het bij het kiezen van een serviceprovider belangrijker om te bepalen of deze uw technologische en zakelijke doelen kan bereiken dan welke technologie ze daadwerkelijk implementeren.
Kan het opschalen en tegen welke prijs?
Een van de voordelen van op HTTP gebaseerde technologieën is dat ze kunnen worden geschaald tegen standaardprijzen met de meeste CDN's. Daarentegen vereisen de meeste op WebRTC en WebSocket gebaseerde technologieën een speciale leveringsinfrastructuur die door de serviceprovider wordt geïmplementeerd. Om deze reden kunnen niet-HTTP-gebaseerde services duurder zijn om te leveren dan HLS / DASH / CMAF. Wanneer u serviceproviders vergelijkt, moet u de kosten van de gebeurtenis in verhouding tot de noten vaststellen, inclusief inkomend verkeer, transcodering, bandbreedte, aanmaken van VOD-bestanden, eenmalige of per-gebeurtenis configuraties en dergelijke.
Implementatiegerelateerde problemen?
Stel de volgende vragen met betrekking tot het implementeren en gebruiken van de technologie.
- Wat is de haalbare wachttijd op een schaal die relevant is voor uw doelgroepgrootte en geografische spreiding?
- Zijn er kwaliteitsbeperkingen - sommige technologieën zijn mogelijk beperkt tot bepaalde maximale resoluties of H.264-profielen.
- Gaan de pakketten door een firewall? Op HTTP gebaseerde systemen gebruiken HTTP-protocollen, die firewallvriendelijk zijn. Anderen gebruiken UDP, dat mogelijk niet automatisch door firewalls gaat. Als UDP, zijn er backchannels om aan geblokkeerde kijkers te leveren?
- Welke platforms worden ondersteund? Vermoedelijk computers en mobiele apparaten, maar hoe zit het met STB's, dongles, OTT-apparaten en smart-tv's?
- Kan het systeem worden geschaald om te voldoen aan de aantallen kijkers? Is de CDN-infrastructuur privé en zo ja, kan deze worden geleverd aan alle relevante kijkers in alle relevante markten? Wat zijn de verwachte kosten van schaalvergroting?
- Kun je je eigen speler gebruiken of moet je de speler van het systeem gebruiken? Als die van u zijn, welke wijzigingen zijn dan nodig en hoeveel kost dat?
- Wat is er nodig voor mobiel afspelen? Worden de streams in een browser afgespeeld of is een app vereist? Als er een app vereist (of wenselijk) is, zijn er dan SDK's beschikbaar?
- Welke encoders kan het systeem gebruiken? De meesten zouden elke encoder moeten gebruiken die RTMP-verbindingen naar de cloudtranscoder kan ondersteunen, maar controleer of er andere protocollen nodig zijn.
- Kan de inhoud worden hergebruikt voor VOD of is hercodering vereist? Geen groot probleem, aangezien het ongeveer $ 20 / uur aan video kost om naar een redelijke coderingsladder te transcoderen, maar duur voor frequente uitzendingen.
- Wat zijn de afvloeiingsmogelijkheden en wat zijn de kosten? Voor missiekritieke uitzendingen wilt u weten hoe u de coderings- / uitzendworkflow kunt dupliceren als een systeemcomponent tijdens het evenement uitvalt. Wordt deze redundantie ondersteund en wat zijn de kosten?
Welke functies zijn beschikbaar en op welke schaal?
Er zal een breed scala aan functieaanbiedingen zijn van de verschillende leveranciers, waaronder al dan niet:
- ABR-streaming - hoeveel streams en zijn er relevante bitrate- of resolutiebeperkingen?
- Hoe zit het met DVR-functies? Kunnen de kijkers het afspelen stoppen en opnieuw starten zonder dat er inhoud verloren gaat?
- Videosynchronisatie - Kan het systeem alle kijkers naar hetzelfde punt in de stream synchroniseren? Streams kunnen over locaties en apparaten drijven, en zonder deze mogelijkheid kunnen gebruikers op sommige verbindingen een voordeel hebben bij veilingen of gokken.
- Welke inhoudsbescherming is beschikbaar? Als je een producent van premium content bent, heb je misschien echte DRM nodig. Anderen kunnen zich redden met authenticatie of andere soortgelijke technieken.
- Zijn er ondertitels beschikbaar? Bijschriften zijn wettelijk verplicht voor sommige uitzendingen, maar over het algemeen voordelig voor iedereen.
- Hoe zit het met het invoegen van advertenties of een ander schema voor het genereren van inkomsten? Ondersteunt de technologie / serviceprovider dit?
In het algemeen, als je een streamingwinkel bent die uitzendtijden in het bereik van 5 tot 6 seconden wil ontmoeten of verslaan, is een op standaarden gebaseerde HTTP-technologie waarschijnlijk de beste keuze, omdat deze het dichtst in de buurt komt om dezelfde functieset te ondersteunen als jij ' momenteel opnieuw worden gebruikt, zoals inhoudsbescherming, ondertiteling en het genereren van inkomsten. Als je een applicatie hebt die een veel kortere latentie vereist, heb je waarschijnlijk een op WebRTC of Websockets gebaseerde oplossing of een eigen HTTP-technologie nodig. In beide gevallen zou het stellen van de bovenstaande vragen u moeten helpen de technologie en / of serviceprovider te identificeren die het beste aan uw behoeften voldoet.
