В свете последних событий с замедлениями, блокировками и прочими «радостями» часто возникает вопрос, а где и как альтернативно размещать свои видео, да еще и чтобы все было максимально доступно для всех.
Кому это всё надо?
Подозреваю, что подавляющее кол-во людей попросту воспользуются альтернативными площадками вроде того же RuTube или VK или Kinescope. Другие воспользуются более простыми вариантами размещения видео. Но тем не менее, считаю, что в целом понимание того, как работает потоковое видео и как самостоятельно его «приготовить» лишним точно не будет. Более того, подавляющее большинство используемых вами сервисов использует ту же схему, о которой рассказано ниже. Да, со своими изменениями и доработками. Где-то встроили рекламу, где-то статистику просмотров. Но глобально сам принцип никуда не делся и едва ли что-то изменится в ближайшее время. Попутно в статье раскрою тему, почему VPN может крайне серьезно и негативно влиять на пользовательский опыт при просмотре ваших видео.
А пока можно посмотреть, как у меня получилось организовать свой видео-поток в плеере ниже.
В чем идея потокового видео?
Как уже описано выше, глобально сделать self-hosted видео довольно просто. Можно залить видео файл в хранилище любого сервиса позволяющего получить прямую ссылку на файл. Эту ссылку подключить к какому-либо известному вам Web-плееру (я использую Plyr) и всё. Задача решена.
Но такой подход практически уже нигде не используется по простой причине — это слишком медленно. Основная проблема такого подхода заключается в том, что клиенту, перед просмотром, необходимо предзагрузить файл. Это не большая проблема, если у клиента скоростной интернет, файл занимает 20 Мб и длительностью около 3-4х минут в качестве 720р и ниже.
А вот если речь заходит о выдаче клиенту видео длительностью час и более, а еще и в качестве FullHD (1080p) и выше, а вдруг еще и с частотой кадров 60-120, то такой файл будет занимать гигабайты. И даже с хорошим интернетом грузиться все это дело будет долго. И наш клиент даже промотать видео не сможет по той причине, что перемотка такого видео возможна только в рамках уже загруженной части. Если клиент перемотает ближе к завершению ролика, то он ничего не увидит, пока браузер (приложение) не скачает видео до этого момента. Примерно по этой причине многие не хотят загружать длинные видео в Telegram. Все же замечали, как долго происходит прогрузка видео и насколько это не удобно? Так вот Telegram как раз-таки использует прямые ссылки на файл.
Тем не менее крупные компании смогли решить задачу с раздачей видео клиентам без предзагрузки. К тому же им удалось реализовать выбор качества видео (отчасти это работает автоматически) и побочным эффектом получить некое подобие защиты. Потоковое видео хоть и можно скачать, но не так всё просто, во всяком случае в сравнении с видео по прямой ссылке.
Технология HLS
HLS (HTTP Live Streaming) — по сути технология потокового видео поверх обычного http-протокола. К слову, есть и другие, вроде rtmp-протокола. Поток с OBS-Studio на YouTube/Bizon/GetCourse передается как раз через rtmp, но это решение подходит не всюду, и в целом так и не появилось доступных, вменяемых клиентских проигрывателей, которые могли бы воспроизводить видео напрямую с RTMP. Последние такие попытки, насколько мне известно, закончились вместе с эпохой технологии Flash. В настоящее же время есть разного рода Web-плееры, но практически все они работают с HLS либо DASH (в целом очень похож на HSL, только чутка сложнее в реализации).
HTML5 страницы могут воспроизводить HLS практически без проблем. Достаточно встроить в Web-страницу тег <video> и указать настройки, откуда забирать поток.
Разбираемся как это всё работает.
Допустим у нас есть некий исходный видео-файл (SOURCE). Чтобы клиенты могли комфортно его просматривать, нам нужно выполнить ряд действий.
На первом этапе мы с исходного файла в разрешении 1080р создадим еще два ролика с меньшим разрешением (CONV 720p и 480p). Если же мы будем управлять еще и битрейтом, тогда мы сделаем и третий ролик, в качестве 1080р, но с пониженным относительно исходного ролика битрейтом. Но пока это хоть уже и меньшие, но все еще файлы.
Далее необходимо все эти файлы перекодировать на чанки.
Чанки это по сути части видео с некоторой фиксированной продолжительностью. Чем короче чанк (фрагмент видео) — тем быстрее видео будет загружаться. Но есть и другая зависимость. Чем короче чанк — тем их больше, что в целом негативно сказывается на скорости подгрузки видео и такие потоки крайне чувствительны к мощности клиентского устройства и еще более чувствительны к скорости доступа к информации в интернет (PING). Чем выше PING и короче чанк — тем сложнее клиенту просматривать видео. По сути, в целом вся задача потокового видео это подобрать оптимальный битрейт и длительность чанка, чтобы видео грузилось быстро при этом было менее подвержено к задержкам доступа.
При кодировании видео и дроблении на чанки попутно создается манифест (по сути это плейлист) в котором указан порядок следования фрагментов и их продолжительность.
В целом это практически финальный этап создания потокового видео. Каждый из этих манифестов (плейлистов) вполне может функционировать независимо. Однако для удобства создается т.н MASTER. Это также HLS манифест (но в этот раз, проще говоря, это плейлист с плейлистами) и именно этот манифест как правило браузер запрашивает самым первым. В этом файле указано, какие потоки доступны. После загрузки мастера плеер определяет количество потоков. Напомню, что каждый поток в данном случае идет со своим качеством (разрешение + битрейт), затем переключая эти потоки происходит выбор качества видео в плеере.
При перемотке видео в случайный диапазон времени плеер обращается к манифесту и определяет, какие чанки соответствуют запрошенному таймингу и передают нужные фрагменты на загрузку. А так как длина чанков как правило не превышает несколько секунд, а их размер пару тройку мегабайт, видео на стороне клиента загружается максимально быстро и более нет необходимости загружать все видео целиком для комфортной перемотки. А раздробленность видео создает некоторые сложности для скачивания видео, т.к необходимо скачать плейлист, сформировать ссылки для всех фрагментов. Затем все эти фрагменты скачать и каким-то образом склеить несколько десятков (а то и сотен) коротеньких видео в одно цельное. Так себе защита, однако тем не менее, для большинства «пиратов» этого достаточно.
Что не так с VPN?
Как описано выше, потоковое видео, по сути, не что иное, как плейлист с большим количеством фрагментов исходного ролика. При последовательном просмотре плеер планомерно скачивает один чанк за другим. За простым процессом скачивания на самом деле стоит ряд процессов:
- Установка соединения
- https хэндшейк
- Передача данных на клиент
Это прям если очень сильно упростить. И эти все процессы необходимо повторить каждый для каждого отдельно взятого чанка.
При скорости доступа в условные 140 мс (ping, только не путайте с скоростью передачи данных) в целом загрузка чанков особой проблемы не представляет. Видео стабильно загружаются, быстро перематываются, доступно максимальное качество. Но когда же мы подключаемся к VPN серверу, то все те же операции многократно дублируются.
Так как клиентское устройство передает данные сначала на сервер VPN, затем сервер VPN связывается с сервером, который раздает видео. Этот сервер отправляет данные снова на VPN, а последний уже возвращает данные клиенту. Путь прохождения сигнала становится существенно длиннее. И чем дальше размещен VPN сервер относительно местоположения клиента, тем сильнее ситуация усугубляется. А HLS, ввиду большого количества чанков и необходимости постоянный переподключений для загрузки новых фрагментов, довольно чувствительно реагирует на такое удлинение маршрута. В следствие чего страдает производительность воспроизведения видео. Это проявляется в большем времени ожидания начальной загрузки, ожидания запуска видео после перемотки. Так же в манифесте HLS может быть указано, при какой скорости интернет-соединения какой поток выбирать. Схема похожа на ту, которую используют в css стилях для адаптивной верстки, когда на разной ширине экрана меняется положение и размер элементов WEB-страницы. Таким образом включение VPN между клиентом и сервером с потоковым видео может повлиять на авто выбор потока воспроизведения в пользу потока с меньшим битрейтом, а следственно и качеством. Конечно, не на всех потоках эти значения указаны, а также никто не запрещает вручную поставить максимальное качество, но тем не менее такое поведение временами встречается.
Заключение
Что в целом можно сказать о HLS? Фактически это очень простая технология и по своему изящна. У HLS есть ряд особенностей, которые позволяют легко встроить рекламу в целевой ролик и даже отчасти динамически её изменять и при этом обеспечивать бесшовное воспроизведение. Технология позволяет сравнительно скромными средствами достаточно подробно отслеживать динамику просмотров видео, определять наиболее часто просматриваемые фрагменты с точностью до длительности чанка. Подготовить видео хоть в целом и затратно (любая конвертация видео это вычислительно сложная задача), но сам процесс довольно несложный. К этому мы еще вернемся в практической части статьи. К тому же HLS фактически индустриальный стандарт (хотя таковым называют MPEG-DASH), поддерживается с коробочки всей техникой Apple, HTML5, большей частью браузеров и устройств.
К недостаткам можно отнести тот факт, что для одного и того же видео суммарное дисковое пространство в HLS формате потребуется больше. Есть необходимость конвертации видео (чанки могут быть только в формате MPEG-TS), и формат довольно чувствителен к задержкам в сети. Однако это свойственно всем форматам потокового видео.
P.S. Статью решил разбить на две части: теория и практика. Так как в практической части хватает и другого материала, и не охота мешать теплое с мягким. Поэтому в данной статье разобрали теоретическую часть, чтобы было понимание, что и почему нам нужно делать и как в принципе устроено потоковое вещание. В практической же части посмотрим на то, как именно сделать такое своими руками.
