Skip to content
Техспец PRO
Menu
  • Главная
  • Продукты
    • TCD
    • Информатор
    • Помощник Геткурс
  • Услуги
    • GetCourse
    • Вебинары
    • SaleBot и создание чат-ботов
    • Инфраструктурные решения
    • Аудио/видео продакшн
  • Обо мне
Menu

Потоковое видео своими руками (теория)

Posted on 30.09.202430.09.2024 by backtrack

В свете последних событий с замедлениями, блокировками и прочими «радостями» часто возникает вопрос, а где и как альтернативно размещать свои видео, да еще и чтобы все было максимально доступно для всех.

Кому это всё надо?

Подозреваю, что подавляющее кол-во людей попросту воспользуются альтернативными площадками вроде того же 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. Статью решил разбить на две части: теория и практика. Так как в практической части хватает и другого материала, и не охота мешать теплое с мягким. Поэтому в данной статье разобрали теоретическую часть, чтобы было понимание, что и почему нам нужно делать и как в принципе устроено потоковое вещание. В практической же части посмотрим на то, как именно сделать такое своими руками.

Добавить комментарий Отменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.

Рубрики

  • Yandex DataLens
  • Дайджест новостей
  • Для начинающих
  • Курилка техспеца
  • По фану
  • Разработка

Мы используем куки для наилучшего представления нашего сайта.

Если Вы продолжите использовать сайт, мы будем считать что Вас это устраивает.

Вы можете узнать больше о том, какие файлы cookie мы используем, или отключить их в .

Техспец PRO
Powered by  Соблюдение GDPR Cookie
Политика конфеденциальности

Этот веб-сайт использует файлы cookie, чтобы мы могли предоставить вам наилучший пользовательский опыт. Информация о файлах cookie хранится в вашем браузере и выполняет такие функции, как распознавание вас, когда вы возвращаетесь на наш веб-сайт, и помогает нашей команде в понимании того, какие разделы веб-сайта вы считаете наиболее интересными и полезными.

Строго необходимые файлы cookie

Строго необходимые файлы cookie должны быть включены постоянно, чтобы мы могли сохранить ваши предпочтения для настроек файлов cookie.

Если вы отключите этот файл cookie, мы не сможем сохранить ваши настройки. Это означает, что каждый раз, когда вы посещаете этот веб-сайт, вам нужно будет снова включать или отключать файлы cookie.