Vanaf de eerste dagen dat we aan een videobewakingssysteem in de cloud werkten, werden we geconfronteerd met een probleem, zonder oplossing waarvoor we Ivideon konden opgeven - dit was onze Everest, klimmen dat veel energie kostte, maar nu hebben we eindelijk stak een ijsbijl in de bovenkant van de platformonafhankelijke puzzel.
Het systeem voor het verzenden van audio en video via internet mag niet afhankelijk zijn van apparatuur, webclients en de standaarden die zij ondersteunen, en moet ook correct werken in de aanwezigheid van Network Address Translators en firewalls. Een gebruiker van cloudvideobewaking wil toegang tot de dienst, zelfs als hij analoge camera's gebruikt, en kijkt het liefst naar live video-uitzendingen op het modernste apparaat.
Het is van groot belang dat de gebruiker video's met minimale vertraging wil bekijken. Bijna de enige manier om video met lage latentie in een browser weer te geven, is door gebruik te maken van WebRTC (web real-time communications). WebRTC is een reeks technologieën voor peer-to-peer-overdracht van video en audio in browsers, aanvankelijk ontworpen voor de verzending en weergave van videostreams met lage latentie. Hiervoor wordt onder meer het UDP-protocol gebruikt.
Voordat we u vertellen wat de nieuwe engine de gebruiker biedt, zullen we u eraan herinneren waarom en waarom we HLS-technologieën ondersteunen, en waarom we besloten verder te gaan.
HLS-motor: voor- en nadelen
()
HLS (HTTP Live Streaming)-technologie is ontwikkeld door Apple, dus het is geen verrassing dat het in eerste instantie door Apple-apparaten werd ondersteund. Tegenwoordig wordt HLS-video ook ondersteund door vrijwel alle settopboxen en veel apparaten die op het besturingssysteem draaien. Android.
De HLS-engine maakt gebruik van de bekende H264-videocodec in combinatie met AAC- of MP3-audiostreams om videogegevens te streamen. De volledige audio- en videodatastroom wordt verpakt in een MPEG-TS-transportcontainer. Voor verzending via het HTTP-protocol wordt de informatie in de stream opgedeeld in fragmenten die worden beschreven in m3u8-afspeellijsten. En alleen dan worden deze fragmenten, samen met afspeellijsten, via HTTP verzonden. Chunking betekent automatisch een vertraging in seconden. Dit is een kenmerk van de MPEG-TS-container.
De HLS-engine ondersteunt ook multibitrate-streams, Live/VOD.
Belangrijkste voordelen van HLS:
- ingebouwde ondersteuning in alle grote browsers;
- implementatiegemak (vergeleken met WebRTC);
- Het is erg handig en efficiënt om allerlei uitzendingen voor een groot publiek te organiseren, omdat segmenten één keer naar een CDN kunnen worden geüpload.
Ondanks de eenvoud van de motor verloopt niet alles zo soepel als het lijkt. Het grootste probleem is dat externe spelersontwikkelaars afstand hebben genomen van de aanbevelingen van Apple, bijvoorbeeld op het gebied van ondersteunde audioformaten. In het bijzonder begonnen veel ontwikkelaars de mogelijkheid toe te voegen om met populaire audiostreams te werken: mpeg2-video, mpeg2-audio, enz. Als gevolg hiervan moesten ze verschillende afspeellijstformaten maken voor verschillende spelers.
Maar een van de grootste problemen met de HLS-engine is de hoge latentie bij de gegevensoverdracht.
De oorsprong van “remmen”
De belangrijkste reden voor de hoge latentie van HLS ligt in het feit dat programmeurs de engine hebben gemaakt om beelden van de hoogste kwaliteit te verkrijgen. Daarom zijn de parameters van het gebruikte frame-interval en de grootte van de afspeelbuffer eenvoudigweg niet geschikt voor live video-uitzendingen. Hierdoor is er een vrij grote vertraging bij de overdracht van videobeelden, die 5-7 seconden kan bedragen.
Aan de ene kant is dit bijvoorbeeld niet veel voor degenen die een film kijken vanaf een videohostingserver. Maar voor videobewakingssystemen kan de vertraging bij het verzenden van videobeelden erg belangrijk zijn.
Kijk je naar een kantoor waar medewerkers één keer per uur opkijken van hun monitor, dan maakt een vertraging van 5 seconden helemaal niets uit. Maar mensen begonnen te klagen dat ze bijvoorbeeld bij het uitzenden van een voetbalwedstrijd al GOOOOL in de chat schreven, maar dit staat nog niet op de video :). We hebben al een aantal gebruikerscasussen waarin Ivideon Skype praktisch zou moeten vervangen.
Is het mogelijk om de latentie in HLS te verslaan? Het antwoord op deze vraag klinkt als de toespraak van een ervaren rattenverdelger tijdens een lezing voor beginnende ongediertebestrijdingsspecialisten: “Ratten kunnen niet worden uitgeroeid, maar hun aantal kan wel tot een redelijk minimum worden teruggebracht.” Hetzelfde geldt voor de vertraging bij HLS: het zal niet mogelijk zijn om deze tot nul terug te brengen, maar er zijn oplossingen op de markt die de vertraging aanzienlijk kunnen verminderen.
Fijne snitten
Een ander nadeel van de engine is het gebruik van kleine bestanden voor gegevensoverdracht. Het lijkt erop dat wat hier mis mee is?
Iedereen die heeft geprobeerd een groot aantal kleine bestanden van het ene medium naar het andere te kopiëren, heeft waarschijnlijk gemerkt dat de schrijfsnelheid van zo'n set veel lager is dan die van één groot bestand van dezelfde grootte. En de intensiteit van de toegang tot de harde schijf neemt aanzienlijk toe, wat over het algemeen de prestaties van de hele computer negatief beïnvloedt. Daarom draagt het verzenden van videogegevens in kleine stukjes van 10 seconden ook bij aan een grotere latentie van de engine.
Laten we alle voor- en nadelen van HLS-technologie kort samenvatten.
Voordelen van HLS:
- Mogelijkheid om met elk apparaat te werken. Je kunt video's bekijken op elk modern apparaat, of het nu een smartphone, tablet, laptop of desktop-pc is. Het belangrijkste is dat de webbrowser up-to-date is en compatibel is met HTML5 en Media Source Extensions.
- Uitstekende beeldkwaliteit. Met de gebruikte adaptieve gegevensoverdrachtfunctie kunt u de kwaliteit van de verzonden video dynamisch wijzigen, afhankelijk van de bandbreedte van de internetverbinding, terwijl het algoritme ernaar streeft de maximale kwaliteit te behouden.
- Er is geen noodzaak voor een complexe configuratie van de apparatuur van de gebruiker.
Nadelen:
- Beperkte ondersteuning voor het werken met de engine op sommige apparaten.
- Hoge vertragingen bij beeldoverdracht.
- Aanzienlijke toename van de overhead en complexiteit van de optimalisatie door het gebruik van kleine bestanden. Vanwege de aard van de container zullen we nooit een latentie kunnen krijgen die lager is dan de segmentgrootte.
De nadelen van HLS wogen voor ons zwaarder dan de voordelen ervan en dwongen ons op zoek te gaan naar alternatieve mogelijkheden.
Wat is WebRTC
()
Het WebRTC-platform is in 2011 door Google ontwikkeld om streaming video- en audiogegevens met minimale latentie tussen browsers en mobiele applicaties te verzenden. Hiervoor wordt gebruik gemaakt van het standaard UDP-protocol en speciale flow control-algoritmen. Tegenwoordig is het een open source-project, het wordt actief onderhouden door Google en wordt ontwikkeld.
WebRTC is een reeks technologieën voor peer-to-peer video- en audiotransmissie. Dat wil zeggen dat gebruikersbrowsers die WebRTC gebruiken, bijvoorbeeld rechtstreeks gegevens naar elkaar kunnen overbrengen, zonder gebruik te maken van externe servers voor het opslaan en verwerken van gegevens. Alle informatie wordt ook verwerkt door de browsers en mobiele applicaties van eindgebruikers.
Het gemak en de uitgebreide mogelijkheden van deze technologie worden gewaardeerd door ontwikkelaars van alle populaire browsers. WebRTC-ondersteuning is momenteel beschikbaar in Mozilla Firefox, Opera, Google Chrome (en alle op Chromium gebaseerde browsers), evenals in mobiele apps die draaien op Android en iOS.
Ondanks al zijn onbetwiste voordelen heeft WebRTC verschillende belangrijke nadelen.
Moeilijkheden bij het kiezen
WebRTC-technologie is veel complexer in termen van netwerkinteracties vanwege het feit dat het om P2P gaat. Het is moeilijk te debuggen, te testen en kan zich onvoorspelbaar gedragen. Tegelijkertijd moeten we NAT en firewall overwinnen, we moeten de werking garanderen in netwerken waar UDP wordt geblokkeerd.
De WebRTC-implementatie van Google is erg moeilijk te gebruiken. Er is zelfs een heel bedrijf dat SDK-assemblagediensten levert. Bovendien was de implementatie van Google erg moeilijk te integreren met ons systeem zonder de hele video opnieuw te coderen.
We willen gebruikers echter al lang de mogelijkheid geven om met volwaardige “live” video te werken en de vertraging tussen het beeld op het scherm en de gebeurtenissen zelf te minimaliseren. Bovendien wilden we het gebruik van PTZ-camera's comfortabeler maken, waar vertragingen van cruciaal belang zijn.
Gezien het feit dat andere anti-lag-implementaties nog steeds beperkte functionaliteit hebben en merkbaar slechter werken, hebben we besloten om WebRTC te gebruiken.
Wat hebben we gedaan
Het correct implementeren van het WebRTC-platform is geen gemakkelijke taak. Elke misrekening of onnauwkeurigheid kan ertoe leiden dat vertragingen in de videotransmissie niet alleen niet afnemen in vergelijking met andere platforms, maar zelfs toenemen.
Om WebRTC correct te laten werken, is het allereerst noodzakelijk om een technologische upgrade van de stapel uit te voeren voor het werken met webvideo. Dat is wat wij deden.
Eerst hebben we een WebRTC-signaleringsprotocolserver via Websocket geïmplementeerd en ook een WebRTC-peerserver in de cloud geïmplementeerd op basis van de webrtc.org SDK. Zijn taak is het distribueren van videostreams naar WebRTC-clients in H.264 + Opus/G.711-formaat zonder videotranscodering.
We kozen voor Websocket als signaalprotocol omdat het al hoogwaardige ondersteuning biedt in alle populaire webbrowsers. Hierdoor kunt u niet alleen de ontwikkelingsoverhead aanzienlijk verminderen, maar ook voorkomen dat u tijd en middelen verspilt aan herhaalde TCP- en TLS-handshakes in vergelijking met AJAX.
Feit is dat WebRTC standaard niet het signaleringsprotocol biedt dat nodig is om real-time videocommunicatie tussen de bron- en clientapplicaties correct te configureren, onderhouden en beëindigen.
En om de signaleringstechnologie zelfstandig te kunnen implementeren, moesten we onze eigen signaleringsserver ontwikkelen met ondersteuning voor verschillende webprotocollen (Websocet, WebRTC). En met de mogelijkheid om sessies en meldingen veilig in realtime te beheren, videobeheer en nog veel meer.
We hebben de beperkingen van P2P overwonnen door de latentie niet via P2P te verminderen, maar via UDP en flow control om de latentie te verminderen. Dit is ook ingebouwd in WebRTC, aangezien de belangrijkste use-case p2p-gesprekken via een browser zijn.
In de mobiele client hebben we de speler geïmplementeerd met behulp van de webrtc.org SDK, omdat alleen deze de stroomcontrole correct implementeert, over alle bekende FEC-schema's (Forward Error Correction) beschikt en het mechanisme voor het opnieuw verzenden van pakketten voor alle browsers correct implementeert. Het is ook belangrijk dat de webrtc.org SDK actief wordt ontwikkeld door Google.
Wat is het resultaat van de implementatie van WebRTC?
Om live video van camera's te bekijken, hebben we een nieuwe geoptimaliseerde speler op basis van WebRTC aan uw persoonlijke account toegevoegd. Het biedt snelle laadsnelheden voor video's en elimineert volledig het probleem van de ophoping van latentie naarmate de kijktijd toeneemt.
Na de introductie van WebRTC-ondersteuning in de Ivideon-cloudservice kunnen we met het volste vertrouwen zeggen dat onze klanten nu volwaardige livevideo kunnen bekijken. Nu bedraagt de vertraging bij het uitzenden van videosequenties niet meer dan één seconde! Ter vergelijking: de vorige HLS-engine zorgde voor videoweergave met een vertraging van 5-7 seconden. Het verschil in de snelheid van de videodemonstratie is zeer groot en de gebruiker zal het onmiddellijk merken nadat hij met onze videodienst gaat werken.
Zoals we hadden verwacht, heeft de implementatie van de nieuwe speler de responsiviteit van PTZ en spraakcommunicatie met de camera verbeterd.
Er is slechts één subtiel punt waarop we de aandacht willen vestigen. De nieuwe WebRTC-speler werkt momenteel in testmodus. En daarom schakelen we het niet standaard in voor al onze klanten. Maar je kunt het zelf activeren door het overeenkomstige item in de camera-instellingen in te schakelen (hiervoor moet je naar gaan ).
Kenmerken van de implementatie van WebRTC in de Ivideon-service
WebRTC is momenteel nog een experimentele technologie. De ondersteuning is nog niet correct geïmplementeerd in alle browsers en gebruikersapparaten, en ook niet in alle camera's.
Dit is precies de reden waarom we de WebRTC-speler nog niet tot standaard voor alle gebruikers hebben gemaakt.
Voorlopig raden we aan om WebRTC alleen in de Google Chrome-browsers te gebruiken. De nieuwste versies van Firefox en Safari ondersteunen deze technologie ook, maar is helaas nog steeds instabiel.
We hebben nog geen WebRTC-ondersteuning voor browsers op mobiele apparaten geïmplementeerd. Als u zich momenteel aanmeldt vanaf een mobiel apparaat en WebRTC activeert, werkt deze modus niet. WebRTC is echter beschikbaar in onze mobiele applicaties voor и .
En ter afsluiting van het verhaal over de kenmerken van de WebRTC-implementatie in onze service, laten we nog twee subtiele punten opmerken.
Ten eerste is de technologie gericht op het in realtime uitzenden van live video. Als uw kanaal dus niet genoeg bandbreedte heeft om de video te verzenden, zult u framedrops opmerken (met HLS zult u videofading en verhoogde latentie opmerken, maar er zullen geen framedrops zijn), maar de video zal nog steeds in het echt worden uitgezonden. tijd.
Ten tweede gebruiken we de technologie niet om met gearchiveerde videogegevens te werken, omdat deze specifiek is ontworpen om in realtime met live video te werken.
Andere wijzigingen in de service
Op dit moment is Flash niet langer betrokken bij het automatische motorselectiemechanisme. Je kunt zo’n speler nog steeds gebruiken, maar hiervoor moet je hem handmatig selecteren in de account- of camera-instellingen. Dit is geen eerbetoon aan mode, maar volgens de statistieken van onze service zijn er vrijwel geen gebruikers meer die met Flash werken. En als we proberen vast te stellen of de browser van de gebruiker dit ondersteunt, verliezen we ongeveer 2 seconden kostbare tijd.
Hier is een kort overzicht van de veranderingen die u te wachten staan in ons cloudvideobewakingssysteem en persoonlijke account. Blijf bij ons en volg het nieuws!
Bron: www.habr.com
