Последнее время в качестве хобби снимаю на видео лекции знакомого психолога. Отснятый материал монтирую и публикую на своём сайте. Месяц назад я загорелся идеей организовать круглосуточную трансляцию этих лекций на YouTube в режиме 24/7. Этакий тематический «телеканал», посвященный личностному росту.
Как сделать обычную трансляцию я знаю. А вот как сделать так, чтобы это была трансляция именно видео-файлов? Чтобы она шла 24/7, была гибкой, максимально автономной и при этом никак не зависела от моего домашнего компьютера. Это мне и предстояло выяснить.
На поиск решения ушло несколько дней. Я изучил множество форумов и различных мануалов без которых моя трансляция просто бы не получилась. И теперь, когда шалость удалась, я чувствую потребность поделиться своим решением. Так появилась эта статья.
Если коротко, то итоговое решение получилось следующим: VPS + ffmeg + bash-скрипт. Под катом я описываю проделанные шаги и рассказываю про «подводные камни», которые обнаружились при организации трансляции.
Шаг 1 – откуда будет идти трансляция?
В самом начале нужно было определиться откуда будет вестись трансляция, где будет её источник. Самое первое, что приходило в голову – с домашнего компьютера. Собрать видео в плейлист и запустить их воспроизведение в любом видеоплеере. Затем захватить изображение с экрана и транслировать его на YouTube. Но я почти сразу отмёл этот вариант т.к. для его реализации нужно держать домашний компьютер постоянно включенным, а это шум от кулеров даже ночью и увеличенное потребление электроэнергии (+100-150 кВт*ч каждый месяц). И получается, что домашним компьютером на время трансляции пользоваться будет нельзя т.к. любое шевеление мышкой будет видно в трансляции.
Дальше я стал смотреть в сторону облачных сервисов. Искал готовый сервис, куда бы можно было загрузить свои видео или, например, вставить ссылки на видео с YouTube и это бы все упаковывалось в одну нон-стоп трансляцию. Но ничего подходящего не нашел. Возможно плохо искал. Единственное что-то ± подходящее под функционал – это restream.io, сервис, который помогает вести одновременную трансляцию на несколько платформ. У них вроде можно загружать свои видео. Но этот сервис создавался совсем для других целей и они рассчитывают, что трансляция будет длиться всего пару часов. Думаю, что если через этот сервис получилось бы организовать круглосуточную трансляцию, то это бы выстрелило в десятки, а то и сотни долларов в месяц. А трансляцию все же хотелось организовать либо бесплатно, либо с минимальными финансовыми вложениями.
Стало понятно, что под трансляцию нужно или отдельное устройство или вообще отдельный компьютер. Думал в сторону чего-нибудь вроде Raspberri Pi. А чего? Кулера у него нет. Записал видео на флешку, воткнул Ethernet-кабель и пускай лежит себе где-нибудь в укромном месте, трансляцию ведёт. Вариант. Но ни самой платы, ни опыта работы с ней у меня не было, поэтому от этого варианта я тоже отказался.
В итоге я наткнулся на некое обсуждение, где обсуждали создание собственного сервера трансляции. Это было не совсем то, что я искал, но основную мысль я уловил – можно же использовать сервер! В том обсуждении предлагали использовать связку VPS + nginx + OBS. Стало понятно, что эта связка может подойти и мне. Смущало лишь то, что я никогда не администрировал сервера и мне казалось, что свой выделенный сервер – это заморочено и дорого. Решил узнать сколько будет стоить арендовать сервер в минимальной комплектации и был приятно удивлен.
Цены указаны в белорусских рублях и это просто крохи. Для понимания, 8 белорусских рублей – это где-то 3.5 доллара или 240 российских рублей. За месяц использования полноценного компьютера, который включен 24/7 и имеет быстрый доступ в Интернет. Почему-то это открытие стало очень радостным для меня и я несколько дней ходил жутко довольный словно ребенок, который открыл для себя космические ракеты 🙂
К слову, я воспользовался предложением первого же сайта, который выдал мне Google по запросу «аренда VPS». Возможно есть ещё более бюджетные решения, но эта цена меня устроила и дальше я не искал.
При создании сервера можно выбрать операционную систему, под управлением которой он будет работать. На любой из перечисленных систем можно организовать трансляцию и делать выбор стоит исходя из ваших предпочтений и финансовых возможностей (за сервер с Windows просят дополнительную плату). Я выбрал CentOS. Просто потому что у меня раньше был небольшой опыт работы с ней.
Шаг 2 – настройка сервера
Первое, что нужно после создания сервера – это подключиться к нему по SSH. По-началу я использовал PuTTy, но потом стал использовать приложение Secure Shell App, которое запускается в Google Chrome. Так мне оказалось удобнее.
Дальше я изменил имя хоста, настроил синхронизацию времени на сервере, обновил систему, возился с iptables… и сделал еще куча вещей, но не потому что это было необходимо. Просто мне интересно было настраивать сервер и у меня это получалось. Люблю когда получается 🙂
А вот те шаги, которые нужно сделать:
- Подключить репозиторий EPEL.
- Поднять FTP-сервер (я выбрал vsftp).
- Установить ffmpeg.
Детально команды приводить не буду, эта инструкция скорее концептуальная, чтобы донести общий план действий. Если у вас по какому-либо из шагов возникнут затруднения, то они быстро решаются запросом в поисковике вида «CentOS подключить EPEL» или «CentOS установка FTP-сервера». И по первым ссылкам вы сможете найти детальные пошаговые инструкции.
Итак, как я уже писал раньше, мне нужна была связка VPS + nginx + OBS. VPS – готово. Но вот по остальным пунктам стали возникать вопросы. OBS – это программа для проведения трансляций, Open Broadcaster Software. И оно работает только с потоками т.е. например, берет изображение с веб-камеры и его транслирует. Или запись экрана. Или уже идущую трансляцию перенаправляет на другой сайт. А у меня нет потока, у меня есть только набор видео-файлов, который нужно сделать потоком.
Стал копать в эту сторону и наткнулся на ffmpeg. FFmpeg – это набор свободных библиотек с открытым исходным кодом, которые позволяют записывать, конвертировать и передавать цифровые аудио- и видеозаписи в различных форматах.
И я очень удивился сколько всего ffmpeg может. Хочешь – вытянет звук из видео. Хочешь – вырежет фрагмент видео без перекодирования. Хочешь – сконвертирует из одного формата в другой. И много-много чего ещё. Вплоть до того, что ему можно указать файл, он его преобразует в поток и сам передаст на YouTube. Всё, цепочка собрана. Осталось только доработать нюансы.
Шаг 3 – настройка трансляции
Создаём трансляцию на YouTube. На этом этапе нам нужна только ссылка и ключ трансляции. На скриншоте ниже они выделены красным.
Далее загружаем на сервер видео-файлы, которые планируем транслировать. Собственно, FTP только для этого этапа и нужен. Если у вас есть другой удобный способ загрузки файлов на сервер, то FTP-сервер можно не поднимать.
Передаём поток на YouTube. Для старта вещания необходимо запустить ffmpeg c несколькими атрибутами. Вот так выглядит самая короткая команда, которая у меня получилась:
ffmpeg -re -i lecture1.mp4 -f flv rtmp://a.rtmp.youtube.com/live2/%КЛЮЧ_ТРАНСЛЯЦИИ%
Расшифровка атрибутов-re – указывает, что файл необходимо конвертировать в поток.
-i – указывает, какой файл необходимо воспроизводить. Важно, чтобы команда запускалась из того же каталога, где расположен сам видео-файл. Иначе стоит указывать абсолютную ссылку на файл, вроде /usr/media/lecture1.mp4.
-f – задает формат выходного файла. В моём случае получается, что ffmpeg «на лету» конвертирует мой файл из mp4 в flv.
И в конце указываем данные, которые мы взяли на YouTube на странице настройки трансляции т.е. адрес, на который нужно передавать данные, и ключ трансляции, чтобы трансляция отобразилась именно на вашем канале.
Если вы всё сделали правильно, то после запуска этой команды, YouTube увидит передаваемый поток. Для запуска трансляции вам останется нажать кнопку «Начать трансляцию» в самом YouTube.
Шаг 4 – добавляем автономность
Поздравляю! Теперь вы знаете как запустить трансляцию из видео-файла. Но этого недостаточно для круглосуточной трансляции. Важно, чтобы после окончания воспроизведения первого видео, сразу же запускалось следующее, а когда покажутся все видео, воспроизведение начиналось сначала.
Я придумал следующий вариант: создать .sh-файл, в котором прописал по команде на каждый видео-файл и в самом конце указал команду на повторный запуск этого же скрипта. Получилась этакая рекурсия:
Команда 1... (запуск трансляции файла lecture1.mp4)
Команда 2... (запуск трансляции файла lecture2.mp4)
Команда 3... (запуск трансляции файла lecture3.mp4)
bash start.shИ, да, это сработало. Я, довольный собой, запустил тестовую трансляцию и пошёл спать.
Утром меня ожидал неприятный сюрприз. Оказалось, что трансляция шла всего пару минут и закончилась практически сразу как я выключил свой компьютер. Расследование показало, что команды, запущенные таким образом, выполняются пока пользователь авторизован на сервере. Как только я отключился, выполнение запущенных мной команд прервалось. Чтобы такого не происходило, достаточно перед командой bash дописать команду nohup. Это позволит запущенному процессу выполняться независимо от вашего присутствия.
Итоговая минимальная версия скрипта выглядит так:
ffmpeg -re -i lecture1.mp4 -f flv rtmp://a.rtmp.youtube.com/live2/%КЛЮЧ_ТРАНСЛЯЦИИ%
ffmpeg -re -i lecture2.mp4 -f flv rtmp://a.rtmp.youtube.com/live2/%КЛЮЧ_ТРАНСЛЯЦИИ%
ffmpeg -re -i lecture3.mp4 -f flv rtmp://a.rtmp.youtube.com/live2/%КЛЮЧ_ТРАНСЛЯЦИИ%
nohup bash start.sh $Где start.sh – это файл, в котором записан этот скрипт. И этот файл должен располагаться в одном каталоге с видео-файлами.
Добавление знака доллара в конце позволяет запускать процесс в фоновом режиме, чтобы можно было дальше пользоваться консолью не прерывая вещание.
Из бонусов получились следующие плюшки:
- Можно вручную переключать воспроизведение файлов. Для этого нужно «убить» выполняющийся в текущий момент процесс ffmpeg. После этого автоматически запустится воспроизведение следующего файла из списка.
- Новые видео можно добавлять в трансляцию без остановки вещания. Просто загружаете видео на сервер, дописываете в скрипте команду на запуск этого файла, сохраняете. И всё. На следующем круге воспроизведения новый файл уже будет транслироваться наравне со старыми файлами.
Шаг 5 – донастраиваем ffmpeg
На этом, в принципе, можно было остановиться. Но мне хотелось сделать трансляцию чуть более дружелюбной для зрителей.
Допустим, человек зашел на трансляцию, начал смотреть, ему понравилось и он захотел посмотреть эту лекцию с начала, а трансляция не предусматривает перемотку. Для просмотра лекции с начала человеку нужно будет перейти на мой сайт и получить запись интересующей лекции. А как понять какая лекция его интересует? На сайте уже 16 лекций и каждую неделю их становится только больше. Думаю, что даже я, кто снимал и монтировал все эти лекции, не смогу по случайному фрагменту определить какая это лекция. Поэтому нужно, чтобы каждая лекция была как-то обозначена.
Вариант добавить надписи в исходные видео-файлы в программе для монтажа меня не устраивал. Нужно было сделать так, чтобы использовались оригинальные файлы. Чтобы поддержка трансляции требовала от меня как можно меньше телодвижений.
Оказалось, что и в этом мне сможет помочь ffmpeg. У него есть специальный атрибут -vf, который позволяет наносить текст поверх видео. Чтобы добавить текст на видео, необходимо в команду добавить следующий фрагмент:
-vf drawtext="fontfile=OpenSans.ttf:text='Лекция 13: Психология эмоций. Как создавать радость?':fontsize=26:fontcolor=white:borderw=1:bordercolor=black:x=40:y=670"
Расшифровка параметровfontfile= – ссылка на файл шрифта. Без этого надпись на видео не добавляется. Проще всего файл шрифта положить в одну папку с видео. Или нужно будет указать полный путь к файлу.
text= – собственно, сам текст, который необходимо разместить поверх видео.
fontsize= – размер шрифта в пикселях.
fontcolor= – цвет шрифта.
borderw= – толщина контура вокруг текста в пикселях (у меня белый текст с черным контуром толщиной в 1 пиксель).
bordercolor= – цвет контура.
x= и y= – координаты текста. Точка 0;0 находится в левом верхнем углу. У меня координаты подобраны таким образом, чтобы текст размещался в левом нижнем углу при разрешении видео 1280х720 пикселей.
Выглядит это вот так:
Шаг 6 – определяемся с качеством трансляции
Всё, трансляция готова. FFmpeg вещает, файлы воспроизводятся, моё присутствие для трансляции не нужно. Даже каждая лекция подписана. Вроде всё.
Но всплыл ещё один нюанс – я выбрал минимальную конфигурацию сервера и он не вытягивал трансляцию. Конфигурация сервера: 1 ядро (вроде 2.2 ГГц), 1 гигабайт оперативной памяти, SSD на 25 Гб. Оперативной памяти хватало, а вот процессор практически наглухо уходил в загрузку на 100% (а временами даже в 102-103% 🙂 Это приводило к тому, что трансляция раз в несколько секунд подвисала. Некрасиво.
Можно было просто взять более дорогую конфигурацию с двумя ядрами, благо, что с облачными технологиями смена конфигурации сервера происходит нажатием пары кнопок. Но мне хотелось уместиться на мощностях минимальной конфигурации. Стал изучать документацию ffmpeg и да, там также есть настройки, которые позволяют регулировать нагрузку на систему.
Высокое качество изображения может быть достигнуто двумя путями: либо высокой нагрузкой на процессор, либо большим исходящим трафиком. Получается, чем больше нагрузку на себя может взять процессор, тем меньше нужна будет пропускная способность канала. Или можно сильно не нагружать процессор, но тогда нужен будет широкий канал с большим запасом по трафику. Если же есть ограничения и по процессору, и по размеру исходящего канала/трафику, то придется снижать качество картинки, чтобы трансляция шла без рывков.
Моему серверу доступен канал шириной в 10 Мбит/с. Такой ширины прям с запасом. Но есть ограничение по трафику – 1 ТБ в месяц. Поэтому, чтобы уложиться в ограничения по трафику, мой исходящий поток не должен превышать ~300 Кб в секунду т.е. битрейт исходящего потока должен быть не более 2,5 Мбит/с. YouTube, кстати, как раз и рекомендует вести трансляции в таком битрейте.
Для регуляции нагрузки на систему ffmpeg использует разные подходы. Хорошо об этом расписано . Я в итоге использовал два атрибута: -crf и -preset.
Constant Rate Factor (CRF) – это коэффициент, благодаря которому можно регулировать качество картинки. CRF может иметь значения от 0 до 51, где 0 – качество исходного файла, 51 – наихудшее возможное качество. Рекомендуется использовать значения от 17 до 28, по умолчанию стоит 23. При коэффициенте 17 видео визуально будет идентично исходному, но технически таким являться не будет. Также в документации указано, что размер итогового видео в зависимости от указанного CRF меняется экспоненциально т.е. увеличение коэффициента на 6 пунктов приведет к удвоению битрейта исходящего видео.
Если с помощью CRF можно подобрать «вес» исходящей картинки, то с помощью пресетов (-preset) можно определить насколько сильно будет загружен процессор. Параметры у этого атрибута есть следующие:
ultrafastsuperfastveryfastfasterfastmedium– значение по умолчаниюslowslowerveryslow
Чем «быстрее» параметр указан, тем выше будет нагрузка на процессор.
Я сначала подобрал пресет, который был в принципе «по зубам» моему процессору, а затем более тонко подобрал нагрузку с помощью CRF. В моём случае подошел пресет fast, а для crf я остановился на значении 24.
Заключение
На этом всё. Итоговая команда для запуска трансляции у меня получилась такой:
ffmpeg -re -i lecture1.mp4 -vf drawtext="fontfile=OpenSans.ttf:text='Лекция 1: Жонглирование картинами мира':fontsize=26:fontcolor=white:borderw=1:bordercolor=black:x=40:y=670" -c:v libx264 -preset fast -crf 24 -g 3 -f flv rtmp://a.rtmp.youtube.com/live2/%КЛЮЧ_ТРАНСЛЯЦИИ%Здесь осталось только два неописанных момента:
1) -c:v libx264 – указание конкретного кодека для работы с исходным файлом.
2) -g 3 – явное указание количества ключевых кадров. В этом случае указано, что каждый третий кадр должен быть ключевым. Стандартное значение то ли на 5, то ли на 8, но YouTube ругается, просит не менее 3.
Какого качества получилась трансляция можно посмотреть .
Нагрузка на сервер получилась следующая:
Исходя из данных мониторинга, видно, что нагрузка на процессор колеблется в рамках от 70% до 95% и за неделю трансляция ни разу не уперлась в 100%. Значит, с такими настройками процессора хватает.
По загрузке диска могу сказать, что он почти не нагружен и для трансляции вполне должно хватить и обычного HDD.
А вот количество исходящего трафика меня беспокоит. Получается, что мой исходящий поток колеблется от 450 до 650 Кбайт в секунду. За месяц это составит порядка 1,8 терабайт. Возможно придется докупать трафик или все же перейти на конфигурацию с двумя ядрами т.к. качество картинки не хотелось бы снижать.
***
Как итог, скажу, что настройка такой трансляции с нуля занимает порядка 1-2 часов. Причем большую часть времени займёт загрузка видео на сервер.
Как маркетинговый инструмент запуск такой трансляции себя не оправдал. Возможно, если накрутить просмотры, чтобы алгоритмы YouTube подхватили эту трансляцию и стали активно показывать её в рекомендациях, тогда что-то бы и получилось. В моём же случае за 16 дней непрерывной трансляции её посмотрели 58 раз.
Ну ничего. Трансляция гармонично вписалась на главной странице моего сайта. Получилась этакая возможность быстро составить своё мнение о лекторе и самих лекциях.
И ещё один момент. Важно, чтобы трансляция не нарушала ничьих авторских прав иначе её заблокируют. Я за свою трансляцию спокоен т.к. музыкальные вставки я специально выбирал со свободным использованием, а автор контента сидит за соседним компьютером и весьма не против того, чтобы я использовал её контент 🙂
Но если у вас в трансляции где-то фоном играет радио, или вы при монтаже использовали любимый трек, или взяли видеоряд из популярного музыкального клипа, сериала или фильма – тогда ваша трансляция в зоне риска. Также важно, чтобы трансляция несла хотя бы минимальную смысловую нагрузку, иначе её могут заблокировать как спамерскую.
***
На этом у меня всё. Надеюсь этот мануал сослужит кому-нибудь хорошую службу. Ну а если вам есть что добавить – пишите, с удовольствием почитаю дополнения и уточнения к статье.
Источник: habr.com