Idag är vi glada över att introducera Samtidig streamingacceleration, en ny teknik för att minska den helt slutna latensen för livevideo på webben när du använder Stream Delivery. Låt oss gräva i live-streaming latens, varför det är viktigt och vad folk har gjort för att förbättra det.
Hur ”live” är ”live” video?
Livestreaming utgör en ökande andel video på webben. Oavsett om det är en TV-sändning, ett livespelprogram eller ett online-klassrum förväntar sig användarna att videon kommer snabbt och smidigt. Och löftet om ”live” är att användaren ser händelser när de händer. Men hur nära ”realtid” är ”live” Internetvideo?
Att leverera livevideo på Internet är fortfarande svårt och lägger till massor av latens:
Innehållskällan spelar in video och skickar den till en kodningsserver.
Ursprungsservern omvandlar den här videon till ett format som DASH, HLS eller CMAF som kan levereras till miljontals enheter effektivt;
Ett CDN används vanligtvis för att leverera kodad video över hela världen
Klientspelare avkodar videon och återger den på skärmen
Och allt detta är under en tidsbegränsning – hela processen måste ske om några sekunder, annars kommer videoupplevelser att lida. Vi kallar den totala fördröjningen mellan när videon spelades in och när den kan ses på en slutanvändares enhet, som ”end-to-end latens” (tänk på det som tiden från kameralinsen till telefonens skärm).
Traditionell segmenterad leverans
Videoformat som DASH, HLS och CMAF fungerar genom att dela upp video i små filer, så kallade ”segment”. En typisk segmentvaraktighet är 6 sekunder.
Om en klientspelare behöver vänta på att ett helt 6s-segment ska kodas, skickas via ett CDN och sedan avkodas, kan det vara en lång väntan! Det tar ännu längre tid om du vill att klienten ska bygga upp en buffert av segment för att skydda mot eventuella avbrott i leveransen. En typisk spelarbuffert för HLS är 3 segment:
När du överväger kodningsfördröjningar är det lätt att se varför fördröjningen för livestreaming på Internet vanligtvis har varit cirka 20-30 sekunder. Vi kan bättre.
Minskad latens med segmenterad överföringskodning
Ett naturligt sätt att lösa det här problemet är att göra det möjligt för klientspelare att börja spela bitarna medan de laddar ner, eller till och med medan de fortfarande skapas. För att göra detta möjligt krävs ett smart samarbete för att koda och leverera filerna på ett visst sätt, så kallad ”chunked encoding”. Detta innebär att dela upp segment i mindre bitar eller ”bitar”. Segmenterad kodning kan vanligt vis minska svarstiden till 5 eller 10 sekunder.
HTTP-segment är viktiga eftersom webbklienter har begränsad förmåga att bearbeta dataströmmar. De flesta klienter kan bara arbeta med data när de har fått det fullständiga HTTP-svaret, eller åtminstone ett komplett HTTP-segment. Genom att använda HTTP-segmenterad överföringskodning gör vi det möjligt för videospelare att börja tolka och avkoda video tidigare.
CMAF-segment är viktiga så att avkodare faktiskt kan spela de bitar som finns i HTTP-segmenten. Utan att koda video på ett försiktigt sätt skulle avkodare ha slumpmässiga bitar av en videofil som inte kan spelas upp.
CDN kan införa ytterligare buffring
Chunked kodning med HLS och CMAF växer i bruk över webben idag. En del av det som gör den här tekniken bra är att HTTP-segmenterad kodning stöds i stor utsträckning av CDN – det har varit en del av HTTP-specifikationerna i 20 år.
CDN-stöd är avgörande eftersom det gör det möjligt för livevideo med låg latens att skala upp och nå målgrupper för tusentals eller miljoner samtidiga tittare – något som för närvarande är mycket svårt att göra med andra icke-HTTP-baserade protokoll.
Tyvärr, även om du aktiverar segmentering för att optimera leveransen, kan ditt CDN fungera mot dig genom att buffra hela segmentet. För att förstå varför överväga vad som händer när många människor begär ett livesegment samtidigt:
Cloudflares lösning: Samtidig streamingacceleration
Som du kanske har gissat, tror vi att vi kan göra bättre. Enkelt uttryckt har vi nu möjlighet att leverera olagrade filer till flera klienter samtidigt medan vi hämtar filen en gång från ursprungsservern.
Detta låter som en enkel förändring, men det finns mycket subtilitet att göra detta säkert. Under huven har vi gjort djupgående ändringar i vår cachelagringsinfrastruktur för att ta bort cachelåset och göra det möjligt för flera klienter att säkert kunna läsa från en enda fil medan den fortfarande skrivs.
Det bästa är – hela Cloudflare fungerar nu på detta sätt! Det finns inget behov av att anmäla sig, eller ens göra en konfigurationsändring för att få förmånen.
Vi rullade ut den här funktionen för ett par månader sedan och har varit riktigt nöjda med resultaten hittills. Vi mäter framgång med väntetiden ”cachelås”, det vill säga hur länge en begäran måste vänta på andra förfrågningar – en direkt komponent i Time To First Byte. En OTT-kund såg detta mått sjunka från 1,5 på P99 till nästan 0, som förväntat: