Како разумети стриминг медија са малим кашњењем

Преглед садржаја:

Anonim

Ниска латенција универзална је тежња медија. Када компанија као што је Вовза изради савршену табелу која објашњава технологије стримовања са малим кашњењем, морате да им скинете капу и користите је уз атрибуцију и неке мање измене. Речени графикон представљам као слику 1; разговарајмо редом означеним бројевима које сам додао.

Слика 1. Савршени дијаграм Вовза за објашњење технологија са малим кашњењем. Измењено тако да искључује неке технологије са малим кашњењем којима се не бавим у овом чланку, попут СРТ и РТМП са малим кашњењем.

1. Пријаве за малу кашњење

ВОДИЧ ЗА ПРОИЗВОДЕ

Најбоље ПТЗ камере за стриминг уживо

Само да бисмо били сигурни да смо сви на истој страници, кашњење у контексту стриминга уживо значи кашњење од стакла до стакла. Прва чаша је камера на стварном догађају уживо, друга је екран који гледате. Латенција је кашњење између тренутка када се појављује у камери и када се појави на вашем телефону. Латенцији доприносе фактори као што су време кодирања (на догађају), време преноса у облак, време транскодирања у облаку (да би се створила лествица за кодирање), време испоруке и критично колико секунди ваш играч баферује пре почетка игре.

Горњи слој приказује типичне примене и њихове захтеве за кашњењем. Популарне апликације које недостају због латенције и кашњења готово у реалном времену су коцкање и аукције.

Пре него што уђете у нашу расправу о технологији, схватите да што је мања латенција вашег стрима уживо, то је стреам мање отпоран на прекиде пропусности. На пример, помоћу подразумеваних подешавања, ХЛС ток ће се репродуковати кроз 15+ секунди прекинутог пропусног опсега и ако се у том тренутку обнови, гледалац можда никада неће знати да је дошло до проблема. Насупрот томе, ток са малим кашњењем ће престати да се репродукује готово одмах након прекида. Дакле, корист од времена покретања са малим кашњењем увек треба уравнотежити са негативном заустављањем у репродукцији. Ако вам апсолутно не треба мала латенција, можда не би било вредно жртвовати еластичност да бисте је добили.

Међутим, корисно је поделити кашњење у три категорије, како следи.

ПРО НЕВСЛЕТТЕР

Аудио + Видео + ИТ. Наши уредници су стручњаци за интеграцију аудио / видео и ИТ. Добијте свакодневне увиде, вести и професионално умрежавање. Претплатите се на Про АВ данас.

  • Лепо је имати - Брже је увек боље, али ако уживо преносите састанак одбора за образовање или фудбалску утакмицу у средњој школи, можда ћете одлучити да је робусност стрима важнија од мале кашњења, посебно ако многи гледаоци гледају на везама са малим брзинама.
  • Конкурентска предност - У неким случајевима, мала латенција пружа конкурентску предност, или спора латенција значи конкурентски недостатак. На графикону ћете приметити да је типично кашњење кабловске телевизије око пет секунди. Ако се ваша услуга стримовања надмеће са кабловском, морате да будете у том опсегу, са нижом кашњењем која пружа умерену конкурентску предност.
  • Комуникација у реалном времену - Ако сте коцкање или аукција или ваша апликација на неки други начин захтева комуникацију у реалном времену, апсолутно морате да пружите малу кашњење.
  • Водич за упоређивање стримовања уживо
  • Како предвидети успех кодека

Сад кад знамо категорије, погледајмо најефикаснији начин да пружимо потребан ниво ниске латенције.

2/3 Лепо је имати малу кашњење

Број 2 показује да су Аппле ХЛС и МПЕГ-ДАСХ примењени помоћу њихових подразумеваних подешавања резултирају око 30 секунди кашњења. Бројеви су једноставни; ако користите величине од десет секунди и желите да три сегмента буду у баферу уређаја за репродукцију пре почетка репродукције, на тридесет сте секунди. Заправо, Аппле је пре неколико година променио своје захтеве са десет на шест секунди, а већина произвођача ДАСХ користи сегменте од 4 до 6 секунди, тако да је задати број заиста ближи 20 секунди.

Ипак, број 3, ХЛС Тунед и ДАСХ Тунед, показује кашњење од око 6-8 секунди. У суштини, подешавање значи прелазак са сегмената од 10 секунди на сегменте од 2 секунде, који применом исте математике пружају 6-8 секунди кашњења. Дакле, када је кашњење лепо имати, можете драматично смањити кашњење без времена за развој или трошкова или знатно повећаног ризика испоручивости.

4. Конкурентска предност - ХТТП технологије са малим кашњењем

Када је мала латенција потребна као конкурентска предност, само резање величина сегмената то неће учинити; мораћете да примените истинску технологију са малим кашњењем. Овде постоје две класе; ХТТП технологије као што су ХЛС са малим кашњењем и ЦМАФ са малим кашњењем за ДАСХ, и решења заснована на другим технологијама, попут ВебСоцкетс и ВебРТЦ.

За већину произвођача са апликацијама из ове класе, ХТТП технологије са малим кашњењем нуде најбољу комбинацију приступачности, повратне компатибилности, флексибилности и скупа функција. Дакле, у овом одељку ћу описати ХЛС са ниским кашњењем и ЦМАФ са малим кашњењем за ДАСХ, а у наставку и друге технологије.

Сви системи ниске латенције засновани на ХЛС / ДАСХ / ЦМАФ раде на исти основни начин, као што је приказано на слици 2. То јест, уместо да чекају док се не кодира читав сегмент, што обично траје између 6-10 секунди (врх слике 2) , кодер ствара много краће делове који се преносе на ЦДН чим заврше (дно слике 2).

Слика 2. Из хармоничног белог папира под насловом ДАСХ ЦМАФ ЛЛЦ да игра кључну улогу у омогућавању ниског кашњења видео преноса доступан овде.

На пример, ако ваш кодер производи сегменте од шест секунди, имали бисте најмање шест секунди кашњења; троструко ако би гледалац требало да прими нормална три сегмента пре него што репродукција започне. Међутим, ако је ваш кодер потиснуо делове на сваких 200 милисекунди, а уређај је конфигурисан да одмах започне репродукцију, кашњење би требало да буде много, много мање. Једна од кључних предности ове шеме је уназад компатибилност; с обзиром да се сегменти још увек креирају, играчи који нису компатибилни са шемом са малим кашњењем и даље би требали моћи да играју сегменте, мада са већом латенцијом. Ови сегменти су такође тренутно доступни за ВОД презентације из стрима уживо.

Поред ових предности, ХТТП технологије са малим кашњењем подржавају већину карактеристика своје уобичајене браће и сестара са кашњењем, укључујући шифровање, уметање реклама и титловање, које нису универзална подршка у технологијама заснованим на ВебРТЦ и ВебСоцкетс. Вероватно можете да примените изабрану технологију са малим кашњењем користећи постојећи плејер и инфраструктуру испоруке, минимализујући развојне и друге технолошке трошкове.

Избор ХТТП технологије са малим кашњењем

Постоје два главна стандарда за ХТТП прилагодљиво струјање, ХЛС и ДАСХ, плус обједињени формат контејнера, ЦМАФ. Једном када је Аппле најавио своје ХЛС решење са малим кашњењем, одмах је преселио неколико основних напора и постао технологија одабира за испоруку ниске латенције ХЛС-у. Иако су спецификације још увек релативно нове, већ их подржавају добављачи технологија попут Вовза и ВМСПанел са својим производом Нимбле Стреамер.

Постоји ДВБ стандард за ДАСХ са малим кашњењем и Индустријски форум ДАСХ одобрио је неколико режима са ниском латенцијом за ДАСХ који ће бити укључени у њихове следеће смернице за интероперабилност. У складу са свим овим спецификацијама, програмери енкодера и плаиера и мреже за испоруку садржаја раде већ неколико година како би осигурали интероперабилност тако да би све ДАСХ / ЦМАФ апликације са малим кашњењем требале да дођу до темеља.

Најбоље ПТЗ камере за стриминг уживо

Као пример, Хармониц и Акамаи заједно су демонстрирали ЦМАФ са малим кашњењем још у време НАБ-а и ИБЦ-а 2017, показујући испоруку ОТТ уживо са латенцијом испод пет секунди. Од тада је Хармониц интегрисао ДАСХ функционалност са малим кашњењем у своје производе засноване на уређајима (Пацкагер КСОС и Елецтра КСОС) и СааС решења (ВОС Цлустер и ВОС260). Многи други добављачи кодера и уређаја за репродукцију учинили су то исто.

Без обзира да ли се одлучите за примену ХЛС са малим кашњењем или са малим кашњењем за ДАСХ, или обоје, прелазак са ваше постојеће ХЛС и / или ДАСХ архитектуре испоруке требало би да буде релативно неприметан и јефтин.

5. Комуникације у реалном времену

ВебРТЦ је обично мотор интегрисаног пакета који укључује енкодер, плејер и инфраструктуру испоруке. Примери великих проточних решења заснованих на ВебРТЦ-у укључују Реал Тиме из Пхеника, Лимелигхт Реалтиме Стреаминг и Миллицаст из ЦоСМо Софтваре и Инфлукис (слика 3). Такође можете приступити технологији ВебРТЦ у алатима попут Вовза Стреаминг Енгине, ЦоСМО софтвера и Ред 5 Про сервера. Времена кашњења за технологије из ове класе крећу се од .5 секунди за 71% стримова (Пхеник), мање од 500 милисекунди (Ред5 Про), до мање од једне секунде (Лимелигхт). Ако вам треба латенција испод две секунде, ВебРТЦ је опција коју требате узети у обзир.

Ако су вам потребне комуникације у реалном времену, вероватно ћете морати да примените решење засновано на ВебРТЦ или Вебсоцкетс. ВебРТЦ је формулисан за комуникацију између прегледача и прегледача, а подржавају га сви главни прегледачи на радној површини, на Андроиду, иОС-у, Цхроме ОС-у, Фирефок ОС-у, Тизен 3.0 и БлацкБерри 10, тако да би требало да ради без преузимања на било којој од ових платформи. Као што и само име говори, ВебРТЦ је протокол за испоруку стримова уживо сваком гледаоцу, било пеер-то-пеер или серверу пеер.

Слика 3. Преглед система система заснованог на Миллицаст ВебРТЦ за велике преносе уживо са латенцијом испод секунде.

ВебСоцкетс је протокол у стварном времену који ствара и одржава трајну везу између сервера и клијента којег било која страна може користити за пренос података. Ова веза се може користити за подршку испоруке видео записа и других комуникација, па је погодна ако је вашој апликацији потребна интерактивност. Као и ВебРТЦ имплементације, услуге које користе ВебСоцкетс обично се нуде као услуга која укључује плејер и ЦДН, а можете користити било који кодер који може преносити токове на сервер путем РТМП-а или ВебРТЦ-а. Примери укључују Наноцосмос наноСтреам Цлоуд и Вовза Стреаминг Цлоуд са ултра ниском кашњењем. Вовза тврди да је кашњење испод 3 секунде за њихово решење, док Наноцосмос тврди око једне секунде, стакло до стакла.

Остале технологије са малим кашњењем

Постоји четврта категорија производа која се најбоље назива „остали“ и који користе различите технологије како би обезбедили малу кашњење. Ова категорија укључује ТХЕО Тецхнологиес Хигх Еффициенци Стреаминг Протоцол (ХЕСП), власнички ХТТП протокол прилагодљивог протока који према ТХЕО-у пружа латенцију испод 100 милисекунди, истовремено смањујући пропусни опсег за око 10% у поређењу са другим технологијама са ниском латенцијом. ХЕСП користи стандардне кодере и ЦДН-ове, али захтева прилагођену подршку у пакету и уређају за репродукцију (слика 4). Више о ХЕСП-у можете прочитати у белом папиру доступан за преузимање овде.

Слика 4. ТХЕО-ов ХЕСП је заштићени протокол компатибилан са већином ЦДН-ова.

Ево листе питања која бисте требали узети у обзир приликом одлучивања коју технологију са малим кашњењем да примените и како то учинити.

Изградити или купити?

Ако сами примените технологију, обавезно одговорите на сва доленаведена питања пре него што одаберете технологију. Ако бирате добављача услуга, користите их за упоређивање различитих пружалаца услуга.

Да ли бирате стандард или партнера?

Изнад смо истакли различите технологије за постизање мале кашњења, али примене се разликују од добављача услуга до добављача услуга. Дакле, неће сва примена ЛЛ ХЛС-а укључивати испоруку АБР-а, бар не у почетку. Већина традиционалних апликација сличних емитовању вероватно ће мигрирати ка ХТТП стандардима као што су ХЛС / ДАСХ / ЦМАФ са малим кашњењем, док ће апликације којима је потребно ултра ниско кашњење попут клађења и аукција гравитирати према осталим технологијама. У оба случаја, приликом избора добављача услуга важније је утврдити могу ли они испунити ваше технолошке и пословне циљеве, него коју технологију заправо примењују.

Може ли се скалирати и по којој цени?

Једна од предности технологија заснованих на ХТТП-у је што се скалирају по стандардним ценама користећи већину ЦДН-ова. Супротно томе, за већину технологија заснованих на ВебРТЦ и ВебСоцкет потребна је посебна инфраструктура испоруке коју примењује добављач услуга. Из тог разлога, услуге које се не темеље на ХТТП-у могу бити скупље за испоруку од ХЛС / ДАСХ / ЦМАФ. Када упоређујете добављаче услуга, утврдите трошкове супе и ораха догађаја, укључујући улаз, прекодирање, пропусни опсег, стварање ВОД датотека, једнократне конфигурације или конфигурације по догађају и слично.

Питања везана за имплементацију?

Поставите следећа питања у вези са применом и употребом технологије.

  • Која је кашњења која се могу постићи на скали која је релевантна за величину ваше публике и географску дистрибуцију?
  • Постоје ли ограничења квалитета - неке технологије могу бити ограничене на одређене максималне резолуције или Х.264 профиле.
  • Да ли ће пакети проћи кроз заштитни зид? Системи засновани на ХТТП-у користе ХТТП протоколе који су заштићени од заштитног зида. Други користе УДП, који можда неће аутоматски проћи кроз заштитни зид. Ако је УДП, постоје ли повратни канали за испоруку блокираним гледаоцима?
  • Које платформе су подржане? Вероватно рачунари и мобилни уређаји, али шта је са СТБ-овима, донгловима, ОТТ уређајима и паметним телевизорима?
  • Да ли систем може да се прилагоди бројевима циљних гледалаца? Да ли је ЦДН инфраструктура приватна и ако може, може ли је пружити свим релевантним гледаоцима на свим релевантним тржиштима? Који су предвиђени трошкови скалирања?
  • Да ли можете да користите свој плејер или морате да користите системски плејер? Ако је ваш сопствени, које промене су потребне и колико ће то коштати?
  • Шта је потребно за репродукцију на мобилном уређају? Да ли ће се стримови репродуковати у прегледачу или је потребна апликација? Ако постоји потребна апликација (или је пожељна), да ли су доступни СДК-ови?
  • Које кодере систем може користити? Већина би требало да користи било који кодер који може да подржава РТМП везе у транскодер у облаку, али проверите да ли су потребни други протоколи.
  • Може ли се садржај поново користити за ВОД или ће бити потребно поновно кодирање? Није велика ствар јер кошта око 20 УСД / сат видео записа да би се транскодирао на разумну лествицу кодирања, али је скуп за честа емитовања.
  • Које су могућности вишка и који су трошкови? За емисије критичне за мисију, желели бисте да знате како да дуплирате ток рада кодирања / емитовања уколико било која системска компонента падне током догађаја. Да ли је подржан овај вишак и колика је цена?

Које функције су доступне и у ком обиму?

Биће понуђена широка палета карактеристика различитих добављача, што може и не мора укључивати:

  • АБР стреаминг - колико токова и да ли постоје релевантна ограничења брзине или резолуције?
  • Шта је са карактеристикама ДВР-а? Могу ли гледаоци зауставити и поново покренути репродукцију без губитка садржаја.
  • Видео синхронизација - Да ли систем може да синхронизује све гледаоце са истом тачком у стриму? Потоци се могу пребацивати преко локација и уређаја, а без ове могућности корисници на неким везама могу имати предност за аукције или коцкање.
  • Која је заштита садржаја доступна? Ако сте произвођач врхунског садржаја, можда ће вам требати прави ДРМ. Други могу да се снађу помоћу аутентификације или других сличних техника.
  • Да ли су доступни титлови? Натписи су законски потребни за нека емитовања, али углавном корисни за све.
  • Шта је са уметањем реклама или другом шемом монетизације? Да ли добављач технологије / услуге то подржава?

Генерално, ако сте стреаминг продавница која жели да испуни или победи време емитовања у опсегу од 5 до 6 секунди, ХТТП технологија заснована на стандардима је вероватно ваша најбоља опклада, јер ће бити најближа подршци истој функцији коју сте поставили ' који тренутно користе, попут заштите садржаја, описа и уновчавања. Ако имате апликацију која захтева много ниже кашњење, вероватно ће вам требати решење засновано на ВебРТЦ или Вебсоцкетс или заштићена ХТТП технологија. У оба случаја постављање горе наведених питања требало би да вам помогне да идентификујете добављача технологије и / или услуге који најбоље одговара вашим потребама.