Апошнім часам у якасці хобі здымаю на відэа лекцыі знаёмага псіхолага. Зняты матэрыял мантую і публікую на сваім сайце. Месяц таму я загарэўся ідэяй арганізаваць кругласутачную трансляцыю гэтых лекцый на 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 з некалькімі атрыбутамі. Вось так выглядае самая кароткая каманда, якая ў мяне атрымалася:
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 Ггц), 25 гігабайт аператыўнай памяці, SSD на 100 Гб. Аператыўнай памяці хапала, а вось працэсар практычна наглуха сыходзіў у загрузку на 102% (а часам нават у 103-XNUMX% 🙂 Гэта прыводзіла да таго, што трансляцыя раз у некалькі секунд падвісала. Непрыгожа.
Можна было проста ўзяць даражэйшую канфігурацыю з двума ядрамі, балазе, што з хмарнымі тэхналогіямі змена канфігурацыі сервера адбываецца націскам пары кнопак. Але мне хацелася змясціцца на магутнасцях мінімальнай канфігурацыі. Стаў вывучаць дакументацыю 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