Ниската латентност е универсален стремеж в медиите. Когато компания като Wowza създава перфектната диаграма, за да обясни технологиите за стрийминг с ниска латентност, трябва да им свалите шапката и да използвате диаграмата с приписване и някои незначителни модификации. Представям споменатата диаграма като Фигура 1; нека обсъдим в реда, посочен от маркираните числа, които съм добавил.
1. Приложения за ниска латентност
РЪКОВОДСТВО ЗА ПРОДУКТИ
Най-добрите PTZ камери за стрийминг на живо
Само за да сме сигурни, че всички сме на една и съща страница, латентността в контекста на поточното предаване на живо означава забавяне от стъкло до стъкло. Първата чаша е камерата на действителното събитие на живо, втората е екранът, който гледате. Латентността е закъснението между появата в камерата и когато тя се показва на телефона ви. Допринасящи за латентността са фактори като време за кодиране (на събитието), време за транспортиране до облака, време за прекодиране в облака (за създаване на стълбата за кодиране), време за доставка и критично колко секунди вашият играч буферира, преди да започне да играе.
Най-горният слой показва типичните приложения и техните изисквания за латентност. Популярни приложения, които липсват поради ниска латентност и почти латентност в реално време, са сайтове за хазарт и търгове.
Преди да се потопите в нашата дискусия за технологиите, разберете, че колкото по-ниска е латентността на потока ви на живо, толкова по-малко еластичен е потокът към прекъсванията на честотната лента. Например, използвайки настройките по подразбиране, HLS поток ще се възпроизведе през 15+ секунди прекъсната честотна лента и ако се възстанови в този момент, зрителят може никога да не знае, че е имало проблем. За разлика от това потокът с ниска латентност ще спре да играе почти веднага след прекъсване. Така че, предимството от времето за стартиране с ниска латентност винаги трябва да бъде балансирано спрямо отрицателното при спиране при възпроизвеждане. Ако не се нуждаете абсолютно от ниска латентност, може да не си струва да жертвате устойчивостта, за да я получите.
Въпреки това е полезно да се раздели латентността на три категории, както следва.
ПРО БЮЛЕТИНАудио + Видео + ИТ. Нашите редактори са експерти в интегрирането на аудио / видео и ИТ. Получавайте ежедневна информация, новини и професионални мрежи. Абонирайте се за Pro AV днес.
- Приятно е да имаш - По-бързо е винаги по-добре, но ако излъчвате на живо среща на Board of Education или футболна игра в гимназията, може да решите, че стабилността на потока е по-важна от ниската латентност, особено ако много зрители гледат на връзки с ниска скорост.
- Конкурентно предимство - В някои случаи ниската латентност осигурява конкурентно предимство или бавната латентност означава конкурентно неблагоприятно положение. В диаграмата ще забележите, че типичната латентност за кабелна телевизия е около пет секунди. Ако вашата услуга за стрийминг се конкурира с кабел, трябва да сте в този диапазон, като по-ниската латентност осигурява скромно конкурентно предимство.
- Комуникации в реално време - Ако сте сайт за хазарт или търг или приложението ви по друг начин изисква комуникация в реално време, абсолютно трябва да осигурите ниска латентност.
- Ръководство за сравнение на живо
- Как да предскажете успеха на кодека
Сега, след като познаваме категориите, нека разгледаме най-ефективния начин за осигуряване на необходимото ниво на ниска латентност.
2/3 Хубаво е да имате ниска латентност
Числото 2 показва, че Apple HLS и MPEG-DASH, внедрени, използвайки настройките им по подразбиране, водят до около 30 секунди латентност. Числата са прости; ако използвате десетсекундни размери на сегменти и изисквате три сегмента да са в буфера на плейъра, преди да започне възпроизвеждането, вие сте на тридесет секунди. В действителност, Apple промени своите изисквания от десет секунди на шест секунди преди няколко години и повечето производители на DASH използват сегменти от 4 до 6 секунди, така че номерът по подразбиране наистина е по-близо до 20 секунди.
И все пак номер 3, HLS Tuned и DASH Tuned, показва латентност от около 6-8 секунди. По същество настройката означава преминаване от 10-секундни сегменти към 2-секундни сегменти, които, прилагайки същата математика, осигуряват 6-8 секунди латентност. Така че, когато е забавно да имате латентност, можете драстично да намалите латентността, без време за разработка или разходи или значително увеличен риск за доставяне.
4. Конкурентно предимство - HTTP технологии с ниска латентност
Когато е необходима ниска латентност като конкурентно предимство, само рязането на размерите на сегментите няма да го направи; ще трябва да внедрите истинска технология с ниска латентност. Тук има два класа; HTTP технологии като HLS с ниска латентност и CMAF с ниска латентност за DASH и решения, базирани на други технологии, като WebSockets и WebRTC.
За повечето производители с приложения от този клас HTTP технологиите с ниска латентност предлагат най-добрата комбинация от достъпност, обратна съвместимост, гъвкавост и набор от функции. Така че, ще разгледам HLS с ниска латентност и CMAF с ниска латентност за DASH в този раздел и други технологии в следващия.
Всички базирани на HLS / DASH / CMAF системи с ниска латентност работят по същия основен начин, както е показано на Фигура 2. Тоест, вместо да чакат, докато се кодира целият сегмент, което обикновено отнема между 6-10 секунди (отгоре на Фигура 2) , кодерът създава много по-къси парчета, които се прехвърлят към CDN веднага щом завършат (дъното на фигура 2).
Като пример, ако вашият енкодер е генерирал шестсекундни сегменти, ще имате поне шест секунди латентност; тройно, ако нормалните три сегмента трябва да бъдат получени от зрителя преди началото на възпроизвеждането. Ако обаче вашият енкодер изтласква парчета на всеки 200 милисекунди и плейърът е конфигуриран да започне незабавно възпроизвеждане, латентността трябва да бъде много, много по-малка. Едно ключово предимство на тази схема е обратната съвместимост; тъй като сегментите все още се създават, играчите, които не са съвместими със схемата с ниска латентност, все още трябва да могат да играят сегментите, макар и с по-голяма латентност. Тези сегменти са незабавно достъпни и за VOD презентации от потока на живо.
Освен тези предимства, HTTP технологиите с ниска латентност поддържат повечето от характеристиките на техните нормални латентни братя и сестри, включително криптиране, вмъкване на реклами и субтитри, които не са универсална поддръжка в базирани на WebRTC и WebSockets технологии. Вероятно можете да внедрите избраната от вас технология с ниска латентност, като използвате съществуващата инфраструктура на плейъра и доставката, като минимизирате разходите за развитие и други технологии.
Избор на HTTP технология с ниска латентност
Има два основни стандарта за HTTP Adaptive Streaming, HLS и DASH, плюс унифициращ формат на контейнера, CMAF. След като Apple обяви своето HLS решение с ниска латентност, той незабавно измести няколко основни усилия и се превърна в избраната технология за предоставяне на ниска латентност на HLS. Въпреки че спецификацията е все още сравнително нова, тя вече се поддържа от технологични доставчици като Wowza и WMSPanel с техния продукт Nimble Streamer.
Има DVB стандарт за DASH с ниска латентност и индустриалният форум на DASH одобри няколко режима с ниска латентност за DASH, които да бъдат включени в следващите им насоки за оперативна съвместимост. Съгласно всички тези спецификации, разработчиците на енкодери и плейъри и мрежите за доставка на съдържание работят от няколко години, за да осигурят оперативна съвместимост, така че всички приложения с ниска латентност на DASH / CMAF да улеснят.
Като пример, Harmonic и Akamai заедно демонстрираха CMAF с ниска латентност още до NAB и IBC 2017, показвайки доставка на OTT на живо с латентност под пет секунди. Оттогава Harmonic интегрира функционалността DASH с ниска латентност в своите продукти, базирани на уреди (Packager XOS и Electra XOS) и SaaS решения (VOS Cluster и VOS260). Много други доставчици на енкодери и плейъри са направили същото.
Независимо дали решите да внедрите HLS с ниска латентност или ниска латентност за DASH, или и двете, преходът от вашата съществуваща архитектура за доставка на HLS и / или DASH трябва да бъде относително безпроблемен и евтин.
5. Комуникации в реално време
WebRTC обикновено е двигател за интегриран пакет, който включва кодера, плейъра и инфраструктурата за доставка. Примери за базирани на WebRTC широкомащабни решения за стрийминг включват Real Time от Phenix, Limelight Realtime Streaming и Millicast от CoSMo Software и Influxis (Фигура 3). Можете също така да получите достъп до технологията WebRTC в инструменти като Wowza Streaming Engine, CoSMO Software и Red 5 Pro Server. Времената на латентност за технологии от този клас варират от .5 секунди за 71% от потоците (Phenix), под 500 милисекунди (Red5 Pro), до под една секунда (Limelight). Ако имате нужда от латентност под две секунди, WebRTC е опция, която трябва да имате предвид.
Ако имате нужда от комуникации в реално време, вероятно ще трябва да внедрите решение, базирано на WebRTC или Websockets. WebRTC е формулиран за комуникация между браузър и се поддържа от всички основни браузъри за настолни компютри, на Android, iOS, Chrome OS, Firefox OS, Tizen 3.0 и BlackBerry 10, така че трябва да работи без изтегляния на никоя от тези платформи. Както подсказва името, WebRTC е протокол за доставяне на потоци на живо до всеки зрител, или от равнопоставено ниво, или от сървър към равнопоставено.
WebSockets е протокол в реално време, който създава и поддържа постоянна връзка между сървър и клиент, който всяка страна може да използва за предаване на данни. Тази връзка може да се използва както за доставка на видео, така и за други комуникации, така че е удобна, ако вашето приложение се нуждае от интерактивност. Подобно на внедряванията на WebRTC, услугите, които използват WebSockets, обикновено се предлагат като услуга, която включва плейър и CDN и можете да използвате всеки кодер, който може да транспортира потоци до сървъра чрез RTMP или WebRTC. Примерите включват nanoStream Cloud на Nanocosmos и Streaming Cloud на Wowza с ултра ниска латентност. Wowza претендира за латентност под 3 секунди за своето решение, докато Nanocosmos твърди около една секунда, стъкло на стъкло.
Други технологии с ниска латентност
Има четвърта категория продукти, наречени най-добре „други“, които използват различни технологии, за да осигурят ниска латентност. Тази категория включва THEO Technologies High Efficiency Streaming Protocol (HESP), патентован HTTP адаптивен протокол за стрийминг, който според THEO осигурява латентност под 100 милисекунди, като същевременно намалява честотната лента с около 10% в сравнение с други технологии с ниска латентност. HESP използва стандартни кодери и CDN, но изисква персонализирана поддръжка в пакета и плейъра (Фигура 4). Можете да прочетете повече за HESP в бяла книга, достъпна за изтегляне, тук.
Ето списък с въпроси, които трябва да имате предвид, когато решавате коя технология с ниска латентност да приложите и как да го направите.
Изграждане или покупка?
Ако внедрите технологията сами, не забравяйте да отговорите на всички изброени по-долу въпроси, преди да изберете технология. Ако избирате доставчик на услуги, използвайте ги, за да сравните различните доставчици на услуги.
Избирате ли стандарт или партньор?
По-горе посочихме различните технологии за постигане на ниска латентност, но внедряванията варират при различните доставчици на услуги. Така че, не всички внедрения на LL HLS ще включват доставка на ABR, поне не в началото. Повечето традиционни приложения, подобни на излъчване, вероятно ще мигрират към HTTP-базирани стандарти като HLS / DASH / CMAF с ниска латентност, докато приложенията, изискващи ултра ниска латентност като залагания и търгове, ще гравитират към другите технологии. И в двата случая при избора на доставчик на услуги е по-важно да определите дали те могат да изпълнят вашите технологични и бизнес цели, отколкото коя технология всъщност прилагат.
Може ли да се мащабира и на каква цена?
Едно от предимствата на HTTP-базираните технологии е, че те се мащабират при стандартни цени, използвайки повечето CDN. За разлика от тях, повечето базирани на WebRTC и WebSocket технологии изискват специална инфраструктура за доставка, внедрена от доставчика на услуги. Поради тази причина услугите, които не са базирани на HTTP, могат да бъдат по-скъпи за предоставяне от HLS / DASH / CMAF. Когато сравнявате доставчиците на услуги, установете супата с ореховите разходи за събитието, включително влизане, прекодиране, честотна лента, създаване на VOD файл, еднократни конфигурации или конфигурации за събитие и други подобни.
Въпроси, свързани с изпълнението?
Задайте следните въпроси, свързани с внедряването и използването на технологията.
- Каква е латентността, постижима в мащаб, съответстващ на размера на аудиторията ви и географското разпределение?
- Има ли ограничения за качество - някои технологии могат да бъдат ограничени до определени максимални разделителни способности или профили H.264.
- Ще преминат ли пакетите през защитна стена? Базираните на HTTP системи използват HTTP протоколи, които са удобни за защитна стена. Други използват UDP, който може да не премине автоматично през защитни стени. Ако UDP, има ли обратни канали, които да се доставят на блокирани зрители?
- Какви платформи се поддържат? Вероятно компютри и мобилни устройства, но какво ще кажете за STB, донгли, OTT устройства и интелигентни телевизори?
- Може ли системата да се мащабира така, че да отговаря на целевите ви зрителски номера? Инфраструктурата на CDN частна ли е и ако да, може ли да достави на всички съответни зрители на всички съответни пазари? Какви са очакваните разходи за мащабиране?
- Можете ли да използвате собствения си плейър или трябва да използвате плейъра на системата? Ако сте собствени, какви промени са необходими и колко ще струва това?
- Какво е необходимо за възпроизвеждане от мобилни устройства? Ще се възпроизвеждат ли потоците в браузър или е необходимо приложение? Ако има необходимо приложение (или желателно), налични ли са SDK?
- Кои енкодери може да използва системата? Повечето трябва да използват всеки кодер, който може да поддържа RTMP връзки в облачния транскодер, но проверете дали са необходими други протоколи.
- Може ли съдържанието да се използва повторно за VOD или ще се наложи повторно кодиране? Не е голяма сделка, тъй като струва около 20 щ.д. / час видео за прекодиране в разумна стълба за кодиране, но скъпо за чести излъчвания.
- Какви са възможностите за съкращаване и какви са разходите? За критично важни излъчвания ще искате да знаете как да дублирате работния поток на кодирането / излъчването, ако някой системен компонент падне по време на събитието. Поддържа ли се това съкращаване и каква е цената?
Какви функции са налични и в какъв мащаб?
Ще има голямо разнообразие от предложения за функции от различните доставчици, които могат или не могат да включват:
- ABR стрийминг - колко потока и има ли съответни ограничения за битрейт или разделителна способност?
- Какво ще кажете за характеристиките на DVR? Могат ли зрителите да спрат и рестартират възпроизвеждането, без да губят никакво съдържание.
- Видео синхронизация - Може ли системата да синхронизира всички зрители до една и съща точка в потока? Потоците могат да се носят по места и устройства и без тази възможност потребителите на някои връзки могат да имат предимство за търгове или хазарт.
- Каква защита на съдържанието е на разположение? Ако сте производител на първокласно съдържание, може да се нуждаете от истински DRM. Други могат да се справят с удостоверяване или други подобни техники.
- Налични ли са надписи? Надписите са законно задължителни за някои предавания, но като цяло са полезни за всички.
- Какво ще кажете за вмъкване на реклама или друга схема за осигуряване на приходи? Поддържа ли доставчикът на технологии / услуги това?
Като цяло, ако сте стрийминг магазин, който се стреми да се срещне или да победи времето за излъчване в диапазона от 5 до 6 секунди, HTTP технологията, базирана на стандарти, е може би най-добрият ви залог, тъй като тя ще бъде най-близка до поддържането на същия набор от функции, в момента се използват, като защита на съдържанието, надписи и осигуряване на приходи. Ако имате приложение, което изисква много по-ниска латентност, вероятно ще ви е необходимо решение, базирано на WebRTC или Websockets, или собствена HTTP технология. И в двата случая задаването на изброените по-горе въпроси трябва да ви помогне да определите доставчика на технология и / или услуга, който най-добре отговаря на вашите нужди.
