Från de första dagarna av arbetet med ett molnvideoövervakningssystem stod vi inför ett problem, utan en lösning som vi kunde ge upp på Ivideon - detta var vår Everest, klättring som tog mycket energi, men nu har vi äntligen stack en isyxa i toppen av plattformspusslet.
Systemet för att överföra ljud och video över Internet bör inte vara beroende av utrustning, webbklienter och de standarder de stöder, och fungerar även korrekt i närvaro av nätverksadressöversättare och brandväggar. En användare av molnvideoövervakning vill komma åt tjänsten, även om han använder analoga kameror, och föredrar att se livevideosändningar på den modernaste enheten.
Det är mycket viktigt att användaren vill titta på videor med minimal fördröjning. Nästan det enda sättet att visa video med låg latens i en webbläsare är att använda WebRTC (web realtime communications). WebRTC är en uppsättning tekniker för peer-to-peer-överföring av video och ljud i webbläsare, från början designad för överföring och uppspelning av videoströmmar med låg latens. För detta ändamål används bland annat UDP-protokollet.
Innan vi berättar vad den nya motorn ger användaren, kommer vi att påminna dig om varför och varför vi stöder HLS-teknologier, och varför vi bestämde oss för att gå vidare.
HLS-motor: för- och nackdelar
()
HLS-tekniken (HTTP Live Streaming) utvecklades av Apple, så det är ingen överraskning att den först stöddes på Apple-enheter. Idag stöds HLS-video också av praktiskt taget alla set-top-boxar och många enheter som kör operativsystemet. Android.
HLS-motorn använder den välkända H264-videokodeken i kombination med AAC- eller MP3-ljudströmmar för att strömma videodata. Hela ljud- och videodataströmmen paketeras i en MPEG-TS-transportbehållare. För överföring via HTTP-protokollet är informationen i strömmen uppdelad i fragment som beskrivs i m3u8-spellistor. Och först då sänds dessa fragment, tillsammans med spellistor, via HTTP. Chunking innebär automatiskt en fördröjning i sekunder. Detta är en funktion hos MPEG-TS-behållaren.
HLS-motorn stöder även multibitrate-strömmar, Live/VOD.
Huvudfördelarna med HLS:
- inbyggt stöd i alla större webbläsare;
- enkel implementering (jämfört med WebRTC);
- Det är väldigt bekvämt och effektivt att organisera alla typer av sändningar till en stor publik på grund av att segment kan laddas upp till ett CDN en gång.
Trots motorns enkelhet är inte allt så smidigt som det verkar. Det största problemet är att tredjepartsspelares utvecklare har gått bort från Apples rekommendationer, till exempel när det gäller ljudformat som stöds. I synnerhet började många utvecklare lägga till möjligheten att arbeta med populära ljudströmmar: mpeg2-video, mpeg2-ljud, etc. Som ett resultat var de tvungna att skapa olika spellistformat för olika spelare.
Men ett av de största problemen med HLS-motorn är den höga latensen vid dataöverföring.
Ursprunget till "bromsar"
Den främsta orsaken till den höga latensen hos HLS ligger i det faktum att programmerare skapade motorn för att få bilder av högsta kvalitet. Därför är parametrarna för det använda ramintervallet och storleken på uppspelningsbufferten helt enkelt inte lämpliga för livevideosändningar. På grund av detta är det en ganska stor fördröjning i överföringen av videofilmer, som kan vara 5-7 sekunder.
Å ena sidan är detta inte mycket, till exempel för den som tittar på en film från en videohosting-server. Men för videoövervakningssystem kan förseningen i överföringen av videofilmer vara mycket viktig.
Om du tittar på ett kontor där anställda tittar upp från sina bildskärmar en gång i timmen, så spelar en fördröjning på 5 sekunder ingen roll. Men folk började klaga på att de till exempel när de sänder en fotbollsmatch redan skrivit GOOOOL i chatten, men detta finns inte på videon ännu :). Vi har redan ett antal användarfall där Ivideon praktiskt taget borde ersätta Skype.
Är det möjligt att slå latens i HLS? Svaret på denna fråga låter som talet av en erfaren råttutrotare vid en föreläsning för nybörjare på skadedjursbekämpningsspecialister: "Råttor kan inte utrotas, men deras antal kan reduceras till ett rimligt minimum." Samma med förseningen i HLS, det kommer inte att gå att reducera den till noll, men det finns lösningar på marknaden som kan minska förseningen avsevärt.
Fina snitt
En annan nackdel med motorn är användningen av små filer för dataöverföring. Det verkar som att vad är felet med detta?
Alla som har försökt kopiera ett stort antal små filer från ett medium till ett annat har förmodligen märkt att skrivhastigheten för en sådan uppsättning är mycket lägre än en stor fil av samma storlek. Och intensiteten av åtkomst till hårddisken ökar avsevärt, vilket generellt sett negativt påverkar hela datorns prestanda. Därför bidrar även överföring av videodata i små 10 sekunders bitar till ökad motorlatens.
Låt oss kort sammanfatta alla för- och nackdelar med HLS-teknik.
Fördelar med HLS:
- Förmåga att arbeta med alla enheter. Du kan titta på videor på vilken modern enhet som helst, oavsett om det är en smartphone, surfplatta, bärbar dator eller stationär PC. Huvudsaken är att webbläsaren är uppdaterad och kompatibel med HTML5 och Media Source Extensions.
- Utmärkt bildkvalitet. Den adaptiva dataöverföringsfunktionen som används gör att du dynamiskt kan ändra kvaliteten på den överförda videon beroende på internetanslutningens bandbredd, medan algoritmen strävar efter att bibehålla maximal kvalitet.
- Det finns inget behov av komplex konfiguration av användarens utrustning.
Nackdelar:
- Begränsat stöd för att arbeta med motorn på vissa enheter.
- Stora förseningar i bildöverföring.
- Betydande ökning av omkostnader och komplexitet i optimeringen på grund av användningen av små filer. På grund av behållarens natur kommer vi aldrig att kunna få en fördröjning som är lägre än segmentstorleken.
Nackdelarna med HLS uppvägde dess fördelar för oss och tvingade oss att leta efter alternativa alternativ.
Vad är WebRTC
()
WebRTC-plattformen utvecklades av Google 2011 för att överföra strömmande video- och ljuddata mellan webbläsare och mobilapplikationer med minimal latens. För detta används standard UDP-protokollet och speciella flödeskontrollalgoritmer. Idag är det ett projekt med öppen källkod, det underhålls aktivt av Google och håller på att utvecklas.
WebRTC är en uppsättning tekniker för peer-to-peer video- och ljudöverföring. Det vill säga att till exempel användarwebbläsare som använder WebRTC kan överföra data till varandra direkt, utan att använda fjärrservrar för att lagra och bearbeta data. All information behandlas även av slutanvändarnas webbläsare och mobilapplikationer.
Bekvämligheten och de omfattande funktionerna hos denna teknik har uppskattats av utvecklare av alla populära webbläsare. WebRTC-stöd är för närvarande tillgängligt i Mozilla Firefox, Opera, Google Chrome (och alla Chromium-baserade webbläsare), såväl som i mobilappar som kör ... Android och iOS.
Trots alla dess otvivelaktiga fördelar har WebRTC flera betydande nackdelar.
Svårigheter att välja
WebRTC-tekniken är mycket mer komplex när det gäller nätverksinteraktioner på grund av att det handlar om P2P. Det är svårt att felsöka, testa och kan bete sig oförutsägbart. Samtidigt måste vi övervinna NAT och brandvägg, vi måste säkerställa drift i nätverk där UDP är blockerad.
Googles WebRTC-implementering är mycket svår att använda. Det finns till och med ett helt företag som tillhandahåller SDK-monteringstjänster. Dessutom var Googles implementering mycket svår att integrera med vårt system utan att koda om hela videon.
Vi har dock länge velat ge användarna möjlighet att arbeta med fullfjädrad "live"-video och minimera fördröjningen mellan bilden på skärmen och själva händelserna. Dessutom hade vi en önskan att göra användningen av PTZ-kameror, där förseningar är kritiska, mer bekväm.
Med tanke på att andra anti-lag-implementationer fortfarande har begränsad funktionalitet och fungerar märkbart sämre, bestämde vi oss för att använda WebRTC.
Vad har vi gjort
Att korrekt implementera WebRTC-plattformen är inte en lätt uppgift. Eventuella felberäkningar eller felaktigheter kan leda till att förseningar i videoöverföringen inte bara minskar jämfört med andra plattformar, utan till och med ökar.
För att WebRTC ska fungera korrekt är det först och främst nödvändigt att genomföra en teknisk uppgradering av stacken för att arbeta med webbvideo. Det var vad vi gjorde.
Först implementerade vi en WebRTC-signalprotokollserver över Websocket och distribuerade även en WebRTC-peer-server i molnet baserad på webrtc.org SDK. Dess uppgift är att distribuera videoströmmar till klient WebRTC-peers i H.264 + Opus/G.711-format utan videoomkodning.
Vi valde Websocket som signaleringsprotokoll eftersom det redan har högkvalitativt stöd i alla populära webbläsare. På grund av detta kan du avsevärt minska inte bara utvecklingskostnader, utan också undvika att slösa tid och resurser på upprepade TCP- och TLS-handslag jämfört med AJAX.
Faktum är att WebRTC som standard inte tillhandahåller det signaleringsprotokoll som krävs för att korrekt konfigurera, underhålla och avsluta videokommunikation i realtid mellan källan och klientapplikationerna.
Och för att självständigt implementera signaleringsteknik behövde vi utveckla en egen signalserver med stöd för flera webbprotokoll (Websocet, WebRTC). Och med möjligheten att säkert hantera sessioner och aviseringar i realtid, videohantering och mycket mer.
Vi övervann begränsningarna för P2P genom att minska latensen inte genom P2P, utan genom UDP och flödeskontroll för att minska latensen. Detta är också inbyggt i WebRTC, eftersom det huvudsakliga användningsfallet är p2p-konversationer via en webbläsare.
I den mobila klienten implementerade vi spelaren med webrtc.org SDK, eftersom endast den implementerar flödeskontroll korrekt, har alla kända FEC-scheman (Forward Error Correction) och implementerar korrekt mekanismen för att skicka om paket för alla webbläsare. Det är också viktigt att webrtc.org SDK aktivt utvecklas av Google.
Vad är resultatet av att implementera WebRTC?
För att se livevideo från kameror har vi lagt till en ny optimerad spelare baserad på WebRTC till ditt personliga konto. Det ger snabba videoladdningshastigheter och eliminerar helt problemet med latens som ackumuleras när visningstiden ökar.
Efter att ha introducerat WebRTC-stöd i molntjänsten Ivideon kan vi med full tillförsikt säga att våra kunder nu kan se fullfjädrad livevideo. Nu överstiger inte fördröjningen vid sändning av videosekvenser en sekund! Som jämförelse tillhandahöll den tidigare HLS-motorn videoleverans med en fördröjning på 5-7 sekunder. Skillnaden i videodemonstrationshastighet är mycket betydande, och användaren kommer att märka det direkt efter att ha börjat arbeta med vår videotjänst.
Som vi förväntade oss har implementeringen av den nya spelaren förbättrat responsen hos PTZ och röstkommunikation med kameran.
Det finns bara en subtil punkt som vi vill uppmärksamma. Den nya WebRTC-spelaren arbetar för närvarande i testläge. Och det är därför vi inte aktiverar det för alla våra kunder som standard. Men du kan aktivera det själv genom att aktivera motsvarande objekt i kamerainställningarna (för att göra detta måste du gå till ).
Funktioner för implementeringen av WebRTC i Ivideon-tjänsten
WebRTC är fortfarande en experimentell teknik för tillfället. Dess stöd är ännu inte korrekt implementerat i alla webbläsare och användarenheter, och inte heller i alla kameror.
Det är just därför vi ännu inte har gjort WebRTC-spelaren till standard för alla användare.
För närvarande rekommenderar vi att du endast använder WebRTC i Google Chrome-webbläsare. De senaste versionerna av Firefox och Safari stöder också denna teknik, men tyvärr är den fortfarande instabil.
Vi har ännu inte implementerat WebRTC-stöd för webbläsare på mobila enheter. För närvarande, om du loggar in från en mobil enhet och aktiverar WebRTC, kommer detta läge inte att fungera. WebRTC är dock tillgängligt i våra mobilapplikationer för и .
Och för att avsluta historien om funktionerna i WebRTC-implementeringen i vår tjänst, låt oss notera ytterligare två subtila punkter.
För det första är tekniken fokuserad på att sända livevideo i realtid. Därför, om din kanal inte har tillräckligt med bandbredd för att överföra videon, kommer du att märka bildrutefall (med HLS kommer du att märka videofading och ökad latens, men det kommer inte att finnas några bildrutefall), men videon kommer fortfarande att sändas på riktigt tid.
För det andra, eftersom tekniken är designad för att fungera specifikt med livevideo i realtid, använder vi den inte för att arbeta med arkiverad videodata.
Andra ändringar av tjänsten
För närvarande är Flash inte längre involverat i den automatiska motorvalsmekanismen. Du kan fortfarande använda en sådan spelare, men för att göra detta måste du välja den manuellt i konto- eller kamerainställningarna. Detta är inte en hyllning till mode, det är bara det att enligt statistiken för vår tjänst finns det praktiskt taget inga användare kvar som arbetar med Flash. Och när vi försöker avgöra om användarens webbläsare stöder det, förlorar vi cirka 2 sekunder av dyrbar tid.
Här är en kort översikt över de förändringar som väntar dig i vårt molnvideoövervakningssystem och personliga konto. Stanna hos oss och följ nyheterna!
Källa: will.com
