WebRTC och videövervakning: hur vi besegrade fördröjningen i videoströmmen från kameror

Från första dagen av arbetet med vårt molnbaserade övervakningssystem stötte vi på ett problem som utan en lösning skulle sätta en begränsning för Ivideon – det var vår Everest, vars bestigning krävde enorma resurser, men nu har vi äntligen stuckit isyxan i toppen av det plattformsöverskridande pusslet.

Systemet för ljud- och videoöverföring över internet bör inte vara beroende av utrustning, webbläsarklienter och de standarder som de stöder. Det ska också fungera korrekt när det finns Network Address Translators och brandväggar. Användaren av molnbaserad övervakning vill få tillgång till tjänsten, även om den använder analoga kameror och föredrar att se livevideo på den senaste enheten.

Det är mycket viktigt att användaren vill se video med minimal fördröjning. Den praktiskt taget enda möjligheten att visa video med låg fördröjning i webbläsaren är att använda WebRTC (web real-time communications). WebRTC är en uppsättning teknologier för peer-to-peer överföring av video och ljud i webbläsare, ursprungligen avsedd för överföring och uppspelning av videoströmmar med låg fördröjning. Detta använder, bland annat, UDP-protokollet.

Innan vi berättar vad den nya motorn ger användaren, påminner vi om varför och hur vi stöder HLS-teknologier och varför vi har beslutat att gå vidare.

HLS-motor: fördelar och nackdelar

(c)

Tekniken HLS (HTTP Live Streaming) utvecklades av Apple, så det är inte förvånande att det först blev stöd för den på enheter från just detta märke. Idag kan nästan alla tv-boxar och många enheter som kör Android också reproducera video i HLS-format.

HLS-motorn använder den välkända videokodeken H264 i kombination med AAC- eller MP3-ljudströmmar för videodataöverföring. Hela ljud- och videoströmmen paketeras i transportcontainern MPEG-TS. För överföring via HTTP delas informationen i strömmen upp i fragment som beskrivs i m3u8-spellistor. Dessa fragment tillsammans med spellistorna överförs sedan via HTTP. Uppdelningen i fragment innebär automatiskt fördröjningar i sekunder. Det är en särskild egenskap hos MPEG-TS-containern.

HLS-motorn stöder också multi-bitrate strömmar, Live/VOD.

De huvudsakliga fördelarna med HLS:

• inbyggt stöd i alla stora webbläsare;
• enkelt att implementera (jämfört med WebRTC);
• väldigt bekvämt och effektivt att organisera olika sändningar till en stor publik tack vare att segment kan laddas en gång på CDN.

Trots att motorn är enkel, är inte allt så smidigt som det verkar. Huvudproblemet är att utvecklarna av tredjeparts spelfilmer har avvikit från Apples rekommendationer, exempelvis när det gäller stödda ljudformat. Många utvecklare har specifikt börjat lägga till stöd för populära ljudströmmar: mpeg2 video, mpeg2 audio osv. Resultatet blev att olika spellisteformat var tvungna att skapas för olika spelare.

Men en av de största problemen med HLS-motorn är den höga fördröjningen i dataöverföringen.

Ursprunget till 'stötarna'

Den främsta orsaken till den höga fördröjningen i HLS ligger i det faktum att programmerarna skapade motorn för att få maximal bildkvalitet. Därför passar inte parametrarna för den använda bildfrekvensen och buffertvolymen för direkt videoströmning. Detta leder till en ganska hög fördröjning i videoströmningen, som kan uppgå till 5-7 sekunder.

Å ena sidan är det lite, till exempel för dem som tittar på en film från en videohostingsserver. Men för övervakningssystem kan fördröjningen i videoströmmen ha stor betydelse.

Om du övervakar ett kontor där anställda släpper skärmarna en gång i timmen, spelar 5 sekunder ingen roll. Men folk har börjat klaga på att till exempel under sändningen av en fotbollsmatch, i chatten redan har skrivit MÅÅÅL, men på videon syns det fortfarande inte :). Vi har redan flera användartester där Ivideon på praktiskt taget ska ersätta Skype.

Kan fördröjningen i HLS övervinnas? Svaret på denna fråga låter som en veteran råttjägare som föreläser för nybörjare: "Det går inte att utrota råttor, men deras antal kan reduceras till en rimlig minimivärde". Så det är med fördröjningen i HLS, att få den till noll är inte möjligt, men det finns lösningar på marknaden som kan minska fördröjningen avsevärt.

Fin klippning

En annan nackdel med motorn är användningen av små filer för dataöverföring. Det verkar som att det inte är så dåligt?

Någon som har försökt att kopiera ett stort antal små filer från en enhet till en annan har säkert märkt att skrivhastigheten för en sådan uppsättning är mycket lägre än för en enda stor fil av samma storlek. Dessutom ökar intensiteten av åtkomsten till hårddisken avsevärt, vilket i sin helhet påverkar datorns prestanda negativt. Därför bidrar överföring av videodata i form av små 10-sekunders fragment också till den ökade latensen i motorn.

Låt oss kort sammanfatta alla fördelar och nackdelar med HLS-teknologi.

Fördelarna med HLS:

1. Möjlighet att arbeta med alla enheter. Du kan titta på video på vilken modern enhet som helst, vare sig det är en smartphone, surfplatta, bärbar dator eller stationär dator. Det viktigaste är att webbläsaren är av modern version och kompatibel med HTML5 och Media Source Extensions.
2. Utmärkt bildkvalitet. Den använda funktionen för adaptiv dataöverföring gör det möjligt att dynamiskt ändra kvaliteten på den överförda videoströmmen beroende på bandbredden i internetanslutningen, samtidigt som algoritmen strävar efter att bevara kvaliteten så hög som möjligt.
3. Ingen behov av komplicerade användarinställningar.

Nackdelar:

1. Begränsat stöd för motor på vissa enheter.
2. Höga latenser i bildöverföringen.
3. Starkt ökad overhead och komplexitet i optimeringen på grund av användning av små filer. På grund av behoven hos containern kan vi aldrig få en latens som är lägre än segmentets storlek.

Nackdelarna med HLS övergick för oss dess fördelar och gjorde oss tvungna att leta efter alternativa lösningar.

Vad är WebRTC

(c)

WebRTC-plattformen utvecklades av Google 2011 för att överföra strömmande video- och ljuddata mellan webbläsare och mobilapplikationer med minimal latens. Detta görs med hjälp av den standardiserade UDP-protokollet och speciella algoritmer för flödeshantering. Idag är det ett projekt med öppen källkod, som aktivt stödjs och utvecklas av Google.

WebRTC är en uppsättning teknologier för peer-to-peer överföring av video och ljud. Det innebär att användarnas webbläsare med hjälp av WebRTC kan överföra data direkt till varandra, utan att använda externa servrar för lagring och bearbetning av information. All information bearbetas också av webbläsare och mobilapplikationer hos slutkonsumenterna.

Bekvämligheten och de stora möjligheterna med denna teknologi har uppskattats av utvecklare av alla populära webbläsare. Idag stöds WebRTC i Mozilla Firefox, Opera, Google Chrome (och alla webbläsare baserade på Chromium), samt i mobilapplikationer för Android och iOS.

Trots sina självklara fördelar har WebRTC några betydande nackdelar.

Svårigheter med valet

WebRTC-teknologin är mycket mer komplex när det kommer till nätverksinteraktioner på grund av att den är baserad på P2P. Den är svår att debugga och testa, och den kan bete sig oförutsägbart. Dessutom behöver vi övervinna NAT och brandväggar, och säkerställa att den fungerar i nätverk där UDP är blockerat.

Det är mycket svårt att använda Googles version av WebRTC. Det finns till och med ett helt företag som erbjuder tjänster för att bygga SDK. Dessutom var det mycket svårt att integrera Googles lösning med vårt system utan att behöva omkoda all video.

Vi har länge velat ge användare möjlighet att arbeta med riktig "live" video och minimera fördröjningen mellan bilden på skärmen och de faktiska händelserna. Dessutom ville vi göra användningen av PTZ-kameror mer bekväm, där fördröjningar är kritiska.

Med tanke på att andra implementeringar för att bekämpa fördröjningar fortfarande har begränsad funktionalitet och fungerar betydligt sämre, beslutade vi oss för att använda WebRTC.

Vad vi har gjort

Att korrekt implementera WebRTC-plattformen är en svår uppgift. Varje felaktighet eller avvikelse kan leda till att fördröjningarna i videoströmmen inte bara inte minskar jämfört med andra plattformar, utan också ökar.

För att WebRTC ska fungera korrekt är det först och främst nödvändigt att genomföra en teknologisk modernisering av stacken för att arbeta med webbvideo. Det har vi gjort.

Först implementerade vi en signaleringsserver för WebRTC-protokollet över Websocket, samt distribuerade en WebRTC peer-server i molnet baserat på SDK webrtc.org. Dess uppgift är att fördela videoströmmar till klienternas WebRTC peers i H.264 + Opus/G.711 format utan att koda om videon.

Vi valde Websocket som signaleringsprotokoll eftersom det redan har ett bra stöd i alla populära webbläsare. Detta gör det möjligt att avsevärt minska inte bara utvecklingskostnaderna utan också att spara tid och resurser genom att undvika upprepade TCP- och TLS-handshakes jämfört med AJAX.

Saken är den att WebRTC som standard inte erbjuder det signaleringsprotokoll som behövs för korrekt konfiguration, support och nedkoppling av videokommunikation i realtid mellan käll- och klientapplikationer.

För att själva implementera signaleringsteknologin behövde vi utveckla vår egen signalserver med stöd för flera webbprotokoll (Websocet, WebRTC). Detta inkluderade säker hantering av sessioner och meddelanden i realtid, videostyrning och många andra parametrar.

Begränsningar med P2P övervann vi genom att minska latensen inte via P2P, utan genom UDP och strömhantering syftande till att reducera latensen. Detta är också en del av WebRTC, eftersom den primära användningen är p2p-samtal via webbläsaren.

I mobilklienten implementerade vi en spelare med användning av SDK webrtc.org, eftersom endast den har korrekt implementerat strömhantering, alla kända scheman för Forward Error Correction (FEC) och en korrekt implementerad mekanism för paketåterföring för alla webbläsare. Det är också viktigt att notera att SDK webrtc.org aktivt utvecklas av Google.

Vad är resultatet av att implementera WebRTC?

För att titta på livevideo från kameror har vi lagt till en ny optimerad spelare baserad på WebRTC i användarens konto. Den säkerställer hög hastighet vid videoladdningen och eliminerar helt problemet med ackumulerad latens i takt med att visningstiden ökar.

Efter införandet av WebRTC-stöd i molntjänsten Ivideon kan vi med fullständig säkerhet säga att våra kunder nu har tillgång till att se fullt levande video. För närvarande överstiger inte fördröjningen vid överföring av videoström en sekund! Som jämförelse gav den tidigare HLS-motorn en videoleverans med en fördröjning på 5-7 sekunder. Skillnaden i hastighet för videovisning är mycket betydande, och användaren kommer att märka detta direkt efter att ha börjat använda vår videoservice.

Som vi förväntade oss har implementeringen av den nya spelaren ökat responsiviteten för PTZ och röstkommunikation med kameran.

Det finns bara en liten punkt som vi vill uppmärksamma. Den nya WebRTC-spelaren fungerar för närvarande i testläge. Av den anledningen aktiverar vi inte den automatiskt för alla våra kunder. Men du kan aktivera den själv genom att välja motsvarande alternativ i kamerans inställningar (för detta behöver du gå till ditt personliga konto).

Egenskaper för WebRTC-implementeringen i Ivideon-tjänsten

WebRTC är för närvarande fortfarande en experimentell teknik. Dess stöd har ännu inte implementerats korrekt i alla webbläsare och användarapparater, samt inte i alla kameror.

Det är just detta som förklarar varför vi ännu inte har gjort WebRTC-spelaren standard för alla användare.

Vi rekommenderar för närvarande att använda WebRTC endast i Google Chrome-webbläsare. De senaste versionerna av Firefox och Safari stöder också denna teknik, men tyvärr är det fortfarande instabilt.

Vi har ännu inte infört WebRTC-stöd för webbläsare på mobila enheter. Om du nu loggar in från en mobil enhet och aktiverar WebRTC kommer detta läge att fungera inte. Däremot finns WebRTC i våra mobilapplikationer för Android och iOS.

Och som avslutning på vår berättelse om egenskaperna hos WebRTC-implementeringen i vår tjänst vill vi nämna ytterligare två viktiga punkter.

För det första är tekniken inriktad på att strömma just levande video i realtid. Därför, om din kanalbredband inte är tillräcklig för att överföra videoströmmen, kommer du att märka att bilder faller bort (med HLS kommer du att märka att videon fryser och fördröjningen ökar, men bilder kommer inte att falla bort), men videon kommer fortfarande att strömmas i realtid.

För det andra, eftersom teknologin är avsedd för att arbeta med livevideo i realtid, använder vi den inte för att hantera arkiverade videodata.

Andra ändringar i tjänsten

För närvarande deltar inte Flash längre i mekanismen för automatisk val av motor. Du kan fortfarande använda en sådan spelare, men du måste välja den manuellt i inställningarna för ditt konto eller din kamera. Detta är inte en trend, utan enligt statistiken från vår tjänst finns det praktiskt taget inga användare kvar som arbetar med Flash. Och på försöket att avgöra om användarens webbläsare stöder det, förlorar vi runt 2 sekunders värdefull tid.

Här är en kort sammanfattning av de förändringar som väntar dig i vårt molnbaserade övervakningssystem och din personliga portal. Håll dig uppdaterad med oss och följ nyheterna!

Källa: habr.com