Vanaf de eerste dagen dat we aan het cloud videobewakingssysteem werkten, stuitten we op een probleem waarvan de oplossing cruciaal was voor Ivideon ā het was onze Everest, waarvan de beklimming ons veel energie kostte, maar nu hebben we eindelijk de ijsklomp in de top van de cross-platform puzzel gestoken.
Het systeem voor geluids- en videotransmissie via het internet mag niet afhankelijk zijn van hardware, webclients en de standaarden die zij ondersteunen, en moet ook correct functioneren bij aanwezigheid van Network Address Translators en firewalls. De gebruiker van cloud videobewaking wil toegang tot de dienst, zelfs als hij analoge camera's gebruikt, en de live videostream wil bekijken op het nieuwste apparaat.
Het is van groot belang dat de gebruiker video wil bekijken met minimale vertraging. De praktisch enige mogelijkheid om video met lage vertraging in de browser te tonen, is door gebruik te maken van WebRTC (web real-time communications). WebRTC is een set technologieƫn voor peer-to-peer overdracht van video en audio in browsers, oorspronkelijk ontwikkeld voor de overdracht en weergave van videostreams met lage vertraging. Hiervoor wordt onder andere het UDP-protocol gebruikt.
Voordat we u vertellen wat de nieuwe engine de gebruiker biedt, herinneren we u eraan waarom we HLS-technologieƫn ondersteunen en met welk doel we verder willen gaan.
HLS-engine: voor- en nadelen
()
De HLS-technologie (HTTP Live Streaming) is ontwikkeld door Apple, dus het is niet verwonderlijk dat de ondersteuning hiervoor eerst op apparaten van dit merk verscheen. Tegenwoordig kunnen bijna alle tv-ontvangers en vele apparaten die op Android draaien, ook video in HLS-formaat afspelen.
De HLS-engine gebruikt de bekende videocodec H264 voor videotransmissie, in combinatie met AAC- of MP3-audiostreams. De gehele audio- en videostream wordt verpakt in de transportcontainer MPEG-TS. Voor verzending via het HTTP-protocol wordt de informatie in de stream opgedeeld in fragmenten, beschreven in m3u8-playlists. Pas daarna worden deze fragmenten samen met de playlists via HTTP verzonden. Het opdelen in fragmenten betekent automatisch een vertraging in seconden. Deze eigenschap van de MPEG-TS-container.
De HLS-engine ondersteunt ook multi-bitrate streams, Live/VOD.
Belangrijkste voordelen van HLS:
- ingebouwde ondersteuning in alle belangrijke browsers;
- eenvoudige implementatie (vergeleken met WebRTC);
- het is erg handig en efficiƫnt om verschillende uitzendingen voor een groot publiek te organiseren, omdat segmenten ƩƩn keer op de CDN kunnen worden geladen.
Ondanks de eenvoud van de engine is niet alles zo soepel als het lijkt. Het grootste probleem is dat ontwikkelaars van externe spelers zich niet aan de aanbevelingen van Apple hebben gehouden, bijvoorbeeld wat betreft ondersteunde audioformaten. Veel ontwikkelaars hebben de mogelijkheid toegevoegd om met populaire audiostreams te werken: mpeg2 video, mpeg2 audio, enzovoorts. Dit resulteerde in het creƫren van verschillende playlistformaten voor verschillende spelers.
Maar een van de grootste problemen van de HLS-engine is de hoge vertraging bij gegevensoverdracht.
Oorzaken van vertragingen
De belangrijkste reden voor de hoge vertraging bij HLS ligt in het feit dat programmeurs de engine hebben ontwikkeld om de hoogste beeldkwaliteit te verkrijgen. Daarom zijn de parameters voor het gebruikte kaderinterval en de afspeelbuffer gewoon niet geschikt voor live videostreaming. Dit resulteert in een redelijk hoge vertraging bij de videotransmissie, die 5-7 seconden kan bedragen.
Aan de ene kant is dit niet veel, bijvoorbeeld voor degenen die een film bekijken vanaf een videohostingserver. Maar voor bewakingssystemen kan de vertraging bij videotransmissie van groot belang zijn.
Als je een kantoor in de gaten houdt, waar medewerkers ieder uur even van het scherm wegkijken, dan heeft een vertraging van 5 seconden geen betekenis. Maar mensen begonnen te klagen dat bijvoorbeeld tijdens de uitzending van een voetbalwedstrijd, in de chat al GOOOOL was geschreven, terwijl dat nog niet op de video te zien was :). We hebben al verschillende gebruiksgevallen waarin Ivideon praktisch Skype moet vervangen.
Is het mogelijk om de vertraging bij HLS te overwinnen? Het antwoord op deze vraag klinkt als een voordracht van een ervaren rattenbestrijdingsspecialist aan beginners in ongediertebestrijding: 'Ratten kunnen niet volledig worden uitgeroeid, maar hun populatie kan tot een redelijk minimum worden beperkt.' Zo is het ook met de vertraging bij HLS, het is niet mogelijk om deze tot nul te reduceren, maar er zijn oplossingen op de markt die de vertraging aanzienlijk kunnen verminderen.
Kleine segmenten
Een ander nadeel van de engine is het gebruik van kleine bestanden voor gegevensoverdracht. Het lijkt misschien niet slecht, maar is dat wel zo?
Iedereen die geprobeerd heeft een groot aantal kleine bestanden van de ene opslag naar de andere te kopiƫren, heeft ongetwijfeld gemerkt dat de schrijfsnelheid van een dergelijke set veel lager is dan die van ƩƩn groot bestand van dezelfde grootte. Ook de intensiteit van de toegang tot de harde schijf neemt aanzienlijk toe, wat in het algemeen een negatieve invloed heeft op de algehele prestaties van de computer. Daarom draagt de overdracht van videogegevens in de vorm van kleine fragmenten van 10 seconden ook bij aan de verhoogde vertraging van de engine.
Samenvattend, hier zijn alle voor- en nadelen van de HLS-technologie.
Voordelen van HLS:
- De mogelijkheid om op alle apparaten te werken. Je kunt video's bekijken op elk modern apparaat, of het nu een smartphone, tablet, laptop of desktop is. Het belangrijkste is dat de webbrowser een moderne versie heeft en compatibel is met HTML5 en Media Source Extensions.
- Uitstekende beeldkwaliteit. De gebruikte functie voor adaptieve bitrate-streaming maakt het mogelijk om de kwaliteit van de video dynamisch aan te passen op basis van de bandbreedte van de internetverbinding, waarbij het algoritme streeft naar het behoud van de maximale kwaliteit.
- Geen complexe configuratie van de gebruikersapparatuur vereist.
Nadelen:
- Beperkte ondersteuning voor de engine op sommige apparaten.
- Hoge vertraging bij de overdracht van het beeld.
- Sterke toename van overhead en complexiteit van optimalisatie door het gebruik van kleine bestanden. Vanwege de kenmerken van de container zullen we nooit een vertraging kunnen krijgen die lager is dan de grootte van het segment.
De nadelen van HLS wegen zwaarder voor ons dan de voordelen en hebben ons doen zoeken naar alternatieve opties.
Wat is WebRTC?
()
Het WebRTC-platform werd in 2011 door Google ontwikkeld voor de overdracht van streaming video- en audiogegevens tussen browsers en mobiele applicaties met minimale vertraging. Dit gebeurt met de standaard UDP-protocol en speciale algoritmen voor flowbeheer. Tegenwoordig is het een open-source project dat actief door Google wordt ondersteund en verder ontwikkeld.
WebRTC is a set of technologies for peer-to-peer transmission of video and audio. This means, for example, that users' browsers can transmit data directly to each other using WebRTC, without using remote servers to store and process data. All information is also processed by the browsers and mobile applications of end users.
The convenience and vast capabilities of this technology have been well appreciated by developers of all major browsers. Today, WebRTC support is implemented in Mozilla Firefox, Opera, Google Chrome (and all Chromium-based browsers), as well as in mobile applications for Android and iOS.
Despite its undeniable advantages, WebRTC has several significant drawbacks.
Difficulties in choice
The WebRTC technology is much more complex in terms of network interactions because it is based on P2P. It is difficult to debug, test, and it can behave unpredictably. At the same time, we need to overcome NAT and firewalls, and ensure operation in networks where UDP is blocked.
Using Googleās WebRTC implementation is quite challenging. There is even a whole company that provides SDK assembly services. Moreover, integrating Google's implementation with our system was very difficult without re-encoding all the video.
However, we have long wanted to give users the ability to work with a full 'live' video stream and minimize the delay of the image on the screen from the actual events. Additionally, we were eager to make the use of PTZ cameras more comfortable, where delays are of critical importance.
Considering that other implementations of lag mitigation currently have limited functionality and work noticeably worse, we decided to use WebRTC.
What we did
Correctly implementing the WebRTC platform is no easy task. Any mistake or inaccuracy can lead to delays in video transmission not only not decreasing compared to other platforms but even increasing.
For WebRTC to work correctly, it is first necessary to technologically modernize the stack for working with web video. And thatās exactly what we did.
We hebben eerst een WebRTC-signaleringsprotocol bovenop Websocket geĆÆmplementeerd, en ook een WebRTC-peer-server in de cloud opgezet op basis van de SDK van webrtc.org. Deze server is verantwoordelijk voor het distribueren van videostreams naar de client WebRTC peers in H.264 + Opus/G.711 formaat zonder videoherschaling.
We hebben Websocket gekozen als signaalprotocol omdat het al een goede ondersteuning heeft in alle populaire webbrowsers. Hierdoor kunnen we zowel de ontwikkelingskosten aanzienlijk verlagen als tijd en middelen besparen door geen herhaalde TCP- en TLS-handshakes uit te voeren in vergelijking met AJAX.
Het probleem is dat WebRTC standaard geen signaalprotocol biedt dat nodig is voor het correct opzetten, ondersteunen en verbreken van realtime videocommunicatie tussen de bron- en clientapplicaties.
Om zelf signaaltechnologie te implementeren, moesten we onze eigen signaalserver ontwikkelen die meerdere webprotocollen ondersteunt (Websocet, WebRTC). Ook met de mogelijkheid voor veilige sessiebeheer en meldingen in realtime, videobeheer en vele andere parameters.
We hebben de P2P-beperkingen overwonnen door de latentie niet via P2P te verlagen, maar via UDP en een flow management gericht op het verminderen van de latentie. Dit is ook vastgelegd in WebRTC, aangezien de belangrijkste use-case p2p gesprekken via de browser zijn.
In de mobiele client hebben we een speler geĆÆmplementeerd met behulp van de SDK van webrtc.org, omdat alleen hierin het stroombeheer correct is geĆÆmplementeerd, met alle bekende Forward Error Correction (FEC) schemaās, en het mechanisme voor het opnieuw verzenden van pakketten correct is geĆÆmplementeerd voor alle browsers. Niet te vergeten is dat de SDK van webrtc.org actief door Google wordt ontwikkeld.
Wat is het resultaat van de implementatie van WebRTC?
Voor het bekijken van live video van camera's hebben we een nieuwe geoptimaliseerde speler op basis van WebRTC toegevoegd aan het persoonlijk account. Deze speler zorgt voor een hoge laadsnelheid van videofeed en elimineert volledig het probleem van vertraging accumulatie naarmate de kijktijd toeneemt.
Na het implementeren van WebRTC-ondersteuning in de cloudservice Ivideon kunnen we met volle overtuiging zeggen dat onze klanten nu toegang hebben tot het bekijken van volwaardige live video. Momenteel bedraagt de vertraging bij de videostreaming niet meer dan Ć©Ć©n seconde! Ter vergelijking: de vorige HLS-engine zorgde voor een levering van video met een vertraging van 5-7 seconden. Het verschil in de snelheid van videoweergave is zeer significant, en de gebruiker zal het onmiddellijk opmerken zodra hij/zij met onze videoservice begint te werken.
Zoals we hadden verwacht, heeft de implementatie van de nieuwe speler de responsiviteit van de PTZ en spraakverbinding met de camera verbeterd.
Er is slechts Ć©Ć©n fijn punt waar we de aandacht op willen vestigen. De nieuwe WebRTC-speler werkt momenteel in de testmodus. Daarom verbinden we deze nog niet standaard voor al onze klanten. Maar u kunt deze zelf activeren door de bijbehorende optie in de camera-instellingen in te schakelen (hiervoor moet u inloggen in de ).
Kenmerken van de implementatie van WebRTC in de Ivideon-service
WebRTC is op dit moment nog een experimentele technologie. De ondersteuning ervan is nog niet correct geĆÆmplementeerd in alle browsers en gebruikersapparaten, en ook niet in alle camera's.
Dit verklaart waarom we de WebRTC-speler nog niet als de standaardinstelling voor alle gebruikers hebben gemaakt.
Momenteel raden we aan om WebRTC alleen te gebruiken in Google Chrome. De laatste versies van Firefox en Safari ondersteunen deze technologie ook, maar zijn helaas nog instabiel.
We hebben momenteel geen ondersteuning voor WebRTC geĆÆmplementeerd voor browsers op mobiele apparaten. Op dit moment, als u inlogt vanaf een mobiel apparaat en WebRTC inschakelt, zal deze modus niet werken. Echter, WebRTC is beschikbaar in onze mobiele applicaties voor en .
En tot slot, over de kenmerken van de implementatie van WebRTC in onze service, willen we nog twee fijne punten benadrukken.
Ten eerste is de technologie gericht op het uitzenden van live video in real-time. Dus als de bandbreedte van uw kanaal onvoldoende is om de video door te geven, zult u frames verliezen (met HLS zult u stilstand in video en toegenomen vertraging opmerken, maar er zullen geen frames verloren gaan), maar de video wordt nog steeds in real-time uitgezonden.
Ten tweede, omdat de technologie is ontworpen om met live videostreaming in realtime te werken, gebruiken we het niet voor het verwerken van archiefvideogegevens.
Andere wijzigingen in de service
Op dit moment is Flash niet langer betrokken bij het mechanisme voor automatische keuze van de engine. U kunt nog steeds zo'n speler gebruiken, maar u moet deze handmatig kiezen in de account- of camera-instellingen. Dit is geen trend, maar simpelweg omdat uit statistieken van onze service blijkt dat er bijna geen gebruikers meer zijn die met Flash werken. Bij het proberen te bepalen of de browser van de gebruiker dit ondersteunt, verliezen we ongeveer 2 seconden kostbare tijd.
Hier is een kort overzicht van de wijzigingen die u kunt verwachten in ons cloudvideobewakingssysteem en uw persoonlijke account. Blijf bij ons en volg het nieuws!
Bron: habr.com
