De la unuaj tagoj de laboro pri nuba videogvatsistemo, ni alfrontis problemon, sen solvo, al kiu ni povus rezigni pri Ivideon - tio estis nia Everesto, grimpado kiu bezonis multe da energio, sed nun ni finfine havas. enŝovis glacihakilon en la supron de la transplatforma enigmo.
La sistemo por transsendo de audio kaj video per Interreto ne devus dependi de ekipaĵo, Retaj klientoj kaj la normoj, kiujn ili subtenas, kaj ankaŭ funkcii ĝuste en ĉeesto de Retaj Adresaj Tradukiloj kaj fajroŝirmiloj. Uzanto de nuba videogvatado volas aliri la servon, eĉ se li uzas analogajn fotilojn, kaj preferas spekti vivan video-elsendon per la plej moderna aparato.
Estas tre signifa, ke la uzanto volas spekti filmetojn kun minimuma prokrasto. Preskaŭ la sola maniero por montri filmeton kun malalta latenco en retumilo estas uzi WebRTC (retaj realtempaj komunikadoj). WebRTC estas aro de teknologioj por kunula transdono de video kaj audio en retumiloj, komence dizajnitaj por dissendo kaj reproduktado de videofluoj kun malalta latenco. Tiucele interalie estas uzata la protokolo UDP.
Antaŭ ol ni diros al vi, kion la nova motoro donas al la uzanto, ni memorigos al vi kial kaj kial ni subtenas HLS-teknologiojn, kaj kial ni decidis pluiri.
HLS-motoro: avantaĝoj kaj malavantaĝoj
()
La teknologion HLS (HTTP Live Streaming) disvolvis Apple, do ne estas surprize, ke ĝi unue subteniĝis sur aparatoj de Apple. Hodiaŭ, HLS-video ankaŭ estas subtenata de preskaŭ ĉiuj televidomalĉifriloj kaj multaj aparatoj funkciigantaj la operaciumon. Android.
La HLS-motoro uzas la konatan videokodekon H264 en kombinaĵo kun AAC aŭ MP3 sonfluoj por flui videodatenojn. La tuta aŭda kaj video-datumfluo estas pakita en transportujon MPEG-TS. Por transdono per la HTTP-protokolo, la informoj enhavitaj en la fluo estas dividita en fragmentojn priskribitajn en m3u8-listoj. Kaj nur tiam ĉi tiuj fragmentoj, kune kun ludlistoj, estas transdonitaj per HTTP. Chunking aŭtomate signifas prokraston en sekundoj. Ĉi tio estas trajto de la MPEG-TS-ujo.
La HLS-motoro ankaŭ subtenas multibitrate fluojn, Live/VOD.
Ĉefaj avantaĝoj de HLS:
- enkonstruita subteno en ĉiuj ĉefaj retumiloj;
- facileco de efektivigo (kompare kun WebRTC);
- Estas tre oportune kaj efika organizi ĉiajn elsendojn al granda publiko pro la fakto, ke segmentoj povas esti alŝutitaj al CDN unufoje.
Malgraŭ la simpleco de la motoro, ne ĉio estas tiel glata kiel ĝi ŝajnas. La ĉefa problemo estas, ke programistoj de triaj ludantoj malproksimiĝis de la rekomendoj de Apple, ekzemple laŭ subtenataj aŭdformatoj. Aparte, multaj programistoj komencis aldoni la kapablon labori kun popularaj sonfluoj: mpeg2 video, mpeg2 audio, ktp. Kiel rezulto, ili devis krei malsamajn ludlistformatojn por malsamaj ludantoj.
Sed unu el la plej grandaj problemoj kun la HLS-motoro estas la alta latencia en transdono de datumoj.
La originoj de "bremsoj"
La ĉefa kialo de la alta latenteco de HLS kuŝas en la fakto, ke programistoj kreis la motoron por akiri la plej altkvalitajn bildojn. Tial, la parametroj de la kadra intervalo uzata kaj la grandeco de la reprodukta bufro simple ne taŭgas por vivaj videoelsendoj. Pro tio, estas sufiĉe alta prokrasto en la transdono de videofilmo, kiu povas esti 5-7 sekundoj.
Unuflanke, ĉi tio ne estas multe, ekzemple, por tiuj, kiuj spektas filmon de videogastigservilo. Sed por videogvatsistemoj, la prokrasto en elsendo de videofilmo povas esti tre grava.
Se vi rigardas oficejon, kie dungitoj rigardas supren de siaj ekranoj unufoje hore, tiam prokrasto de 5 sekundoj tute ne gravas. Sed homoj komencis plendi ke, ekzemple, kiam oni elsendis futbalan matĉon, oni jam skribis GOOOOL en la babilejo, sed ĉi tio ankoraŭ ne estas en la video :). Ni jam havas kelkajn uzantkazojn kie Ivideon praktike devus anstataŭigi Skajpon.
Ĉu eblas venki latentecon en HLS? La respondo al ĉi tiu demando sonas kiel la parolado de sperta ekstermisto de ratoj ĉe prelego al novulaj specialistoj pri fibesto: "Ratoj ne povas esti ekstermitaj, sed ilia nombro povas esti reduktita al racia minimumo." Same kun la malfruo en HLS, ne eblos redukti ĝin al nulo, sed ekzistas solvoj sur la merkato, kiuj povas signife redukti la malfruon.
Fajnaj tranĉoj
Alia malavantaĝo de la motoro estas la uzo de malgrandaj dosieroj por transdono de datumoj. Ŝajnus, ke kio estas malbona en ĉi tio?
Ĉiu, kiu provis kopii grandan nombron da malgrandaj dosieroj de unu medio al alia, verŝajne rimarkis, ke la skribrapideco de tia aro estas multe pli malalta ol unu granda dosiero de la sama grandeco. Kaj la intenseco de aliro al la malmola disko pliiĝas signife, kio ĝenerale negative influas la rendimenton de la tuta komputilo. Sekve, transdoni videodatenojn en malgrandaj 10 sekundaj pecoj ankaŭ kontribuas al pliigita motora latenteco.
Ni mallonge resumu ĉiujn avantaĝojn kaj malavantaĝojn de HLS-teknologio.
Avantaĝoj de HLS:
- Kapablo labori kun ajnaj aparatoj. Vi povas spekti filmetojn en iu ajn moderna aparato, ĉu ĝi estas inteligenta telefono, tablojdo, tekkomputilo aŭ labortabla komputilo. La ĉefa afero estas, ke la TTT-legilo estas ĝisdatigita kaj kongrua kun HTML5 kaj Media Source Extensions.
- Bonega bildkvalito. La adapta funkcio de transdono de datumoj uzataj ebligas al vi dinamike ŝanĝi la kvaliton de la elsendita video depende de la bendolarĝo de la interreta konekto, dum la algoritmo strebas konservi maksimuman kvaliton.
- Ne necesas kompleksa agordo de la ekipaĵo de la uzanto.
malavantaĝoj:
- Limigita subteno por labori kun la motoro sur iuj aparatoj.
- Altaj prokrastoj en transdono de bildoj.
- Signifa pliiĝo en superkosto kaj komplekseco de optimumigo pro la uzo de malgrandaj dosieroj. Pro la naturo de la ujo, ni neniam povos akiri latentecon pli malaltan ol la segmenta grandeco.
La malavantaĝoj de HLS superpezis ĝiajn avantaĝojn por ni kaj devigis nin serĉi alternativajn elektojn.
Kio estas WebRTC
()
La WebRTC-platformo estis evoluigita fare de Google en 2011 por elsendi fluantajn vidbendon kaj sondatenojn inter retumiloj kaj moveblaj aplikoj kun minimuma latenteco. Por tio, la norma UDP-protokolo kaj specialaj flukontrolalgoritmoj estas uzitaj. Hodiaŭ ĝi estas malfermkoda projekto, ĝi estas aktive prizorgata de Guglo kaj estas disvolvita.
WebRTC estas aro de teknologioj por samulo-al-kunula vidbendo kaj audio-transsendo. Tio estas, ekzemple, uzantretumiloj uzantaj WebRTC povas transdoni datumojn unu al la alia rekte, sen uzi forajn servilojn por stoki kaj prilabori datumojn. Ĉiuj informoj ankaŭ estas prilaboritaj per retumiloj kaj moveblaj aplikoj de finuzantoj.
La oportuno kaj ampleksaj kapabloj de ĉi tiu teknologio estas ŝatataj de programistoj de ĉiuj popularaj retumiloj. Subteno por WebRTC nuntempe haveblas en Mozilla Firefox, Opera, Google Chrome (kaj ĉiuj Chromium-bazitaj retumiloj), same kiel en poŝtelefonaj aplikaĵoj funkciantaj... Android kaj iOS.
Por ĉiuj ĝiaj nedubeblaj avantaĝoj, WebRTC havas plurajn signifajn malavantaĝojn.
Elektaj malfacilaĵoj
WebRTC-teknologio estas multe pli kompleksa laŭ retaj interagoj pro la fakto, ke temas pri P2P. Estas malfacile sencimigi, testi, kaj povas konduti neantaŭvideble. Samtempe, ni devas venki NAT kaj fajroŝirmilon, ni devas certigi funkciadon en retoj kie UDP estas blokita.
La efektivigo WebRTC de Google estas tre malfacile uzebla. Estas eĉ tuta kompanio, kiu provizas SDK-asembleservojn. Krome, la efektivigo de Google estis tre malfacile integrebla kun nia sistemo sen rekodi la tutan videon.
Tamen ni delonge volis doni al uzantoj la ŝancon labori kun plenrajta "viva" video kaj minimumigi la malfruon inter la bildo sur la ekrano kaj la eventoj mem. Plie, ni volis fari la uzon de PTZ-fotiloj, kie prokrastoj estas kritikaj, pli komfortaj.
Konsiderante ke aliaj kontraŭ-malfruaj efektivigoj ankoraŭ havas limigitan funkciecon kaj funkcias videble pli malbone, ni decidis uzi WebRTC.
Kion ni faris
Ĝuste efektivigi la WebRTC-platformon ne estas facila tasko. Ajna miskalkulo aŭ malprecizeco povas konduki al malfruoj en videotranssendo ne nur ne malpliiĝanta kompare kun aliaj platformoj, sed eĉ pliiĝi.
Por ke WebRTC funkciu ĝuste, unue necesas efektivigi teknologian ĝisdatigon de la stako por labori kun retvideo. Tion ni faris.
Unue, ni efektivigis WebRTC-signalan protokolservilon super Websocket, kaj ankaŭ deplojis WebRTC-servilon en la nubo bazitan sur la webrtc.org SDK. Ĝia tasko estas distribui videofluojn al kliento WebRTC-kunuloj en H.264 + Opus/G.711 formato sen video transkodado.
Ni elektis Websocket kiel la signalan protokolon ĉar ĝi jam havas altkvalitan subtenon en ĉiuj popularaj retumiloj. Pro tio, vi povas signife redukti ne nur disvolvan superkoston, sed ankaŭ eviti malŝpari tempon kaj rimedojn pri ripeta TCP kaj TLS-manpremo kompare kun AJAX.
La fakto estas, ke, defaŭlte, WebRTC ne disponigas la signalan protokolon necesan por konvene agordi, konservi kaj ĉesigi realtempan videokomunikadon inter la fonto kaj klientaplikoj.
Kaj por sendepende efektivigi signalteknologion, ni bezonis evoluigi nian propran signalservilon kun subteno por pluraj retprotokoloj (Websocet, WebRTC). Kaj kun la kapablo sekure administri sesiojn kaj sciigojn en reala tempo, videoadministrado kaj multe pli.
Ni venkis la limojn de P2P reduktante latencian ne per P2P, sed per UDP kaj fluo-kontrolo por redukti latencian. Ĉi tio ankaŭ estas konstruita en WebRTC, ĉar la ĉefa uzokazo estas p2p-konversacioj per retumilo.
En la poŝtelefona kliento, ni efektivigis la ludanton uzante la webrtc.org SDK, ĉar nur ĝi ĝuste efektivigas fluoregadon, havas ĉiujn konatajn skemojn de Forward Error Correction (FEC) kaj ĝuste efektivigas la mekanismon por resendi pakojn por ĉiuj retumiloj. Ankaŭ gravas, ke la webrtc.org SDK estas aktive disvolvita de Guglo.
Kio estas la rezulto de efektivigo de WebRTC?
Por vidi vivan videon de fotiloj, ni aldonis novan optimumigitan ludilon bazitan sur WebRTC al via persona konto. Ĝi provizas rapidajn ŝarĝajn rapidojn de video kaj tute forigas la problemon de latencia amasiĝo dum spektadtempo pliiĝas.
Post enkonduko de WebRTC-subteno en la nuba servo Ivideon, ni povas diri kun plena fido, ke niaj klientoj nun povas spekti plenkreskan vivan videon. Nun la prokrasto dum elsendado de videosekvencoj ne superas unu sekundon! Por komparo, la antaŭa HLS-motoro provizis videoliveron kun prokrasto de 5-7 sekundoj. La diferenco en videa pruva rapideco estas tre signifa, kaj la uzanto rimarkos ĝin tuj post komenci labori kun nia videoservo.
Kiel ni atendis, la efektivigo de la nova ludanto plibonigis la respondecon de PTZ kaj voĉan komunikadon kun la fotilo.
Estas nur unu subtila punkto, pri kiu ni volas atentigi. La nova WebRTC-ludanto nuntempe funkcias en prova reĝimo. Kaj tial ni ne ebligas ĝin por ĉiuj niaj klientoj defaŭlte. Sed vi povas aktivigi ĝin mem ebligante la respondan eron en la fotilaj agordoj (por fari tion vi devas iri al ).
Trajtoj de la efektivigo de WebRTC en la Ivideon-servo
WebRTC estas ankoraŭ eksperimenta teknologio nuntempe. Ĝia subteno ankoraŭ ne estas ĝuste efektivigita en ĉiuj retumiloj kaj uzantaj aparatoj, kaj ankaŭ ne en ĉiuj fotiloj.
Ĝuste tial ni ankoraŭ ne faris la WebRTC-ludilon la defaŭlta por ĉiuj uzantoj.
Nuntempe, ni rekomendas uzi WebRTC nur en retumiloj de Google Chrome. La plej novaj versioj de Firefox kaj Safari ankaŭ subtenas ĉi tiun teknologion, sed, bedaŭrinde, ĝi ankoraŭ estas malstabila.
Ni ankoraŭ ne efektivigis WebRTC-subtenon por retumiloj sur porteblaj aparatoj. Nuntempe, se vi ensalutas de poŝtelefono kaj aktivigas WebRTC, ĉi tiu reĝimo ne funkcios. Tamen, WebRTC estas disponebla en niaj moveblaj aplikoj por и .
Kaj konkludante la rakonton pri la funkcioj de la efektivigo WebRTC en nia servo, ni notu du pliajn subtilajn punktojn.
Unue, la teknologio koncentriĝas pri elsendado de viva video en reala tempo. Sekve, se via kanalo ne havas sufiĉe da bendolarĝo por transdoni la videon, vi rimarkos kadrajn falojn (kun HLS vi rimarkos video-malfortiĝon kaj pliigitan latentecon, sed ne estos framfaloj), sed la video ankoraŭ estos elsendita reale. tempo.
Due, ĉar la teknologio estas dizajnita por funkcii specife kun viva video en reala tempo, ni ne uzas ĝin por labori kun arkivitaj videodatenoj.
Aliaj ŝanĝoj al la servo
Nuntempe, Flash ne plu estas implikita en la aŭtomata elekta mekanismo de motoro. Vi ankoraŭ povas uzi tian ludanton, sed por fari tion vi devas elekti ĝin permane en la konto aŭ fotila agordo. Ĉi tio ne estas omaĝo al modo, nur ke laŭ la statistiko de nia servo, preskaŭ ne restas uzantoj laborantaj kun Flash. Kaj provante determini ĉu la retumilo de la uzanto subtenas ĝin, ni perdas ĉirkaŭ 2 sekundojn da altvalora tempo.
Jen mallonga superrigardo de la ŝanĝoj, kiuj atendas vin en nia nuba videogvatsistemo kaj persona konto. Restu kun ni kaj sekvu la novaĵojn!
fonto: www.habr.com
