Щодня мільйони глядачів дивляться відео в Інтернеті. Але щоб відео стало доступним, його потрібно не лише завантажити на сервер, а й обробити. Чим швидше це відбувається – тим краще сервісу та його користувачам.
Мене звуть Аскар Камалов, рік тому я приєднався до команди відеотехнологій Яндекса. Сьогодні я коротко розповім читачам Хабра про те, як за допомогою розпаралелювання процесу кодування нам удалося в рази прискорити доставку відео до користувача.
Ця посада насамперед буде цікава тим, хто раніше не замислювався про те, що відбувається під капотом відеосервісів. У коментарях можна ставити запитання та пропонувати теми для майбутніх постів.
Кілька слів про завдання. Яндекс не лише допомагає шукати відео на інших сайтах, а й зберігає відео для власних сервісів. Будь то авторська програма чи спортивний матч в Ефірі, фільм на КіноПошуку або ролики в Дзені та Новинах — все це завантажується на наші сервери. Щоб користувачі переглянули відео, його потрібно підготувати: конвертувати в необхідний формат, створити превьюшку або навіть прогнати через технологію . Непідготовлений файл просто посідає місце. Причому йдеться не лише про оптимальне використання заліза, а й швидкість доставки контенту до користувачів. Приклад: запис із вирішальним моментом хокейного матчу можуть шукати в пошуку вже за хвилину після події.
Послідовне кодування
Отже, щастя користувача багато в чому залежить від того, як швидко відео стане доступним. І це переважно визначається швидкістю транскодирования. Коли жорстких вимог до швидкості викладення відео немає, то проблем немає. Берете єдиний, неподільний файл, конвертуєте його, викладаєте. На початку свого шляху ми так і працювали:
Клієнт завантажує відео у сховище, компонент Analyzer збирає метаінформацію та передає відео на конвертацію у компонент Worker. Усі етапи виконуються послідовно. При цьому серверів для кодування може бути багато, але один зайнятий обробкою конкретного відео. Проста прозора схема. На цьому її переваги закінчуються. Така схема масштабується лише вертикально (за рахунок покупки потужніших серверів).
Послідовне кодування із проміжним результатом
Щоб хоч якось згладити болісне очікування, в індустрії вигадали варіант швидкого кодування. Оманлива назва, тому що насправді повноцінне кодування відбувається послідовно і так само довго. Зате з проміжним результатом. Ідея така: якнайшвидше підготувати і викласти версію відео в низькій роздільній здатності, а вже потім — версії вищих дозволів.
З одного боку, відео стає швидше. І це корисно для важливих подій. Але з іншого — картинка виходить розмита, а це дратує глядачів.
Виходить, потрібно не лише швидко обробляти відео, а й зберігати його якість. Це те, на що чекають від відеосервісу користувачі зараз. Може здатися, що досить купити найбільш продуктивні сервери (і регулярно разом їх усі апгрейдити). Але це шлях у глухий кут, тому що завжди знайдеться відео, яке змусить гальмувати навіть найпотужніше залізо.
Паралельне кодування
Куди ефективніше поділити складне завдання на безліч менш складних і паралельно вирішувати їх на різних серверах. Такий ось MapReduce для відео. У цьому випадку ми не впираємося в продуктивність одного сервера і можемо масштабуватись горизонтально (за рахунок додавання нових машин).
До речі, ідея дробити відео на дрібні шматки, паралельно обробляти та склеювати їх – не якийсь секрет. Ви можете знайти безліч згадок про цей підхід (наприклад, на Хабрі рекомендую пост про проект ). Але від цього загалом не стає легше, бо не можна просто так узяти вже готове рішення та вбудувати до себе. Потрібна адаптація під нашу інфраструктуру, наше відео та навіть наше навантаження. Загалом простіше написати своє.
Отже, у новій архітектурі монолітний блок Worker з послідовним кодуванням ми розділили на мікросервіси Segmenter, Tcoder, Combiner.
- Segmenter розбиває відео на фрагменти приблизно 10 секунд. Фрагменти складаються з однієї або кількох GOP (). Кожна GOP є незалежною та кодується окремо, так що може бути декодована без посилання на кадри з інших GOP. Тобто фрагменти можуть відтворюватись незалежно один від одного. Таке сегментування зменшує затримку, дозволяючи розпочати обробку раніше.
- Tcoder обробляє кожен фрагмент. Він бере завдання з черги, скачує фрагмент зі сховища, кодує різні дозволи (нагадаємо, що плеєр може вибирати версію, виходячи зі швидкості з'єднання), потім складає результат назад у сховище і помічає фрагмент обробленим в базі даних. Обробивши всі фрагменти, Tcoder відправляє завдання формування результатів наступного компонента.
- Сombiner збирає результати разом: завантажує всі фрагменти, зроблені Tcoder, формує потоки для різних дозволів.
Декілька слів про звук. Найбільш популярний аудіокодек AAC має неприємну особливість. Якщо кодувати фрагменти окремо, склеїти їх безшовно просто не вийде. Переходи будуть помітні. У відеокодеків такої проблеми немає. Теоретично можна пошукати складне технічне рішення, але ця гра поки що просто не коштує свічок (аудіо важить значно менше, ніж відео). Тому в нас паралельно кодується лише відео, а аудіодоріжка обробляється повністю.
Результати
Завдяки паралельній обробці відео ми значно скоротили затримку між завантаженням відео до нас та його доступністю для користувачів. Наприклад, раніше створення кількох повноцінних версій різної якості для FullHD-фільму тривалістю півтори години могло піти дві години. Тепер все це триває 15 хвилин. Більш того, при паралельній обробці ми створюємо версію у високій роздільній здатності навіть швидше, ніж версію в низькій роздільній здатності при старому підході з проміжним результатом.
І ще дещо. При старому підході або не вистачало серверів, або вони простоювали без завдань. Паралельне кодування дозволяє підвищити частку утилізації заліза. Тепер наш кластер більш ніж із тисячі серверів постійно чимось зайнятий.
Насправді є ще куди прагнути. Наприклад, ми можемо суттєво заощадити час, якщо почнемо обробляти фрагменти відео ще до того, як воно до нас надійшло повністю. Як кажуть, далі – більше.
Напишіть у коментарях, про які завдання в галузі роботи з відео ви б хотіли прочитати.
Корисні посилання на досвід колег з індустрії
Джерело: habr.com