Следующая конференция HighLoad++ пройдет 6 и 7 апреля 2020 года в Санкт-Петербурге.
Подробности и билеты связь .
HighLoad++ Москва 2018. Зал «Дели + Калькутта».
8 ноября, 14:00. Тезисы и презентация .
Я работаю в команде ВКонтакте и занимаюсь разработкой системы видеотрансляций.
В докладе я поделюсь особенностями backend-разработки, как развивалась наша система и к каким техническим решениям мы пришли:
- как мы делали бэкенд видеотрансляций, и процесс эволюции как он есть;
- влияние бизнес- и эксплуатационных требований на архитектуру;
- «подожди» и «попробуй еще раз» не сработают;
- как самые простые задачи усложняются количеством пользователей;
- как уменьшить задержку без UDP;
- Проводим стресс-тесты 2 раза в день, или в чем нам помог Клевер.
Я расскажу вам о людях, которые нам стримят, о самих лайвах, о том, с каких платформ мы получаем видеопотоки и на какие их распространяем.
В конце я расскажу вам о текущей живой архитектуре, о ее ограничениях и возможностях, а также о том, как текущая архитектура пережила такой эффект, как «Клевер».
О прямых эфирах.
План отчета
- Сначала немного расскажу о самих прямых трансляциях и стримерах, которые присылают нам видеоконтент, который мы показываем другим зрителям.
- После этого немного сравню с видеозвонками и с самим видео.
Почему я это делаю? Если вы задумываетесь о том, чтобы сделать свой собственный сервис вещания, то наверняка вам хочется где-то схитрить, где-то сэкономить, где-то оптимизировать.
Здесь важно понимать, где мы можем сэкономить по сравнению с видео: где мы проигрываем, где мы выигрываем.
- Я также дам вам экскурс в историю.
Расскажу, как была спроектирована первая архитектура видеотрансляции.
Это можно даже назвать прототипом.
Тем не менее, это сработало, и если вы делаете свои трансляции, то можете даже на этом остановиться.
- После этого я расскажу, как формулировались требования к архитектуре и откуда они взялись.
Расскажу о том, как мы их реализовали и что получилось в итоге.
Могу сказать, что та версия архитектуры, которая существует сейчас, вероятно, была сделана где-то в 2014-2015 годах.
Он претерпел довольно существенный тюнинг, но все основы остались прежними.
- После этого поговорим о масштабировании и балансировке.
Это важно, поскольку хорошая архитектура должна обеспечивать горизонтальное масштабирование и быть достаточно устойчивой при работе с большим количеством зрителей и большим количеством потоков.
- Я расскажу вам, какие протоколы мы используем.
У нас достаточно небольшой набор протоколов как для приема, так и для доставки видео.
Я расскажу вам, почему мы выбрали именно их.
- Давайте обсудим показатели качества и то, как мы следим за трансляциями.
Это важно для работы любой системы.
- Как я уже сказал, я также расскажу о том, как текущая архитектура пережила рост Clover и насколько хорошо она с этим справилась.
Немного о прямых эфирах и стримерах
Все службы вещания выглядят примерно так:
У нас есть какой-то стример, он нам присылает RTMP-поток, и мы показываем его зрителям — ничего удивительного, ничего сверхъестественного.
Откуда видеопоток? Значимым источником трафика для нас является наше мобильное приложение VKlife. Что в этом хорошего? В нем мы можем полностью контролировать, как мы кодируем видео.
Мы можем выполнить множество оптимизаций на стороне клиента, чтобы потом показывать его нашим зрителям с минимальными задержками.
Из минусов: мобильные приложения работают поверх сетей.
Это может быть 3G. В любом случае это почти всегда мобильные сети, что вносит некоторые лаги - необходимо дополнительно буферизовать данные на стороне приложения, чтобы поток шел максимально плавно.
Второй источник — стримеры с OBS, Wirecast или те, кто транслирует из других настольных приложений.
Это достаточно большая аудитория.
Иногда это семинары, иногда игровые стримы (их особенно много из таких приложений).
Из положительного: таких приложений немного, мы можем дать нашим стримерам хорошие рекомендации по их настройке.
Но при этом настроек очень много и они отправляют не совсем тот поток, который нам нужен.
Третья категория — поток RTMP с медиа-серверов.
Это могут быть совсем маленькие медиасерверы, то есть домашнего формата: человек транслирует вид улицы или что-то еще.
Или вполне серьезные трансляции от наших партнеров: там может быть что угодно, таких стримов не очень много, но в принципе они для нас очень важны.
Кто смотрит?
Опять же, это мобильное приложение – здесь все понятно.Самая большая проблема — задержка сети.
Плюс: мы можем настроить плеер - нам удобно, это хорошо, но не везде он работает на 100%.
Веб-плеер ВКонтакте.
Здесь тоже все просто — это обычный веб-плеер, который можно открыть и посмотреть.
ВКонтакте имеет достаточно большую аудиторию, много зрителей на трансляциях.
Некоторые трансляции висят у нас в разделе «Видео» — их там могут быть десятки тысяч (иногда без всякого пиара), особенно если это интересный контент. Соответственно, каналы достаточно большие для зрителей, использующих веб-плеер.
Поэтому трафика довольно много, в том числе и на одну трансляцию.
Третий — веб-плеер ВКонтакте на каком-то стороннем сайте.
Вы можете начать транслировать все, что захотите, и установить веб-плеер ВКонтакте на свой сайт. Вы можете стать нашим партнером, если у вас есть интересный контент: вы можете разместить его у себя, можете разместить у нас – как хотите.
Вы можете организовать свои трансляции таким образом, и все будет работать.
Сравнение с видеозвонками
В видеозвонках нам можно простить некоторые искажения изображения.В видеозвонках проще: мы можем существенно ухудшить изображение, но при этом должны поддерживать очень хорошую задержку.
Если будет большая задержка, услуга будет абсолютно неработоспособна.
В эфирах в этом смысле немного наоборот: мы должны поддерживать высокое качество изображения, но при этом можем увеличить задержку за счет множества факторов.
Например, плеер тем или иным образом буферизует свой поток (например, это может быть секунда или две, чтобы пережить деградацию сети), поэтому в большинстве случаев нет необходимости во секундных или миллисекундных задержках.
К этому можно стремиться, но с точки зрения продукта это не является обязательным условием.
С обычным видео ситуация прямо противоположная.
Нам нужно очень хорошее качество.
В этом случае желательно минимизировать размер видео, битрейт и соотношение качества, чтобы обеспечить наилучшее решение с минимальным потоком.
Плюс: мы не ограничены во времени: в момент загрузки видео у нас достаточно времени, чтобы оптимизировать видео, посмотреть, как его лучше сжать, что-то сделать, перетащить в кэши, если нужно - в целом все достаточно хорошо.
В живых событиях ситуация опять противоположная: времени на перекодирование у нас очень мало.
При этом возможностей по времени мало, а ожиданий от трансляции нет. Зритель нас простит, если у нас будет поддержка или качество будет не очень.
Самая первая версия
Это вполне ожидаемо:
На самом деле все немного иначе:
«Стример – медиасервер – уровень кэширования – зрители».
В принципе, эта версия позволяет достаточно сильно масштабироваться.
Я бы сказал, что оно уже должно выдержать десятки тысяч зрителей.
У нее есть и другие недостатки.
Например, если посмотреть на эту схему (предыдущий слайд), то видно, что она не является отказоустойчивой.
Приходится гадать с медиасервером, чтобы хорошо сбалансировать зрителей.
Мы не можем поставить много кэшей на каждый сервер — это просто дорого.
Итак, мы посмотрели, поняли, что все просто и понятно, какие-то возможности для масштабирования есть, но чего-то явно не хватает. И мы начали формулировать требования.
Требования к инфраструктуре
Что важно?- Количество трансляций.
Мы должны вести тысячи, а может быть, даже десятки тысяч передач.
При этом количество зрителей одной трансляции может быть достаточно большим (на данный момент должно сохраняться до миллиона).
Общее количество зрителей также довольно велико (десятки, сотни тысяч).
- Отказоустойчивость.
Отказоустойчивость существует с двух сторон: во-первых, отказ принимающей стороны (точки, где мы получаем видеопоток) не должен сильно влиять на трансляцию; во-вторых, сбой со стороны дистрибьютора — сбой одного из серверов со стороны, с которой мы раздаем видеопоток, также не должен влиять на наши трансляции.
- Доставка в регионы.
Тоже важный момент! Глупо весь видеоконтент из Питера или Москвы тащить в какой-нибудь Новосибирск, Екатеринбург или даже из Питера в Москву.
Это не очень хорошо, потому что задержка в сети будет большая - будут лаги, все будет лагать, а это нехорошо.
Поэтому наша инфраструктура должна учитывать, что мы доставляем контент в регионы.
- Простота использования и мониторинга.
Важное имущество.
Поскольку система большая и зрителей много, важно своевременно отправлять оповещения администраторам в случае возникновения каких-либо проблем, включая мониторинг продуктовых и технических показателей.
Как сейчас выглядит инфраструктура вещания?
В результате мы пришли к достаточно простой, но эффективной инфраструктуре.
- Это стример, которому дана ссылка на точку входа (это ресиверы, их несколько).
Стример запускает поток RTMP, который достигает получателя.
В получателе происходит некоторая проверка и пересылка на медиасерверы.
- Получатель выбирает, на какой медиасервер отправить поток, часто балансируя его на основе входящего трафика, нагрузки и доступности сервера.
Он выбрал сервер и направил туда медиапоток.
Задача сервера, с одной стороны, проста и понятна, с другой – сложна: необходимо, во-первых, провести транскодирование (т.е.
преобразовать видеопоток в несколько разрешений для доставки); во-вторых, его нужно упаковать в необходимый формат.
- С медиасерверов мы попадаем на уровень кэширования.
Это первый уровень кэширования — он не очень большой, но очень важный.
На этом уровне мы кэшируем практически все имеющиеся у нас видеопотоки и распределяем их дальше.
Это не очень большое количество серверов, а большой объем оперативной памяти или быстрых дисков (фактически и того, и другого).
- Этот уровень защищает медиасерверы от перегрузки практически в любом случае, независимо от количества зрителей или серверов распространения (граничных серверов).
Медиасерверы не будут перегружены отключениями или раздачами.
Они защищены достаточно надежно!
- Последний уровень кэширования — это Edge-серверы, которые уже расположены непосредственно в регионах, в точках доставки.
Здесь все просто: они не сильно кешируют трафик, их задача — просто отдать его зрителю.
Интересно? Балансировка! В этой схеме мы выбираем балансировку и пытаемся отправлять зрителей на каждый пограничный сервер, которые смотрят один и тот же поток.
Здесь очень важна локальность кэша, поскольку пограничных серверов может быть много; и если мы не будем соблюдать как временность, так и локальность кеша с точки зрения потока, то мы перегрузим внутренний слой.
Мы бы тоже этого не хотели.
Поэтому балансируем так: выбираем определенный Edge-сервер для региона, в который отправляем зрителей, и отправляем до тех пор, пока не начнем понимать, что произошло какое-то наполнение и стоит отправить на другой сервер.
Схема проста и работает очень надежно.
Естественно, для разных потоков вы выбираете разную последовательность пограничных серверов (последовательность, в которой мы отправляем зрителей).
Соответственно, балансировка работает достаточно просто.
Мы также даем клиенту ссылку на доступный пограничный сервер.
Это сделано для того, чтобы в случае сбоя пограничного сервера мы могли перенаправить зрителя на другой.
То есть, когда зритель смотрит трансляцию, он каждые несколько секунд получает ссылку на нужный сервер.
Если он понимает, что ссылка должна быть другая, он переключается (плеер переключается) и продолжает смотреть трансляцию с другого сервера.
Еще одна важная роль пограничных серверов — защита контента.
Вся защита контента, по сути, происходит там.
Для этого мы добавили собственный модуль nginx. Это чем-то похоже на Security Link.
Масштабирование и балансировка
- Масштабирование по количеству потоков.
Понятно, что в этой архитектуре мы очень хорошо масштабируемся: мы легко можем добавить медиасерверы, ресиверы и проблем у нас не будет. С точки зрения распространения контента мы можем легко масштабировать пограничные серверы до тех пор, пока не достигнем пропускной способности внутреннего кэширования.
Но сделать это довольно сложно.
Масштабирование по общему количеству зрителей.
Здесь тоже все понятно.
Мы не боимся, что зрителей потоков много - мы уважаем локальность кеширования, поэтому один, два или три зрителя на поток - легко, сто - легко, тысячи, десятки, сотни тысяч тоже легко! В случае чего добавляем сервер для потока и начинаем масштабироваться дальше.
- Масштабирование по количеству зрителей за трансляцию.
Здесь сложнее, потому что если мы начнем отправлять тот же сервер, а потом начнем вещать, то может случиться что-то не очень хорошее: сервер будет какое-то время перегружен.
Для этого мы иногда включаем режим (в случае популярной трансляции) выдачи не одного сервера, а сразу нескольких — либо случайным образом, либо по трафику.
Или, если сервис перегружен, новый сервис придет со ссылкой, и зритель переключится на другой пограничный сервер.
- После масштабирования можно сосредоточиться на качестве, чем мы и занимаемся в последнее время, поскольку масштабирование работает хорошо.
Какие протоколы мы использовали?
Одним из наших основных протоколов был RTMP (не только для ввода, но и для распространения контента).Основное преимущество – низкая задержка.
Это может быть полсекунды, секунда, две секунды.
На этом преимущества, собственно, и заканчиваются.
Этот потоковый протокол сложно отслеживать — он в каком-то смысле закрыт, несмотря на то, что есть спецификация.
Флэш-плеер больше не работает (фактически «уже готово»).
Поддержка нужна на уровне CDN — для корректной передачи потока нужны специальные модули nginx или собственное ПО.
С мобильными клиентами также есть некоторые сложности.
Поддержка «из коробки» в мобильных клиентах очень плохая — нужны специальные модификации, и все это очень сложно.
Второй протокол, который мы использовали, — HLS. Выглядит это довольно просто: это текстовый файл, так называемый индексный файл.
Он содержит ссылки на индексные файлы с различным разрешением, а сами файлы содержат ссылки на медиасегменты.
Что в этом хорошего? Это очень просто, несмотря на то, что оно немного старое.
Он позволяет вам использовать CDN, а это означает, что вам нужен только nginx для обслуживания протокола HLS. Это понятно с точки зрения мониторинга.
Вот его преимущества:
- простота использования — nginx в качестве прокси-сервера;
- легко отслеживать и снимать метрики (мониторить нужно только примерно то же, что вы отслеживаете на своем сайте);
- Сейчас этот протокол у нас основной для доставки контента.
- высокая задержка.
Задержка в HLS фактически встроена в сам протокол; так как требуется длительное время буферизации, то плеер вынужден ждать как минимум пока загрузится один чанк, и по-хорошему он должен ждать пока загрузятся два чанка (два медиасегмента), иначе в случае лага клиент будет имеют нагрузку на плеер, а это не очень хорошо сказывается на пользовательском опыте.
Второй момент, дающий задержку в HLS, — это кеширование.
Список воспроизведения кэшируется на внутреннем уровне и на пограничных серверах.
Даже если мы кешируем, условно говоря, на секунду или полсекунды, то это примерно плюс 2-3 секунды задержки.
Итого от 12 до 18 секунд – это не очень приятно, явно могло быть и лучше.
Улучшение ЗОЖ
Помня об этих мыслях, мы начали улучшать HLS. Мы улучшили его довольно простым способом: приведем последний, даже еще не записанный, медиа-отрезок плейлиста чуть раньше.То есть, как только мы начали писать последний медиасегмент, мы сразу же анонсируем его в плейлисте.
Что происходит в этот момент?.
Уменьшено время буферизации у игроков.
Плеер считает, что уже всё скачал, и спокойно начинает скачивать нужные сегменты.
Мы немного «обмазываем» плеер таким образом, но если мы будем следить за «стебельками» (загрузками в плеере) ну нас это не пугает — мы можем заранее перестать отдавать отрезок, и все вернется на круги своя .
Второй момент: в общей сложности мы выигрываем около 5-8 секунд. Откуда они? Время этого сегмента составляет от 2 до 4 секунд на каждый сегмент плюс время на кэширование плейлиста (это еще 2-3 секунды).
Наша задержка сокращается, и значительно.
Задержка сокращается с 12-15 секунд до 5-7. Чем еще хорош этот подход? Это на самом деле бесплатно! Нам просто нужно проверить, совместимы ли игроки с таким подходом.
Несовместимые файлы мы отправляем на старые URL-адреса, а на новые URL-адреса мы отправляем совместимые проигрыватели.
Нам не нужно обновлять старые клиенты, которые это поддерживают, что тоже важно.
На самом деле нам не нужно модифицировать или выпускать плееры в мобильных клиентах.
Нам не нужно разрабатывать веб-плеер.
Это выглядит довольно хорошо! 
Минусом является необходимость контроля входящего видеопотока.
В случае с мобильным клиентом мы можем сделать это довольно легко (когда поток идёт от мобильного клиента), а можем перекодировать его в обязательном порядке, так как плеер должен знать, сколько времени занимает один медиасегмент. И поскольку мы объявляем об этом еще до того, как он будет записан, нам нужно знать, сколько времени займет его запись.
Метрики качества
Вот как мы улучшили HLS. Теперь хочу рассказать, как мы отслеживаем и какие метрики качества берём:
Одним из основных показателей качества является время начала.
Идеально, когда перед трансляцией пролистываешь мобильный клиент, нажимаешь кнопку, и она сразу начинается.
В идеале оно бы запускалось до нажатия кнопки, но, к сожалению, только при нажатии.
Второй момент – задержка сигнала.
Мы считаем, что несколько секунд – это очень хорошо, 10 секунд – терпимо, 20–30 секунд – очень плохо.
Почему это важно? Например, для концертов и каких-то массовых мероприятий это абсолютно неважная метрика, обратной связи нет; Мы просто показываем поток — лучше не лагать, чем иметь небольшую задержку.
А для стрима, где идет какая-то конференция или человек что-то рассказывает и ему задают вопросы, это начинает иметь значение, потому что в комментариях задают много вопросов и хочется, чтобы зрители получили обратную связь уже возможный.
Еще одним важным показателем является буферизация и задержки.
На самом деле эта метрика важна не столько с точки зрения клиента и качества, сколько с позиции того, насколько мы можем «настроить» доставку HLS, насколько мы можем выжать данные из наших серверов.
Поэтому мы отслеживаем как среднее время буферизации у игроков, так и у «ставов».
Выбор качества в плеерах понятен: неожиданные изменения всегда раздражают. Соответственно, это тоже важный показатель.
Мониторинг
У нас много метрик мониторинга, но здесь я выбрал те метрики, которые всегда срабатывают, если что-то пойдет не так:
- Во-первых, это количество онлайн-трансляций.
Как только что-то идет не так, это число сразу падает. Иногда сильно, иногда нет, но в случае какой-либо ошибки или проблемы на серверах мы замечаем это моментально (десятки секунд, минуты – довольно быстро).
- Входящий/исходящий трафик также является четким показателем.
Причем входящая, пожалуй, более стабильна, так как исходящая зависит от популярности трансляции, и здесь не всегда можно заранее сказать, какое событие будет популярно.
Поэтому в основном входящий трафик.
- Время ответа пограничного сервера.
Четкая метрика, которая весьма важна для администрирования и эксплуатации, поскольку проблемы на пограничных серверах сразу же проявляются в случае возникновения каких-либо проблем.
Что такое клевер и как мы справились с его ростом?
Теперь расскажу, как мы справились с таким приложением, как «Плеер», когда использовали нашу инфраструктуру для трансляции видеопотока с вопросами и ответами.«Клевер» — это онлайн-игра-викторина.
Ведущий что-то говорит, спрашивает: возникают вопросы – вы отвечаете.
12 вопросов, 10 минут игры, в конце какой-то приз.
Что в этом такого сложного? Это рост!
Справа этот график: 
Пик [на графике] — это нагрузка на серверы в API-части в момент запуска Clover. В остальное время обычное вещание.
Это нельзя приравнять к количеству зрителей.
Возможно, дело в количестве запросов и нагрузке.
Это тяжело: за 5 минут к нам на пике пришло миллион зрителей.
Начинают смотреть трансляцию, регистрируются, выполняют какие-то действия, запрашивают видео.
Казалось бы, очень простая игра, но происходит это за очень короткий промежуток времени (все действия, включая финальную игру) - это дает достаточно высокая нагрузка.
С какими вопросами и трудностями мы столкнулись?
- Быстрый рост. Иногда это было +50% в неделю.
Если, например, в среду у вас 200 тысяч человек, то в субботу или воскресенье их может быть уже 300. Это очень много! Начинают проявляться проблемы, которых раньше не было видно.
- Причем проходит 2 раза в день.
Времени на решение этих проблем очень мало.
В утренней передаче обычно меньше людей, а вечером больше.
По сути, вам предстоит утренний эфир, чтобы отладить, понять, что может пойти не так или начинает идти не так, а к вечернему эфиру у вас должно быть решение проблемы, иначе будет очень неприятно.
На исследование и устранение проблем у нас ушло около 12 часов.
Кажется, что это много времени, но на самом деле это не так, потому что нужно тестировать, обкатывать, пробовать подходы на каком-то другом эфире и нужно быть уверенным, что ты решил эту проблему, потому что.
- Если вы потерпите неудачу в течение этого времени, вы, скорее всего, упадете в следующий раз.
Все проблемы начинают проявляться, например, на 200-300 тысячах, а это приводит к очень неприятным последствиям на 400-500.
- Из-за того, что трансляция всего одна, а зрителей много, в случае лагов на сервере трафик моментально взлетает в 3-5 раз.
Как это произошло? Игрок «сходит с ума», он получает новый плейлист, в котором есть сегменты, которые он еще не видел и которые не скачал, и начинает их скачивать.
Он их скачивает в три раза быстрее (хочет скачать сразу в 3 раза больше, чтобы немного буферизоваться), и при этом через какое-то время еще может переключить качество, что приведет к увеличению еще в 3-5 раз.
Как с этим справиться? Первое — ухудшение качества, второе — делать экспоненциальный бэкофф на клиенте, иначе в случае проблем его просто не поднимешь.
Как работает экспоненциальный откат: попробовал и сломалось, в следующий раз нужно попробовать через 2 секунды, потом через 4, через 8. Тогда вы достаточно быстро вернетесь в случае возникновения проблемы и не будете перегружать свои бэкенд-серверы.
Что показал нам рост Clover?
- Во-первых, в этом проекте очень хорошо работают масштабирование и балансировка.
Если вы делаете большую систему вещания, я рекомендую этот подход — он работает очень хорошо.
- Мы проводили тестирование «в фоновом режиме».
Каждый раз, когда пользователь открывает какую-либо трансляцию, мы создаем фейковую, на которую отправляем те же запросы, что и в Clover. В этом случае мы можем быть уверены, что наши решения, во-первых, сработали в случае возникновения проблем, а во-вторых, что не возникло новых проблем.
- Мы создали метрику, которую обычно не отслеживаем и не смотрим — это количество пользователей, у которых не было «становлений» в течение пяти минут. Это интересная метрика специально для Clover. Если у вас обычная трансляция, то вроде бы не важно, сколько пользователей испытывают проблемы.
То есть в среднем это работает. 10% "стало" - это нормально, 10% "стало" на 100 потоков - тоже нормально.
- Для «Кловера» это важно, потому что в видеопотоке есть вопросы, и даже один «старт» или одна задержка вызывает большой негатив.
В обычном эфире такого не происходит - там не такая негативная реакция из-за одного лага.
Вот если у пользователя 100 лагов – это неприятно, но 1 лаг в течение 15 минут – это не такой уж негатив.
- Взаимодействие в команде значительно улучшилось.
В Clover приняли участие команды сетевой инфраструктуры, администрирования, бэкенда и продуктов.
Я бы сказал, что взаимодействие стало существенно более продуктивным, как бы странно это ни звучало.
- Улучшенные инструменты диагностики.
Фактически, в рамках видеотрансляций мы научились выявлять проблемы по мере их возникновения и даже в каком-то смысле предвидеть любые проблемы, которые у нас возникали.
На заключительном этапе мы не ухудшили ни качество, ни задержку, ни другие характеристики.
- Улучшены навыки нагрузочного тестирования.
Спасибо нашим тестерам - они очень многое сделали, чтобы помочь нам разобраться в любых вопросах.
- На пике «Клевера» у нас было 1 миллион зрителей за трансляцию и мы отдавали около терабита видеопотока за трансляцию.
Может быть, не миллион, а чуть меньше.
Это довольно много для одной трансляции.
Вместо проблем возникли интересные ситуации с балансировкой, а также балансировкой других потоков.
Однако архитектура поработала на славу.
Каков результат?
Нас полностью устраивает архитектура, и я могу с уверенностью ее рекомендовать.HLS останется нашим основным протоколом, по крайней мере, для веб-сайта, и, по крайней мере, резервным протоколом для всего остального.
Возможно, мы перейдём на MPEG-DASH.
Мы отказались от RTMP. Несмотря на то, что он дает меньшую задержку, мы решили, что настроим HLS. Возможно, в качестве альтернативы рассмотрите другие способы доставки, включая DASH. 
Улучшим входящую балансировку.
Также мы хотим создать бесшовную отказоустойчивость входящей балансировки, чтобы в случае проблем на одном из медиасерверов переключение было совершенно незаметно для клиента.
Возможно, мы разработаем средства доставки от пограничных серверов к клиенту.
Скорее всего это будет какой-то UDP. О каком из них мы сейчас думаем и находимся на стадии исследования.
Собственно, это все.
Спасибо всем!
Вопросы
Вопрос из зала (далее – А): – Большое спасибо за доклад! Только что выступал спикер из Одноклассников, и он сказал, что им пришлось переписать стример, шифратор, кодировщик.Вы используете такие решения или используете стоковые, которые есть на рынке (типа Harmonic и т.п.
)? 
МИСТЕР: – Сейчас мы используем сторонние решения.
Из open source решений, которые мы использовали, у нас был nginx, RTMP-модуль (давно).
С одной стороны, это нас порадовало, потому что работало и было довольно просто.
Мы очень долго с ним боролись, чтобы оно работало стабильно.
Сейчас он переходит с Nginx-RTMP на собственное решение.
Сейчас думаем о транскодере.
Ресивер имеет Теги: #Хостинг #ИТ-инфраструктура #Конференции #Большие данные #потоковое видео
-
Вирусы. Вирусы? Вирусы! Часть 1
19 Oct, 24 -
Выпущен Linux Mint 12 «Lisa» Rc
19 Oct, 24 -
Microsoft Search Server 2010 Экспресс
19 Oct, 24 -
Мини-Погружение В Изучение Языка
19 Oct, 24 -
Что Такое Центр Данных Google Рекламы
19 Oct, 24 -
Первые Шаги В Rust
19 Oct, 24 -
Темный Лорд?
19 Oct, 24
