O'r dyddiau cyntaf o weithio ar system gwyliadwriaeth fideo cwmwl, roeddem yn wynebu problem, heb ei datrys y bu'n bosibl rhoi diwedd ar Ivideon - ein Everest ni, dringo a gymerodd lawer o gryfder, ond nawr rydym wedi glynu o'r diwedd. bwyell iâ i mewn i ben y rebus traws-lwyfan.
Ni ddylai'r system ar gyfer trosglwyddo sain a fideo dros y Rhyngrwyd ddibynnu ar yr offer, cleientiaid y We a'r safonau y maent yn eu cefnogi, a hefyd weithio'n gywir ym mhresenoldeb Cyfieithwyr Cyfeiriadau Rhwydwaith a waliau tân. Mae defnyddiwr gwyliadwriaeth fideo cwmwl eisiau cyrchu'r gwasanaeth, hyd yn oed os yw'n defnyddio camerâu analog, ac mae'n well ganddo wylio darllediad fideo byw ar y ddyfais fwyaf modern.
Mae'n arwyddocaol iawn bod y defnyddiwr eisiau gwylio'r fideo heb fawr o oedi. Yr unig ffordd fwy neu lai i ddangos fideo hwyrni isel mewn porwr yw defnyddio WebRTC (cyfathrebiadau amser real ar y we). Mae WebRTC yn set o dechnolegau ar gyfer trosglwyddo fideo a sain rhwng cymheiriaid mewn porwyr, a ddyluniwyd yn wreiddiol ar gyfer trosglwyddo a chwarae ffrwd fideo â hwyrni isel. Ar gyfer hyn, ymhlith pethau eraill, defnyddir protocol y CDU.
Cyn dweud wrthych beth mae'r injan newydd yn ei roi i'r defnyddiwr, byddwn yn eich atgoffa pam a pham rydym yn cefnogi technolegau HLS, a pham y gwnaethom benderfynu symud ymlaen.
Peiriant HLS: manteision ac anfanteision
()
Datblygwyd technoleg HLS (Ffrydio Byw HTTP) gan Apple, felly nid yw'n syndod iddi gael ei chefnogi gyntaf ar ddyfeisiau Apple. Heddiw, mae fideo HLS hefyd yn cael ei gefnogi gan bron pob blwch pen set a llawer o ddyfeisiau sy'n rhedeg y system weithredu. Android.
Mae'r injan HLS yn defnyddio'r codec fideo H264 adnabyddus mewn cyfuniad â ffrydiau sain AAC neu MP3 i ffrydio data fideo. Mae'r llif cyfan o ddata sain a fideo wedi'i bacio i mewn i gynhwysydd trafnidiaeth MPEG-TS. Ar gyfer trosglwyddo dros y protocol HTTP, mae'r wybodaeth a gynhwysir yn y ffrwd wedi'i rhannu'n ddarnau a ddisgrifir yn rhestri chwarae m3u8. A dim ond wedyn mae'r darnau hyn, ynghyd â rhestri chwarae, yn cael eu trosglwyddo trwy HTTP. Mae rhannu'n ddarnau yn awtomatig yn golygu oedi mewn eiliadau. Nodwedd o'r fath o'r cynhwysydd MPEG-TS.
Mae'r injan HLS hefyd yn cefnogi ffrydiau amlbitrad, Live/VOD.
Prif fanteision HLS:
- cefnogaeth adeiledig ym mhob un o'r prif borwyr;
- rhwyddineb gweithredu (o'i gymharu â WebRTC);
- Mae'n gyfleus ac effeithlon iawn i drefnu pob math o ddarllediadau ar gyfer cynulleidfa fawr oherwydd y ffaith y gellir llwytho segmentau i CDN unwaith.
Er gwaethaf symlrwydd yr injan, nid yw popeth mor llyfn ag y mae'n ymddangos. Y brif broblem yw bod datblygwyr chwaraewyr trydydd parti wedi gwyro oddi wrth argymhellion Apple, er enghraifft, o ran fformatau sain â chymorth. Yn benodol, dechreuodd llawer o ddatblygwyr ychwanegu'r gallu i weithio gyda ffrydiau sain poblogaidd: fideo mpeg2, sain mpeg2, ac ati O ganlyniad, bu'n rhaid i ni greu gwahanol fformatau rhestr chwarae ar gyfer gwahanol chwaraewyr.
Ond un o'r problemau mwyaf gyda'r injan HLS yw'r hwyrni uchel wrth drosglwyddo data.
Tarddiad y "breciau"
Y prif reswm dros hwyrni uchel HLS yw'r ffaith bod y rhaglenwyr wedi creu'r injan i gael y llun o'r ansawdd uchaf. Felly, nid yw paramedrau'r cyfwng ffrâm a ddefnyddir a maint y byffer chwarae yn addas ar gyfer darllediadau fideo byw. Oherwydd hyn, mae oedi eithaf uchel wrth drosglwyddo'r dilyniant fideo, a all fod yn 5-7 eiliad.
Ar y naill law, nid yw hyn yn llawer, er enghraifft, i'r rhai sy'n gwylio ffilm o weinydd cynnal fideo. Ond ar gyfer systemau gwyliadwriaeth fideo, gall yr oedi wrth drosglwyddo'r dilyniant fideo fod yn bwysig iawn.
Os ydych chi'n gwylio swyddfa lle mae gweithwyr yn tynnu eu llygaid oddi ar y monitorau unwaith yr awr, yna nid yw oedi o 5 eiliad o bwys. Ond dechreuodd pobl gwyno, er enghraifft, yn ystod darllediad gêm bêl-droed, eu bod eisoes wedi ysgrifennu GOOOOL yn y sgwrs, ond nid yw hyn ar y fideo eto :). Mae gennym eisoes nifer o achosion defnyddwyr lle dylai Ivideon gymryd lle skype yn ymarferol.
A yw'n bosibl curo hwyrni yn HLS? Mae’r ateb i’r cwestiwn hwn yn swnio fel araith gan ddifodwr llygod mawr profiadol mewn darlith i ddifodwyr newydd: “Ni ellir difodi llygod mawr, ond gellir lleihau eu poblogaeth i isafswm rhesymol.” Felly gyda'r oedi yn HLS, ni fydd yn gweithio i'w dynnu i sero, ond mae yna atebion ar y farchnad a all leihau'r oedi yn sylweddol.
torri dirwy
Anfantais arall yr injan yw'r defnydd o ffeiliau bach ar gyfer trosglwyddo data. Mae'n ymddangos bod hyn yn ddrwg?
Rhaid i unrhyw un sydd wedi ceisio copïo nifer fawr o ffeiliau bach o un cyfrwng i'r llall fod wedi sylwi bod cyflymder ysgrifennu set o'r fath yn llawer is nag un ffeil fawr o'r un maint. Ydy, ac mae dwyster mynediad i'r ddisg galed yn cynyddu'n sylweddol, sydd yn gyffredinol yn effeithio'n negyddol ar berfformiad y cyfrifiadur cyfan. Felly, mae trosglwyddo data fideo ar ffurf darnau bach 10 eiliad hefyd yn cyfrannu at oedi cynyddol yr injan.
Gadewch i ni grynhoi'n fyr holl fanteision ac anfanteision technoleg HLS.
Manteision HLS:
- Y gallu i weithio gydag unrhyw ddyfais. Gallwch wylio fideos ar unrhyw ddyfais fodern, boed yn ffôn clyfar, llechen, gliniadur neu gyfrifiadur pen desg. Y prif beth yw bod y porwr gwe yn gyfredol ac yn gydnaws â HTML5 ac Estyniadau Ffynhonnell Cyfryngau.
- Ansawdd delwedd rhagorol. Mae'r swyddogaeth trosglwyddo data addasol a ddefnyddir yn caniatáu ichi newid ansawdd y dilyniant fideo a drosglwyddir yn ddeinamig yn dibynnu ar led band y cysylltiad Rhyngrwyd, tra bod yr algorithm yn ymdrechu i gadw'r ansawdd mor uchel â phosibl.
- Nid oes angen gosod offer defnyddiwr cymhleth.
Anfanteision:
- Cefnogaeth gyfyngedig ar gyfer gweithio gyda'r injan ar rai dyfeisiau.
- Cudd uchel wrth drosglwyddo delwedd.
- Cynnydd cryf mewn gorbenion a chymhlethdod optimeiddio oherwydd y defnydd o ffeiliau bach. Oherwydd natur y cynhwysydd, ni allwn byth gael oedi llai na maint y segment.
Roedd anfanteision HLS yn drech na'i fanteision i ni ac yn ein gorfodi i chwilio am ddewisiadau eraill.
Beth yw WebRTC
()
Datblygwyd platfform WebRTC gan Google yn 2011 i drosglwyddo data ffrydio fideo a sain rhwng porwyr a chymwysiadau symudol heb fawr o oedi. Ar gyfer hyn, defnyddir y protocol CDU safonol ac algorithmau rheoli llif arbennig. Heddiw mae'n brosiect ffynhonnell agored, a gefnogir yn weithredol gan Google a'i ddatblygu.
Mae WebRTC yn set o dechnolegau ar gyfer trosglwyddo fideo a sain rhwng cymheiriaid. Hynny yw, er enghraifft, gall porwyr defnyddwyr sy'n defnyddio WebRTC drosglwyddo data yn uniongyrchol i'w gilydd, heb ddefnyddio gweinyddwyr o bell ar gyfer storio a phrosesu data. Mae'r holl wybodaeth hefyd yn cael ei phrosesu gan borwyr defnyddwyr terfynol a chymwysiadau symudol.
Mae cyfleustra a galluoedd helaeth y dechnoleg hon wedi cael eu gwerthfawrogi gan ddatblygwyr pob porwr poblogaidd. Mae cefnogaeth WebRTC ar gael ar hyn o bryd yn Mozilla Firefox, Opera, Google Chrome (a phob porwr sy'n seiliedig ar Chromium), yn ogystal ag mewn apiau symudol sy'n rhedeg Android ac iOS.
Gyda'i holl fanteision diymwad, mae gan WebRTC nifer o anfanteision sylweddol.
Anawsterau dewis
Mae technoleg WebRTC yn llawer mwy cymhleth o ran rhyngweithiadau rhwydwaith oherwydd ei fod yn ymwneud â P2P. Mae'n anodd dadfygio, profi, gall ymddwyn yn anrhagweladwy. Ar yr un pryd, mae angen i ni oresgyn NAT a wal dân, mae angen inni sicrhau gwaith mewn rhwydweithiau lle mae CDU wedi'i rwystro.
Mae gweithrediad WebRTC Google yn anodd iawn i'w ddefnyddio. Mae hyd yn oed cwmni cyfan sy'n darparu gwasanaethau adeiladu SDK. Hefyd, roedd gweithrediad Google yn anodd iawn ei integreiddio â'n system heb ail-amgodio'r fideo cyfan.
Fodd bynnag, rydym wedi bod eisiau rhoi'r cyfle ers tro i ddefnyddwyr weithio gyda dilyniant fideo "byw" llawn a lleihau oedi'r ddelwedd ar y sgrin o'r digwyddiadau eu hunain. Hefyd, roedd gennym awydd i wneud y defnydd o gamerâu PTZ yn fwy cyfforddus, lle mae oedi yn hollbwysig.
O ystyried bod gan weithrediadau gwrth-oedi eraill ymarferoldeb cyfyngedig o hyd a'u bod yn gweithio'n sylweddol waeth, penderfynasom ddefnyddio WebRTC.
Beth ydyn ni wedi'i wneud
Nid yw gweithredu platfform WebRTC yn gywir yn dasg hawdd. Gall unrhyw gamgyfrifiad neu anghywirdeb arwain at y ffaith na fydd yr oedi wrth drosglwyddo'r dilyniant fideo nid yn unig yn lleihau o gymharu â llwyfannau eraill, ond bydd hyd yn oed yn cynyddu.
Er mwyn i WebRTC weithio'n gywir, yn gyntaf oll, mae angen uwchraddio'r pentwr yn dechnolegol ar gyfer gweithio gyda fideo gwe. Sef a wnaethom.
Yn gyntaf, fe wnaethom weithredu gweinydd protocol signalau WebRTC dros Websocket, a hefyd defnyddio gweinydd cymheiriaid WebRTC yn y cwmwl yn seiliedig ar y webrtc.org SDK. Ei dasg yw dosbarthu ffrydiau fideo i gyfoedion WebRTC cleient mewn fformat H.264 + Opus/G.711 heb drawsgodio fideo.
Fe wnaethom ddewis Websocket fel y protocol signalau oherwydd bod ganddo gefnogaeth dda eisoes ym mhob porwr gwe poblogaidd. Oherwydd hyn, gallwch leihau'n sylweddol nid yn unig gorbenion datblygu, ond hefyd peidio â gwastraffu amser ac adnoddau ar ysgwyd llaw TCP a TLS dro ar ôl tro o'i gymharu ag AJAX.
Y pwynt yw nad yw WebRTC, yn ddiofyn, yn darparu'r protocol signalau sydd ei angen i sefydlu, cynnal a therfynu cyfathrebiadau fideo amser real rhwng cymwysiadau ffynhonnell a chleient yn iawn.
Ac er mwyn gweithredu'r dechnoleg signalau yn annibynnol, roedd angen i ni ddatblygu ein gweinydd signalau ein hunain gyda chefnogaeth ar gyfer sawl protocol gwe (Websocet, WebRTC). A chyda'r gallu i reoli sesiynau a hysbysiadau amser real yn ddiogel, rheoli fideo, a mwy.
Fe wnaethom oresgyn cyfyngiadau P2P trwy leihau hwyrni nid trwy P2P, ond trwy CDU a rheolaeth llif i leihau hwyrni. Mae hyn hefyd wedi'i ymgorffori yn WebRTC, gan mai'r prif achos defnydd yw sgyrsiau p2p trwy'r porwr.
Yn y cleient symudol, fe wnaethom weithredu'r chwaraewr gan ddefnyddio'r webrtc.org SDK, gan mai dyma'r unig un sy'n gweithredu rheolaeth llif yn gywir, mae ganddo bob cynllun Cywiro Gwall Ymlaen (FEC) hysbys, ac yn gweithredu'r mecanwaith ar gyfer ail-anfon pecynnau ar gyfer pob porwr yn gywir. . Mae hefyd yn bwysig bod y SDK webrtc.org yn cael ei ddatblygu'n weithredol gan Google.
Beth yw canlyniad gweithredu WebRTC?
I weld fideo byw o gamerâu, rydym wedi ychwanegu chwaraewr optimeiddio newydd yn seiliedig ar WebRTC i'ch cyfrif personol. Mae'n darparu llwytho fideo cyflymder uchel ac yn dileu'n llwyr y broblem o gronni hwyrni wrth i'r amser gwylio gynyddu.
Ar ôl gweithredu cefnogaeth WebRTC yng ngwasanaeth cwmwl Ivideon, gallwn ddweud yn gwbl hyderus y gall ein cwsmeriaid nawr wylio fideo byw llawn. Nawr nid yw'r oedi wrth ddarlledu'r dilyniant fideo yn fwy nag un eiliad! Er mwyn cymharu, darparodd yr injan HLS flaenorol ddosbarthiad fideo gydag oedi o 5-7 eiliad. Mae'r gwahaniaeth yn y cyflymder arddangos fideo yn arwyddocaol iawn, a bydd y defnyddiwr yn sylwi arno yn syth ar ôl dechrau gweithio gyda'n gwasanaeth fideo.
Yn ôl y disgwyl, roedd gweithredu'r chwaraewr newydd yn ei gwneud hi'n bosibl cynyddu ymatebolrwydd PTZ a chyfathrebu llais gyda'r camera.
Nid oes ond un pwynt cynnil yr ydym am dynnu sylw ato. Mae'r chwaraewr WebRTC newydd yn dal i weithio yn y modd prawf. A dyna pam nad ydym yn ei alluogi ar gyfer ein holl gleientiaid yn ddiofyn. Ond gallwch chi ei actifadu eich hun trwy alluogi'r eitem gyfatebol yn y gosodiadau camera (i wneud hyn, ewch i ).
Nodweddion gweithredu WebRTC yn y gwasanaeth Ivideon
Mae WebRTC yn dal i fod yn dechnoleg arbrofol ar hyn o bryd. Nid yw ei gefnogaeth wedi'i gweithredu'n gywir eto ym mhob porwr a dyfais defnyddiwr, ac nid ym mhob camera.
Dyma'n union beth sy'n esbonio'r ffaith nad ydym eto wedi gwneud y chwaraewr WebRTC yn brif ragosodiad ar gyfer pob defnyddiwr.
Am y tro, rydym yn argymell defnyddio WebRTC yn unig mewn porwyr Google Chrome. Mae'r fersiynau diweddaraf o Firefox a Safari hefyd yn cefnogi'r dechnoleg hon, ond yn anffodus nid yw'n sefydlog eto.
Nid ydym wedi gweithredu cefnogaeth WebRTC ar gyfer porwyr ar ddyfeisiau symudol eto. Nawr, os byddwch chi'n mewngofnodi o ddyfais symudol ac yn actifadu WebRTC, ni fydd y modd hwn yn gweithio. Fodd bynnag, mae WebRTC ar gael yn ein cymwysiadau symudol ar gyfer и .
A chwblhau'r stori am nodweddion gweithredu WebRTC yn ein gwasanaeth, nodwn ddau bwynt mwy cynnil.
Yn gyntaf, mae'r dechnoleg yn canolbwyntio ar ddarlledu fideo byw mewn amser real. Felly, os nad yw'ch lled band yn ddigon i drosglwyddo'r dilyniant fideo, byddwch yn sylwi ar ddisgyniadau ffrâm (gyda HLS byddwch yn sylwi ar fideo yn pylu a chynnydd mewn hwyrni, tra na fydd unrhyw fframiau'n cael eu gollwng), ond bydd y fideo yn dal i gael ei ddarlledu mewn go iawn amser.
Yn ail, gan fod y dechnoleg wedi'i chynllunio i weithio gyda fideo byw mewn amser real, nid ydym yn ei ddefnyddio i weithio gyda data fideo wedi'i archifo.
Newidiadau gwasanaeth eraill
Ar hyn o bryd, nid yw Flash bellach yn cymryd rhan yn y mecanwaith dewis injan awtomatig. Gallwch barhau i ddefnyddio chwaraewr o'r fath, ond ar gyfer hyn mae angen i chi ei ddewis â llaw yn y cyfrif neu osodiadau camera. Nid yw hyn yn deyrnged i ffasiwn, dim ond yn ôl ystadegau ein gwasanaeth, nid oes bron unrhyw ddefnyddwyr yn gweithio gyda Flash. Ac yn ceisio penderfynu a yw porwr y defnyddiwr yn ei gefnogi, rydym yn colli tua 2 eiliad o amser gwerthfawr.
Dyma grynodeb byr o'r newidiadau sy'n aros amdanoch chi yn ein system gwyliadwriaeth fideo cwmwl a chyfrif personol. Arhoswch gyda ni a dilynwch y newyddion!
Ffynhonnell: hab.com
