В соцсетях она чаще всего используется в виде мема «как вызывают дьявола в городе Ленина». Разгадка простая и ни ритуалов, ни коммунистической символики тут нет. Вот что написано под ней мелким шрифтом:
«Протоптанная прохожими — пятиконечная звезда на пл. Урицкого. Снято с верхушки шпиля Адмиралтейской иглы. Наш фотограф пять раз поднимался на шпиль, так как дорожки, образующие звезду, четко обозначаются только в «талые» дни, отличающиеся в Ленинграде большими туманами, не дающими возможности произвести съемку».
На самом деле, это специально устроенные в грубой мостовой дорожки, соединяющие напрямую все выходы с площади. Удобное, эффективное решение.
В случае со стримингом видео в интернет, картинка тоже состоит из множества дорожек. Но дороги эти складываются в некий мрачный ритуал:
Это скриншот из нашей внутренней документации — постоянно обновляющаяся схема того, как у нас устроен стриминг, нарисованная в Miro. Растрелли и Росси вращаются как вентиляторы: кажется, что пройти по этим дорожкам до конца могут только избранные.
На самом деле, эта схема построена на железной логике. Благодаря четкой работы этой схеме на конференциях JUG Ru Group мы собираемся обеспечивать качественную и стабильную трансляцию. Статья, которую вы сейчас читаете, будет полезна не только любопытствующим хаброжителям, но и может являться своеобразным шаблоном для других организаторов конференций.
Алексей Федоров уже рассказывал в своём Telegram-канале что конференция глазами организаторов — это инженерная задача по проектированию и построению некоторой распределенной системы. Узлы этой системы — это акторы (спикеры, члены ПК, ведущие, эксперты, участники и спонсоры), оборудование (свет, звук, картинка, стриминг, транскодеры, сайты, чаты) и бизнес-процессы.
Пайплайн стриминга — это основная часть программного-аппаратного комплекса, лежащего в центре этой системы.
Он выполняет цепочку из нескольких основных задач:
- Получить звук и видео от докладчика;
- Передать его на стриминговый сервис в интернете;
- Забрать со стримингового сервиса и отобразить в видеоплеере;
Основные блоки обязаны работать, иначе никакой конференции не случится. Они работают благодаря дублированию подсистем, резервированию, буферизации и другим хорошим практикам построения распределенных систем.
Участник конференции видит только верхнюю часть айсберга — видеоплеер в браузере, описание доклада и прочие составляющие конференционного сайта. Точнее, сложного веб-приложения, но вот об этом участнику задумываться уже не обязательно. О том, как устроен браузерный фронтенд, плеер и всё в таком духе — мы постараемся рассказать в отдельной статье. А здесь поговорим о том, что скрыто глубоко под водой.
Видео может приходить из нескольких основных источников:
- Заранее записанное видео
- Студия в офисе
- Соединение с докладчиком на удаленке
- Студия у спикера
Предзаписанные ролики
первый уровень боли
Суть конференции — в интерактивности и уникальности. Если бы на «конференции» не было интерактивных элементов и уникального контента, проще было бы пойти смотреть древние баяны на YouTube.
Тем не менее, часть вещей стоит записать заранее. Например, все мы знаем примеры, когда на конференциях запороли открытие или какое-то вступительное слово, и это испортило впечатление от всего остального. Записать имеет смысл не только вступительное слово, но и всевозможные интервью со спонсорами, демонстрации, и тому подобное.
Подумайте: не сломается то, чего нет. (Этот же принцип лежит в основе функционального программирования). Если вы не будете записывать вступительное слово вживую, а пустите в записи — это гарантия успеха.
Загруженные файлы проходят упрощенный монтаж и кодирование и загружаются в Amazon.
Со стороны Amazon это выглядит так: файлы обрабатываются очередью задач на перекодирование видео в нужные форматы, после чего раскладываются в нужные места на S3. Это чисто техническая задача, которую нужно один раз правильно настроить. Об Amazon мы ещё поговорим ниже. Если вам интересно, прямо сейчас можно пройти вот по этой ссылке. В статье примерно описан пайплайн и даже видео с докладом есть.
Всё, простая часть заканчивается, дальше начинается боль.
Собственная студия
второй уровень боли
Если записать доклад в хорошо контролируемой среде, например, в собственном офисе — не придётся связываться с доставкой видео по интернету.
О том, как строить студии в офисе, мы написали отдельную статью. Решение хорошее, но применять его можно не всегда: большинство докладчиков находится на другом конце света.
Кроме того, собственная студия — решение далеко не бесплатное:
- Студия занимает офисное помещение целиком, аренда офиса стоит денег;
- Это помещение нужно постоянно проветривать и вообще заботиться о нем;
- Нужно купить кучу дорогого оборудования, включая видеокамеру и свет;
- Нужно работать с дополнительными людьми: ведущими, докладчиками, операторами;
- Часть из этих людей нужно нанимать отдельно: например, с камерой может работать подрядчик;
- Нужны дополнительные координаторы для Zoom и средств удаленного управления (об этом ниже).
Когда люди в первый раз слышат о студии, реагирую вроде: «Да что там делать-то, взял камеру и снимаешь!». В реальности, это довольно долго, дорого и требует тестирования. Такое тестирование мы регулярно делаем, например, проводя выпуски шоу «Ошибка выжившего».
Докладчики на удаленке
третий уровень боли
Докладчик на удаленке — нестабильная и недоверенная часть системы. Интернет подобен океану, и жители интернета мчатся по волнам в утлых судёнышках в самый разгар шторма.
Первое правило интернета — не связываться с интернетом. Но все возможности уже исчерпаны: представьте, студии работают на полную, всё что можно предварительно записать — записано, что дальше? Всегда найдется докладчик, живущий на другом конце мира!
Ожидание:
- Мы запускаем какой-то заранее написанный, хорошо работающий, популярный софт для подключения докладчика к видеоконференции через интернет. Проводим конференцию. Расходимся. Профит.
Реальность:
- На рынке куча решений, но ничего не подходит к нашей задаче. Нужно найти и протестировать кучу разрозненных решений и собрать из них что-то разумное. Кирпичик за кирпичиком.
Сейчас мы используем следующие решения:
- Веб-камера и микрофон докладчика захватывается через vMixCall или Zoom;
- Слайды захватываются через Zoom;
- Резервный план в случае отключения голосовой связи через Zoom — Discord и Telegram;
- Резервный план в случае отключения слайдов через Zoom — средства удаленного управления вроде Chrome Remote Desktop.
От докладчика мы получаем изображение с его веб-камеры и звук. Докладчик получает от нас «толкбэк» — картинку того, как он выглядит в трансляции. Качеством вещания адаптивно управляет WebRTC, на основе которого работает vMixCall.
Важное отличие vMix Call от Zoom в том, что в нём можно точно мониторить все параметры соединения с докладчиком, и при необходимости — вмешаться. Например, если скорость интернет-соединения недопустимо понизилась, можно вручную снизить качество изображения, которое передается спикеру через толкбэк. При понижении качества исходящего видео, входящее видео (веб-камера спикера) станет передаваться лучше.
Отключение от Zoom — это не фатально. Мы постоянно проводим испытания, и уже были ситуации, когда зум отваливался, а докладчик спокойно продолжал общаться с ведущим, отвечая на вопросы слушателей пока его переподключали к трансляции. То есть если к участнику видео попадает через разные независимые каналы — это хорошая идея с точки зрения надёжности, хотя и требует от инженеров дополнительной работы.
Демонстрация слайдов: Zoom
Многие конференции и митапы захватывают слайды с помощью Zoom. К сожалению, качество отображения таких слайдов напрямую зависит от качества соединения. Если это какой-то житель с другого края мира, подключенный по медленной линии ADSL, качество может быть крайне убогим.
Поэтому у нас на конференциях слайды не транслируются через Zoom. Докладчик высылает их заранее и они загружаются на сервер, стоящий в аппаратном помещении. В ходе доклада они транслируются прямо с этого сервера. Под «сервером» понимается ноутбук, на котором установлен весь необходимый софт для демонстрации слайдов. Это Windows-ноутбук с PowerPoint или MacBook с Apple Keynote на борту.
Спикер может самостоятельно листать слайды, подключившись к этому серверу через Zoom в режиме удаленного управления. Чтобы нажимать кнопки «вперед» и «назад» не нужного какого-то особо хорошего качества связи.
Это довольно отказоустойчивый план. Например, если сервер со слайдами сломаемся, то у нас всегда есть несколько резервных ноутбуков, которые подменят его моментально, и такую накладку даже не заметят участники трансляции. Если не заработает Zoom, его всегда можно заменить на Chrome Remote Desktop, VNC, или любое другое средство удаленного управления. Можно даже купить полюбившийся всем TeamViewer, но у него очень дорогие коммерческие лицензии.
Представим худшее — во всём Питере отключили электроэнергию. В наш Питерский офис прилетела ядерная ракета. Remote Desktop перестал работать по каким-то фундаментальным причинам. Но и тут у нас есть запасной вариант — мы можем продолжить трансляцию через аппаратную, расположенную в Москве. Делаем созвон в Zoom, в котором участвуют сразу три источника: докладчик и обе аппаратных в Москве и Питере. Докладчик транслирует слайды со своего компьютера. Если один из городов отключается — остается еще как минимум один, на который можно быстро переключиться.
Похожий прием можно использовать, если докладчик хочет провести какую-то демонстрацию со своего экрана или организовать совместный доклад на несколько человек.
Конечно, при этом слайды становятся из идеально чётких — обычными, немного мыльными, к которым все привыкли. Но согласитесь, это гораздо лучше, чем остаться без доклада вообще.
Если же между нашим штабом и докладчиком потеряется сетевая связность, и докладчик будет на другом конце мира, где-нибудь в США, мы подключим его голосом по телефону. А слайды будем переключать слайды по его прямой команде. **Всегда должен быть резервный план**.
Докладчик и его собственная студия
четвертый уровень боли, максимальный
Если предыдущий пример с докладчиком на удаленке был похож на корабль посреди шторма, то докладчик с собственной студией — это корабль, на котором взбунтовалась команда.
Как это выглядит?
Представьте, что у докладчика свой собственный ноутбук с настроенной программой Open Broadcaster — самым популярным бесплатным решением для стриминга. С этого компьютера он может транслировать свой экран, делать лайвкодинг, показывать любые демонстрационные видео, сам изменять планы, и так далее.
Дальше он подключает свой OBS к нашему серверу по протоколу RTMP и пересылает всё захваченное видео. Это видео проходит упрощённый монтаж и напрямую отправляется на стриминг в Amazon.
Недоверенной средой здесь является не только интернет, но и весь программно-аппаратный комплекс на стороне докладчика.
Для докладчика возможность самостоятельно контролировать ситуацию может звучать хорошо. Но мы в этом случае очень ограничены в способности помочь докладчику с проблемами, если таковые произойдут. Что делать, если OBS начал падать? Что, если компьютер докладчика стал мистическим образом тормозить при попытке отобразить видеоролик? Разнообразных проблем могут быть десятки, сотни.
Могут быть ситуации, когда схема трансляции на стороне докладчика просто несовместима с нашей хитрой системой монтажа. Так случилось с Себастианом Дашнером, который «перехитрил» нас, запустив у себя не один компьютер, а целых два. На одном он работал, а второй использовал как монтажную станцию для OBS. Пришлось выводить его в эфир через Zoom, минуя красивую схему с RTMP-шлюзом.
Всегда должен быть резервный план. В данном случае, стоит заранее договориться с докладчиком, что вы сделаете, если трансляция из его OBS почему-то прекратится. Самый логичный способ — переключиться на «обычный» способ трансляции: соединиться через Zoom и продолжать доклад в обычном режиме. Для этого докладчик должен быть готов к этому «обычному режиму» — то есть, у него должны быть какие-то слайды, и он должен представлять, что рассказывать вместо демонстрации экрана.
Аппаратное помещение и студия
Всё видео, захваченное из всевозможных источников отправляется в аппаратную. Здесь видео монтируется: в трансляцию отбираются правильные планы, кадрируются картинки с веб-камер, к видео дорисовывается какая-то графика вроде рамочек и логотипов, и так далее. После монтажа видео уходит на стриминг в Amazon.
Об устройстве аппаратной мы подробно писали в отдельной статье, а здесь хочется рассказать, чего всё это стоит вместе с оборудованием студии.
Чтобы рассчитать стоимость, давайте посмотрим, что нам вообще нужно. Обычно в аппаратной стоит несколько ноутбуков для Zoom и средств удаленного управления слайдами, и станция монтажа.
Как подключаются к аппаратной?
- Если докладчик подключается через Zoom и средства удаленного управления, связь идёт через открытый интернет;
- Для внешних источников типа OBS на стороне докладчика, где-то в сетевой инфраструктуре установлен RTMP-шлюз, связь с которым тоже идёт через открытый интернет;
- Со студией, расположенной в офисе, связь проходит по проводам напрямую.
На вот этой схеме показаны все связи внутри аппаратной:
Аббревиатура «ПТС» расшифровывается как «передвижная телевизионная станция». В реальности, это достаточно мощный компьютер, чтобы выполнять функции станции монтажа.
В любой момент времени нам нужно минимум две ПТС. Пока одна из них транслирует доклад — на второй идёт подготовка к следующему событию. Например, имеет смысл поделить ПТС так: с одной транслируются только доклады, а со второй — только спонсорские интервью и другие специальные штуки.
На случай отключения электричества нужен блок бесперебойного питания. Одна батарея выдержит минут 10, поэтому батарей нужно закупить много.
Теперь, шок контент. Вот сколько это стоит:
- 14 компьютеров для ПТС, для каждого нужно иметь:
- Системный блок с видеокартой с RTX 2060: около 130 тысяч
- Приличный 27-дюймовый монитор: 30 тысяч
- Карты видеозахвата в 4K: 30 тысяч
- MIDI-контроллеры, клавиатуры и мыши: 10 тысяч рублей комплект
- Нормальные ноутбуки Asus: 10 штук по 70 тысяч рублей;
- Слабые ноутбуки: 5 штук по 30 тысяч рублей;
- Комплекты света для студии: 4 штуки по 23 тысячи рублей;
- Телевизоры: 8 штук по 80 тысяч рублей;
- Стенды для телевизоров: 4 стенда по 20 тысяч рублей;
- Устройство бесперебойного питания и батареи к нему: 550 тысяч рублей;
Если сложить все цифры, то получится более пяти миллионов рублей на минимально необходимое железо.
Если вам вдруг интересно, куда же организаторы тратят огромные деньги, заработанные на билетах, то вот один из примеров.
Наверное, кого-то эти цифры могут повергнуть в шок, но поверьте — это только небольшая часть истории. Например, мы совершенно не учли усилия и зарплаты людей, которые будут эксплуатировать это железо, аренду площадей, и всё в таком духе.
Стриминг в Amazon
«CDN» расшифровывается как «Content Delivery Network». Это географически распределённая сетевая инфраструктура, позволяющая оптимизировать доставку и дистрибуцию контента пользователям Интернета. Прочитать о CDN подробнее можно прямо на Хабре.
Иначе говоря, где-то рядом с вами всегда находится сервер, который сохраняет и быстро-быстро отдаёт все те картинки и видео, которые вы видите в браузере. Если бы вы каждый раз скачивали все картинки с сервера в штате Вирджиния, где расположены основные сервера Amazon, то половина сайтов загружалась бы в два раза дольше. Или не загружалась бы вообще — потому, что веб-сервер упал от нагрузки.
Видео на онлайн-конференции нужно раздавать с помощью CDN. Но если студию или аппаратную можно собрать своими руками, пусть и за миллионы рублей, то собственные CDN по всему миру построить не удастся никак.
Даже если бы нам хотелось построить всего один-единственный сервер, раздающий видео в Москве или Питере, это было бы очень неприятно. Фишка таких систем — в максимальной доступности и отказоустойчивости под нагрузкой. Чем больше нагрузка, тем больше сложных инженерных проблем, требующих высокой квалификации. Что будет, если между нашим сервером и кем-то в Хабаровске пропадёт сетевая связность? Что будет, если контейнер с видеосервером начнёт падать пять раз в секунду по неясной причине? Проще заплатить денег кому-то, кто уже умеет это делать хорошо.
Мы изучили несколько разных решений для стриминга видео и пока остановились на том, что предлагает Amazon.
Процесс выглядит следующим образом:
- Результат работы аппаратной — видеопотоки и предзаписанные видеофайлы.
- Видеопотоки мы отправляем по RTMP на сервера Amazon MediaLive;
- Файлы отправляются на сервера Amazon MediaConvert;
- Видео выгружается в хранилище — Amazon S3;
- И наконец, данные выгребаются из S3 и разлетаются по серверам сети CDN — Amazon CloudFront.
Очевидно, все сервисы стоят каких-то денег. Конкретная стоимость зависит от региона и объемов. В самом начале эти суммы не очень впечатляют, но когда складываются — это уже вполне прилично. Например, чем больше конференций ты провел, тем больше файлов нужно хранить.
К сожалению, сразу бросить файлы на CloudFront нельзя, вначале их нужно подготовить. Участникам с разным качеством интернет-соединения и разным размером экрана нужно видео в различном качестве.
AWS Elemental MediaConvert — это сервис перекодирования видеофайлов с возможностями на уровне взрослых вещательных компаний. Видеофайлы загружаются через веб-интерфейс или API и дальше сами перекодируются в любой нужный формат. Если ты забросил в MediaConvert файл, то вся ответственность за обеспечение кодирования уже не на тебе, а на Амазоне. Стоимости есть на официальном сайте.
AWS Elemental MediaLive — это примерно то же самое, но для видеопотоков. Идея в том, что ты транслируешь на MediaLive поток в самом максимальном качестве, которое у тебя имеется — а он из него генерирует сразу несколько вариантов, подходящих для разных устройств и скорости интернета.
Возможности этих сервисов выглядят круто, но и стоят они недешево. Например, при покупке сервиса транскодирования подразумевается, что они вполне могут сломаться. Если транскодер падает и перезапускается в облаке — на это тратится время, а участник конференции в это время ничего не видит или трансляция прерывается в плеере. Чтобы этого ужаса не произошло, нужно покупать сразу несколько транскодеров на один и тот же видеопоток.
Amazon Simple Storage Service (Amazon S3) — это сервис хранения данных. Заливать данные туда можно практически в неограниченных объемах. Вообще, S3 можно использовать как универсальное хранилище для чего угодно: можно раздавать файлы, можно анализировать большие данные, можно синхронизировать IoT-устройства, и так далее. В нашем случае, S3 нужен как промежуточное хранилище для всего, что отрендерили нам MediaLive и MediaConvert. Чтобы можно было передать видео на CDN, в настройках нужно указать соответствующий бакет в S3.
Что касается надёжности, то S3 обеспечивает надежность 99,999999999 % (здесь 11 девяток). Такая надёжность подходит даже для банков, а нам для видео подойдёт тем более. Можно сказать, это самая устойчивая часть во всей схеме — и устойчивость эта держится на деньгах, которые мы платим Амазону за каждый мегабайт.
Amazon CloudFront — универсальный CDN, который в том числе умеет отдавать и видео. Видео работает в России с довольно низкими задержками и высокой скоростью. Сервис CloudFront интегрирован с AWS, в том числе с S3 и Live-сервисами. Это выглядит как магия: ты настраиваешь несколько параметров в админке, и внезапно твоё видео начинает качественно раздаваться по всему миру.
Оплата за CloudFront происходит по факту использования — деньги начинают капать только если участники конференции действительно смотрят видео. Очень важно, что нам не нужно платить за трафик между S3 и CloudFront — трафик между внутренними сервисами в Amazon совершенно бесплатный. А вот если бы вместо S3 мы попытались использовать какое-то другое хранилище, это влетело бы в копеечку.
Ловим поток в видеоплеере
После того, как видео появилось на CloudFront, его можно забрать с помощью видеоплеера, встроенного в наш браузерный фронтенд (т.е. в сайт, который видят участники конференции).
К сожалению, не существует готовой платформы, которая принимала бы видео из CloudFront и превращала в настоящую онлайн-конференцию. Точней, есть Amazon Media Package, но всё равно дорабатывать напильником. Поэтому нам пришлось написать свою собственную конференционную платформу, включая собственный плеер на основе HLS.js.
Но это тема для совершенно другой статьи.
Итого
В этой статье мы поговорили о том, откуда берётся конференционное видео, и как оно появляется в интернете.
Захват видео, студии и аппаратные мы собираем сами. Транскодирование и доставку видео в CDN мы доверяем сервисам Amazon.
Делаем ли мы работу сами или доверяем подрядчикам, покупаем или арендуем оборудование — всё это огромные суммы, измеряемые многими миллионами рублей. Эти деньги берутся, в том числе, из стоимости билетов, которые приобретают участники.
У нас осталось пространство ещё на парочку статей: нужно рассказать, как устроен наш браузерный фронтенд и как устроены организаторские процессы.
Приходите на наши онлайн-конференции и посмотрите, как всё это работает!
Скоро состоится TechTrain 2020, участие в котором совершенно бесплатное. Подробней о нем можно прочитать на Хабре.
После него летом пройдут восемь больших онлайн-конференций:
- JPoint (Java)
- Heisenbug (тестирование)
- HolyJS (JavaScript)
- DotNext (.NET)
- C++ Russia (C++)
- DevOops (DevOps)
- Hydra (Distributed computing)
- Mobius (мобильная разработка)
Можно взять билет сразу на все летние онлайн-конференции (это выгодно), а можно пойти только на одну из них (это дешевле).
