В последно време като хоби записвам на видео лекции на познат психолог. Записаният материал монтирам и публикувам на моя сайт. Преди месец ми хрумна идеята да организирам 24/7 стрийминг на тези лекции в YouTube. Нещо като тематичен „телеканал“, посветен на личностното развитие.
Знам как да направя обикновен стрийминг. Но как да направя така, че да бъде стрийминг на видеофайлове? За да работи 24/7, да бъде гъвкав, максимално автономен и в същото време да не зависи от моят домашен компютър. Това трябваше да разбера.
Намирането на решение отне няколко дни. Прегледах множество форуми и различни ръководства, без които моят стрийминг просто нямаше да се получи. И сега, когато експериментът се увенча с успех, чувствам необходимост да споделя решението си. Така се появи тази статия.
Вкратце, крайното решение е следното: VPS + ffmpeg + bash-скрипт. Под кат описвам направените стъпки и говоря за "подводните камъни", които се оказаха при организирането на стрийминга.
Стъпка 1 – откъде ще идва стриймингът?
В самото начало трябваше да определя откъде ще се осъществява стриймингът, къде ще бъде неговият източник. Първото, което ми дойде на ум – от домашния компютър. Събрах видеата в плейлист и пуснах тяхното възпроизвеждане в какъвто и да е видеоплеър. След това да заснема изображението от екрана и да го стриймвам в YouTube. Но почти веднага отхвърлих този вариант, тъй като за реализацията му е нужно домашният компютър да е постоянно включен, а това е шум от охладителите дори нощем и повишено потребление на електрическа енергия (+100-150 кВтч всеки месец). И се оказва, че с домашния компютър по време на стрийминга не може да се използва, тъй като всяко движение на мишката ще се вижда в стрийминга.
След това започнах да разглеждам облачни услуги. Търсех готова услуга, където да мога да кача своите видеа или, например, да вмъкна линкове към видеа от YouTube, и всичко това да се обедини в едно нон-стоп предаване. Но не намерих нищо подходящо. Може би търсех не добре. Единственото нещо, което е ± подходящо за функционала – е restream.io, услуга, която помага да се предава едновременно на няколко платформи. Те имат на вид възможност да се качват собствени видеа. Но тази услуга е създадена за съвсем различни цели и те разчитат, че предаването ще продължи само два часа. Мисля, че ако с тази услуга може да се организира 24/7 предаване, то би било на стойност десетки или дори стотици долари на месец. А искалo се предаването да бъде организирано или безплатно, или с минимални финансови вложения.
Стана ясно, че за предаването е нужно или отделно устройство или дори отделен компютър. Мислех в посока нещо подобно на 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 с няколко атрибута. Ето как изглежда най-кратката команда, която успях да получа:
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 GHz), 1 гигабайт оперативна памет, SSD с капацитет 25 GB. Оперативната памет беше достатъчна, но процесорът почти непрекъснато работеше на 100% (понякога дори на 102-103% 🙂 Това водеше до забавяния на транслацията на всеки няколко секунди. Не изглеждаше хубаво.
Можеше просто да взема по-скъпа конфигурация с две ядра, като имам предвид, че при облачните технологии смяната на конфигурацията на сървъра става с натискането на няколко бутона. Но исках да се вместя в мощностите на минималната конфигурация. Започнах да изучавам документацията на ffmpeg и да, там също има настройки, които позволяват регулиране на натоварването на системата.
Високото качество на изображението може да бъде постигнато по два начина: или чрез високо натоварване на процесора, или чрез голям изходящ трафик. В резултат, колкото повече натоварване поема процесорът, толкова по-малка ще бъде необходимата пропускателна способност на канала. Или може да не се натоварва много процесорът, но тогава ще е необходим широк канал с голям резерв за трафика. Ако обаче има ограничения както на процесора, така и на размера на изходящия канал/трафик, ще се наложи да намаля качеството на картината, за да може транслацията да върви без прекъсвания.
Моят сървър разполага с канал с ширина 10 Mbit/s. Тази ширина е с доста резерв. Но има ограничение на трафика – 1 TB на месец. Следователно, за да се вместя в ограниченията на трафика, моят изходящ поток не трябва да надвишава около 300 Kb в секунда, тоест битрейта на изходящия поток не трябва да бъде повече от 2.5 Mbit/s. Между другото, YouTube точно препоръчва транслации с такъв битрейт.
За регулиране на натоварването на системата ffmpeg използва различни подходи. Добре е описано . В крайна сметка използвах два атрибута: -crf и -preset.
Constant Rate Factor (CRF) – това е коефициент, благодарение на който може да се регулира качеството на изображението. CRF може да има стойности от 0 до 51, където 0 е качеството на оригиналния файл, а 51 е най-ниското възможно качество. Препоръчително е да се използват стойности от 17 до 28, по подразбиране е 23. При коефициент 17, видеото визуално ще бъде идентично на оригинала, но технически няма да бъде такова. В документацията също е посочено, че размерът на крайното видео в зависимост от зададения CRF се променя експоненциално, т.е. увеличаването на коефициента с 6 пункта ще доведе до удвояване на битрейта на изходящото видео.
Ако с помощта на CRF може да се определи "теглото" на изходящото изображение, то с помощта на preset (-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
