Низька затримка - це універсальне прагнення засобів масової інформації. Коли така компанія, як Wowza, створює ідеальну діаграму для пояснення технологій потокового передавання з низькою затримкою, вам потрібно зняти з них шапку та використовувати діаграму з атрибуцією та деякими незначними змінами. Я подаю згадану діаграму як малюнок 1; давайте обговоримо в порядку, визначеному виділеними цифрами, які я додав.
1. Заявки на низьку затримку
ПОСІБНИК ПО ПРОДУКЦІЇ
Найкращі PTZ-камери для прямого ефіру
Щоб переконатися, що ми всі на одній сторінці, затримка в контексті прямої трансляції означає затримку від скла до скла. Перша склянка - це камера фактичної події в прямому ефірі, друга - екран, який ви дивитесь. Затримка - це затримка між тим, коли з’являється на камері і коли з’являється на вашому телефоні. Сприяють затримці такі фактори, як час кодування (на заході), час транспортування в хмару, час перекодування в хмарі (для створення сходів кодування), час доставки і, що критично важливо, скільки секунд ваш плеєр буферизує до початку гри.
Верхній шар показує типові програми та вимоги до затримки. Популярні програми, які відсутні через низьку затримку та майже затримку в реальному часі, - це азартні сайти та аукціони.
Перш ніж заглибитися в наше обговорення технологій, зрозумійте, що чим менша затримка вашого прямого ефіру, тим менш стійким він є до перебоїв з пропускною здатністю. Наприклад, використовуючи налаштування за замовчуванням, потік HLS відтворюватиметься через 15+ секунд перерваної смуги пропускання, і якщо її відновити в цей момент, глядач може ніколи не дізнатися, що проблема сталася. На відміну від цього, потік із низькою затримкою припинить відтворення майже відразу після переривання. Отже, вигода від часу запуску з низькою затримкою завжди повинна бути збалансована проти негативу зупинок під час відтворення. Якщо вам абсолютно не потрібна низька затримка, можливо, не варто жертвувати стійкістю, щоб її отримати.
Тим не менш, корисно розділити латентність на три категорії, як описано нижче.
ПРО БЮЛЕТИНАудіо + Відео + ІТ. Наші редактори є експертами з інтеграції аудіо / відео та ІТ. Отримуйте щоденну інформацію, новини та професійні мережі. Підпишіться на Pro AV сьогодні.
- Добре мати - Швидше завжди краще, але якщо ви транслюєте в прямому ефірі засідання Ради з питань освіти або футбольну гру середньої школи, ви можете вирішити, що стійкість потоку важливіша за низьку затримку, особливо якщо багато глядачів дивляться на з’єднання з низьким бітрейтом.
- Конкурентну перевагу - У деяких випадках низька затримка забезпечує конкурентну перевагу, або повільна затримка означає конкурентний недолік. На графіку ви зауважите, що типова затримка кабельного телебачення становить близько п’яти секунд. Якщо ваша послуга потокового передавання конкурує з кабелем, вам слід знаходитись в цьому діапазоні, а низька затримка забезпечує помірну конкурентну перевагу.
- Зв’язок у режимі реального часу - Якщо ви граєте на азартних іграх або аукціоні, або якщо ваша програма іншим чином вимагає спілкування в режимі реального часу, вам абсолютно необхідно забезпечити низьку затримку.
- Посібник для порівняння потокової трансляції
- Як передбачити успіх кодека
Тепер, коли ми знаємо категорії, давайте розглянемо найефективніший спосіб забезпечити необхідний рівень низької затримки.
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, 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 Nanocosmos та Потокова хмара 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 - скільки потоків і чи є відповідні обмеження бітрейту або роздільної здатності?
- А як щодо функцій відеореєстратора? Чи можуть глядачі зупинити та перезапустити відтворення, не втрачаючи жодного вмісту.
- Синхронізація відео - Чи може система синхронізувати всіх глядачів до однієї точки потоку? Потоки можуть дрейфувати по місцях і пристроях, і без цієї можливості користувачі деяких з’єднань можуть мати перевагу для аукціонів чи азартних ігор.
- Який захист вмісту доступний? Якщо ви виробник вмісту преміум-класу, вам може знадобитися справжнє DRM. Інші можуть пройти аутентифікацію або інші подібні методи.
- Чи доступні підписи? Титри законодавчо обов’язкові для деяких передач, але загалом вигідні для всіх.
- А як щодо вставки реклами чи іншої схеми монетизації? Чи підтримує це технологія / постачальник послуг?
Взагалі, якщо ви є потоковим магазином, який прагне відповідати або перемагати час трансляції в діапазоні від 5 до 6 секунд, найкраще підійде стандартна технологія HTTP, оскільки вона буде найближчою до підтримки тієї самої набору функцій, яку ви ' в даний час використовується, як-от захист вмісту, субтитри та монетизація. Якщо у вас є програма, яка вимагає значно меншої затримки, вам, ймовірно, знадобиться рішення на базі WebRTC або Websockets, або власна технологія HTTP. У будь-якому випадку, задання перелічених вище питань має допомогти вам визначити постачальника технологій та / або послуг, який найкраще відповідає вашим потребам.
