Pēdējā laikā kā hobijs filmēju kāda sev pazīstama psihologa lekcijas. Es rediģēju uzņemto materiālu un publicēju to savā vietnē. Pirms mēneša man radās ideja organizēt šo lekciju 24/7 translāciju YouTube. Sava veida tematisks “TV kanāls”, kas veltīts personīgajai izaugsmei.
Es protu taisīt regulāru raidījumu. Bet kā to panākt, lai tā būtu video failu pārraide? Lai tas darbojas 24/7, ir elastīgs, pēc iespējas autonomāks un tajā pašā laikā nekādā veidā nav atkarīgs no mana mājas datora. Tas man bija jānoskaidro.
Pagāja vairākas dienas, lai atrastu risinājumu. Es pētīju daudzus forumus un dažādas rokasgrāmatas, bez kurām mana pārraide vienkārši nebūtu darbojusies. Un tagad, kad palaidnība ir izdevusies, es jūtu nepieciešamību dalīties ar savu risinājumu. Šādi parādījās šis raksts.
Īsāk sakot, galīgais risinājums bija šāds: VPS + ffmeg + bash skripts. Zem griezuma es aprakstu veiktos soļus un runāju par slazdiem, kas tika atklāti, organizējot raidījumu.
1. darbība – no kurienes nāks pārraide?
Pašā sākumā bija jāizlemj, no kurienes būs raidījums un kur būs tā avots. Pati pirmā lieta, kas ienāca prātā, bija no sava mājas datora. Apkopojiet videoklipus atskaņošanas sarakstā un sāciet tos atskaņot jebkurā video atskaņotājā. Pēc tam uzņemiet ekrāna attēlu un pārraidiet to pakalpojumā YouTube. Bet es gandrīz uzreiz noraidīju šo iespēju, jo... Lai to īstenotu, nepieciešams pastāvīgi ieslēgt mājas datoru, kas nozīmē dzesētāju radīto troksni pat naktī un palielinātu elektroenerģijas patēriņu (+100-150 kWh katru mēnesi). Un izrādās, ka apraides laikā nevarēsit izmantot mājas datoru. raidījumā būs redzama jebkura peles kustība.
Tad sāku skatīties uz sāniem mākoņpakalpojumi. Meklēju gatavu servisu, kur varētu augšupielādēt savus video vai, piemēram, ievietot saites uz video no YouTube, un tas viss tiktu iepakots vienā nepārtrauktā pārraidē. Bet neko piemērotu neatradu. Varbūt es slikti meklēju. Vienīgais, kas atbilst funkcionalitātei, ir restream.io — pakalpojums, kas palīdz pārraidīt vienlaikus vairākās platformās. Šķiet, ka tie ļauj augšupielādēt savus videoklipus. Taču šis serviss tika izveidots pavisam citiem mērķiem un viņi paredz, ka pārraide ilgs vien pāris stundas. Es domāju, ka, ja caur šo pakalpojumu būtu iespējams organizēt diennakts pārraidi, tad tas iešūtu desmitos vai pat simtos dolāru mēnesī. Bet es tomēr gribēju organizēt raidījumu vai nu par velti, vai ar minimāliem finanšu ieguldījumiem.
Kļuva skaidrs, ka raidījumam bija nepieciešams vai atsevišķa ierīce vai pat atsevišķu datoru. Es domāju par kaut ko līdzīgu Raspberri Pi. Un kas? Viņam nav dzesētāja. Es ierakstīju video zibatmiņā, pievienoju Ethernet kabeli un ļāvu tam gulēt kaut kur nomaļā vietā un pārraidīt to. Opcija. Bet man nebija ne pašas valdes, ne pieredzes darbā ar to, tāpēc arī no šī varianta atteicos.
Rezultātā es saskāros ar noteiktu diskusiju, kurā viņi apsprieda radīšanu savs serveris raidījumi. Tas nebija tieši tas, ko meklēju, bet es sapratu galveno domu - jūs varat izmantot serveri! Šajā diskusijā tika ieteikts izmantot VPS + nginx + OBS kombināciju. Kļuva skaidrs, ka šī kombinācija varētu derēt arī man. Vienīgais, kas mani mulsināja, bija tas, ka es nekad nebiju administrējis serveri, un man šķita, ka sava servera izveide ir mulsinoša un dārga. Nolēmu noskaidrot, cik izmaksās īrēt serveri ar minimālu konfigurāciju un biju patīkami pārsteigts.
Cenas norādītas Baltkrievijas rubļos un tās ir tikai drupatas. Lai saprastu, 8 Baltkrievijas rubļi ir aptuveni 3.5 dolāri jeb 240 Krievijas rubļi. Par mēnesi lietot pilnvērtīgu datoru, kas ir ieslēgts 24/7 un kuram ir ātrs interneta pieslēgums. Šis atklājums nez kāpēc man kļuva ļoti priecīgs un vairākas dienas staigāju šausmīgi priecīgs, kā bērns, kurš atklāja kosmosa raķetes :)
Starp citu, es izmantoju pirmās vietnes piedāvājumu, ko Google man sniedza vaicājumam “VPS noma”. Varbūt ir vēl vairāk budžeta risinājumu, taču šī cena man bija piemērota, un es neskatījos tālāk.
Veidojot serveri, varat izvēlēties operētājsistēmu, kurā tas darbosies. Varat organizēt apraidi jebkurā no uzskaitītajām sistēmām un izdarīt izvēli, pamatojoties uz jūsu vēlmēm un finansiālajām iespējām (serverim ar Windows viņi prasa papildu maksu). Es izvēlējos CentOS. Vienkārši tāpēc, ka iepriekš man ar to bija maz pieredzes.
2. darbība – servera iestatīšana
Pirmā lieta, kas jums nepieciešams pēc servera izveidošanas, ir izveidot savienojumu ar to, izmantojot SSH. Sākumā izmantoju PuTTy, bet pēc tam sāku lietot lietotni Secure Shell, kas darbojas pārlūkprogrammā Google Chrome. Man tas izrādījās ērtāk.
Pēc tam nomainīju resursdatora nosaukumu, iestatīju serverī laika sinhronizāciju, atjaunināju sistēmu, pastrādāju ar iptables... un darīju vēl daudzas citas lietas, bet ne tāpēc, ka tas būtu nepieciešams. Mani vienkārši interesēja servera iestatīšana, un tas man darbojās. Man patīk, kad izdodas :)
Tālāk ir norādītas darbības, kas jums jāveic.
- Pievienojiet EPEL repozitoriju.
- Iestatiet FTP serveri (es izvēlējos vsftp).
- Instalējiet ffmpeg.
Es nesniegšu komandas sīkāk; šie norādījumi ir diezgan konceptuāli, lai sniegtu vispārīgu darbības plānu. Ja rodas grūtības ar kādu no darbībām, tās var ātri atrisināt, izmantojot meklētājprogrammas vaicājumu, piemēram, “CentOS connect EPEL” vai “CentOS instalēt FTP serveri”. Un pirmajās saitēs jūs varat atrast detalizētus soli pa solim norādījumus.
Tātad, kā jau rakstīju iepriekš, man bija nepieciešama VPS + nginx + OBS kombinācija. VPS – gatavs. Taču jautājumi sāka rasties par citiem jautājumiem. OBS ir apraides programma, Open Broadcaster Software. Un tas darbojas tikai ar straumēm t.i. piemēram, tas paņem attēlu no tīmekļa kameras un pārraida to. Vai ekrāna ierakstīšana. Vai arī jau notiekoša pārraide tiek novirzīta uz citu vietni. Bet man nav straumes, man ir tikai video failu kopa, kas jāpārveido par straumi.
Es sāku rakt šajā virzienā un saskāros ar ffmpeg. FFmpeg ir bezmaksas un atvērtā pirmkoda bibliotēku komplekts, kas ļauj ierakstīt, konvertēt un straumēt digitālo audio un video dažādos formātos.
Un es biju ļoti pārsteigts, cik daudz ffmpeg var darīt. Ja vēlaties, tas izvilks skaņu no video. Ja vēlaties, tas izgriezīs video fragmentu bez pārkodēšanas. Ja vēlaties, tas tiks pārveidots no viena formāta uz citu. Un daudz, daudz vairāk. Tiktāl, ka varat norādīt failu, tas pārveidos to straumē un pārsūtīs uz pakalpojumu YouTube. Tas viss, ķēde ir samontēta. Atliek tikai pabeigt nianses.
3. darbība – apraides iestatīšana
Mēs veidojam pārraidi vietnē YouTube. Šajā posmā mums ir nepieciešama tikai saite un apraides atslēga. Zemāk esošajā ekrānuzņēmumā tie ir iezīmēti sarkanā krāsā.
Tālāk augšupielādēt video failus serverī, kuru plānojam pārraidīt. Faktiski FTP ir nepieciešams tikai šajā posmā. Ja jums ir cits ērts veids, kā augšupielādēt failus serverī, jums nav jāiestata FTP serveris.
Mēs pārsūtām straumi uz YouTube. Lai sāktu apraidi, ir jāpalaiž ffmpeg ar vairākiem atribūtiem. Šādi izskatās īsākā komanda, ko saņēmu:
ffmpeg -re -i lecture1.mp4 -f flv rtmp://a.rtmp.youtube.com/live2/%КЛЮЧ_ТРАНСЛЯЦИИ%
Atribūtu dekodēšana-re – norāda, ka fails ir jāpārvērš straumē.
-i – norāda, kurš fails ir jāatskaņo. Ir svarīgi, lai komanda tiktu palaista no tā paša direktorija, kurā atrodas pats video fails. Pretējā gadījumā jums jānorāda absolūta saite uz failu, piemēram /usr/media/lecture1.mp4.
-f – iestata izvades faila formātu. Manā gadījumā izrādās, ka ffmpeg lidojumā pārvērš manu failu no mp4 uz flv.
Un beigās apraides iestatījumu lapā norādām datus, ko paņēmām no YouTube, t.i. adrese, uz kuru ir jāpārsūta dati, un apraides atslēga, lai apraide tiktu parādīta tieši jūsu kanālā.
Ja visu izdarījāt pareizi, pēc šīs komandas palaišanas YouTube redzēs pārraidīto straumi. Lai sāktu apraidi, jums vienkārši jānoklikšķina uz pogas "Sākt apraidi" pašā YouTube.
4. darbība – autonomijas pievienošana
Apsveicam! Tagad jūs zināt, kā sākt apraidi no video faila. Bet ar to nepietiek XNUMX/XNUMX apraidei. Ir svarīgi, lai pēc pirmā videoklipa atskaņošanas beigām nekavējoties sāktos nākamais, un, kad visi videoklipi ir parādīti, atskaņošana atsāktos no jauna.
Es izdomāju šādu iespēju: izveidot .sh failu, kurā uzrakstīju komandu katram video failam un pašās beigās norādīju komandu vēlreiz palaist to pašu skriptu. Rezultāts ir šāda rekursija:
Команда 1... (запуск трансляции файла lecture1.mp4)
Команда 2... (запуск трансляции файла lecture2.mp4)
Команда 3... (запуск трансляции файла lecture3.mp4)
bash start.shUn, jā, tas strādāja. Apmierināts ar sevi, es uzsāku testa pārraidi un devos gulēt.
No rīta mani sagaidīja nepatīkams pārsteigums. Izrādījās, ka pārraide ilga tikai pāris minūtes un beidzās gandrīz uzreiz, kad izslēdzu datoru. Izmeklēšana parādīja, ka šādā veidā palaistās komandas tiek izpildītas, kamēr lietotājs ir pieteicies serverī. Tiklīdz es atvienojos, komandas, kuras vadīju, tika pārtrauktas. Lai tas nenotiktu, pietiek komandas priekšā bash pievienojiet komandu nohup. Tas ļaus darbības procesam darboties neatkarīgi no jūsu klātbūtnes.
Skripta galīgā minimālā versija izskatās šādi:
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 $Kur start.sh ir fails, kurā ir rakstīts šis skripts. Un šim failam ir jāatrodas tajā pašā direktorijā, kurā atrodas video faili.
Dolāra zīmes pievienošana beigās ļauj procesam darboties fonā, lai jūs varētu turpināt izmantot konsoli, nepārtraucot apraidi.
Prēmijas ietvēra šādus labumus:
- Varat manuāli pārslēgt failu atskaņošanu. Lai to izdarītu, jums ir "jānogalina" pašreizējais ffmpeg process. Pēc tam automātiski tiks sākta nākamā saraksta faila atskaņošana.
- Raidījumam var pievienot jaunus videoklipus, nepārtraucot apraidi. Vienkārši augšupielādējiet video serverī, pievienojiet komandu, lai skriptā palaistu šo failu, un saglabājiet to. Tas ir viss. Nākamajā atskaņošanas kārtā jaunais fails tiks pārraidīts kopā ar vecajiem failiem.
5. darbība — pielāgojiet ffmpeg
Principā mēs varējām tur apstāties. Taču gribēju raidījumu padarīt skatītājiem nedaudz draudzīgāku.
Teiksim, cilvēks aizgāja uz raidījumu, sāka skatīties, iepatikās un gribēja skatīties šo lekciju no sākuma, bet raidījums neļauj attīt. Lai noskatītos lekciju no sākuma, cilvēkam būs jāiet uz manu vietni un jāiegūst interesējošās lekcijas ieraksts. Kā var pateikt, kura lekcija viņu interesē? Vietnē jau ir 16 lekcijas un katru nedēļu to ir tikai vairāk. Domāju, ka pat es, kas filmēju un montēju visas šīs lekcijas, nevarēšu pēc nejauša fragmenta noteikt, par kuru lekciju ir runa. Tāpēc ir nepieciešams, lai katra lekcija būtu kaut kā iecelta.
Man nederēja iespēja rediģēšanas programmā pievienot parakstus avota video failiem. Bija nepieciešams nodrošināt, ka tiek izmantoti oriģinālie faili. Lai raidījuma atbalstīšana no manis prasītu pēc iespējas mazākas ķermeņa kustības.
Izrādījās, ka ffmpeg var man palīdzēt arī šajā jautājumā. Tam ir īpašs atribūts -vf, kas ļauj ievietot tekstu virs video. Lai videoklipam pievienotu tekstu, komandai jāpievieno šāds fragments:
-vf drawtext="fontfile=OpenSans.ttf:text='Лекция 13: Психология эмоций. Как создавать радость?':fontsize=26:fontcolor=white:borderw=1:bordercolor=black:x=40:y=670"
Parametru skaidrojumsfontfile= – saite uz fonta failu. Bez tā paraksts netiks pievienots videoklipam. Vienkāršākais veids ir ievietot fonta failu tajā pašā mapē, kurā atrodas videoklips. Vai arī jums būs jānorāda pilns faila ceļš.
text= – patiesībā pats teksts, kas jāievieto video virspusē.
fontsize= - fonta lielums pikseļos.
fontcolor= - fonta krāsa.
borderw= – kontūras biezums ap tekstu pikseļos (man ir balts teksts ar melnu kontūru 1 pikseļa biezumā).
bordercolor= - kontūras krāsa.
x= и y= – teksta koordinātas. Punkts 0;0 atrodas augšējā kreisajā stūrī. Manas koordinātas ir atlasītas tā, lai teksts tiktu ievietots apakšējā kreisajā stūrī ar video izšķirtspēju 1280x720 pikseļi.
Tas izskatās šādi:
6. solis – nosakiet pārraides kvalitāti
Tas arī viss, raidījums ir gatavs. FFmpeg pārraida, faili tiek atskaņoti, mana klātbūtne nav nepieciešama apraidei. Pat katra lekcija ir parakstīta. Izskatās, ka tas ir viss.
Bet parādījās vēl viena nianse - izvēlējos minimālo servera konfigurāciju un tā nepavilka raidījumu. Servera konfigurācija: 1 kodols (piemēram, 2.2 GHz), 1 gigabaits RAM, 25 GB SSD. RAM bija pietiekami daudz, bet procesors bija gandrīz pilnībā noslogots uz 100% (un brīžiem pat 102-103% :) Tas noveda pie tā, ka raidījums sastinga ik pēc dažām sekundēm. Nav jauki.
Varētu vienkārši paņemt dārgāku konfigurāciju ar diviem kodoliem, par laimi ar mākoņtehnoloģijām servera konfigurācijas maiņa notiek, nospiežot pāris pogas. Bet es gribēju iekļauties minimālajā konfigurācijas ietilpībā. Sāku pētīt ffmpeg dokumentāciju un jā, tur ir arī iestatījumi, kas ļauj regulēt sistēmas slodzi.
Augstu attēla kvalitāti var panākt divos veidos: vai nu ar lielu CPU slodzi, vai lielu izejošo trafiku. Izrādās, jo lielāku slodzi procesors var uzņemties, jo mazāks kanāla joslas platums būs nepieciešams. Vai arī jūs nevarat pārāk daudz noslogot procesoru, bet tad jums būs nepieciešams plašs kanāls ar lielu trafika telpu. Ja ir ierobežojumi gan procesoram, gan izejošā kanāla/datplūsmas izmēram, tad nāksies samazināt attēla kvalitāti, lai apraide noritētu raiti.
Manam serverim ir pieejams 10 Mbit/s plats kanāls. Šis platums ir tieši piemērots. Bet ir satiksmes ierobežojums - 1 TB mēnesī. Tāpēc, lai ievērotu satiksmes ierobežojumus, mana izejošā plūsma nedrīkst pārsniegt ~300 KB sekundē t.i. Izejošās straumes bitu pārraides ātrumam nevajadzētu pārsniegt 2,5 Mbit/s. YouTube, starp citu, iesaka apraidi ar šo bitu pārraides ātrumu.
Lai regulētu sistēmas slodzi, ffmpeg izmanto dažādas pieejas. Par šo labi uzrakstīts . Es beidzot izmantoju divus atribūtus: -crf и -preset.
Pastāvīgās likmes faktors (CRF) - tas ir koeficients, ar kuru jūs varat pielāgot attēla kvalitāti. CRF var būt vērtības no 0 līdz 51, kur 0 ir avota faila kvalitāte, 51 ir sliktākā iespējamā kvalitāte. Ieteicams izmantot vērtības no 17 līdz 28, noklusējuma vērtība ir 23. Ar koeficientu 17 video vizuāli būs identisks oriģinālam, taču tehniski tas nebūs vienāds. Dokumentācijā arī norādīts, ka gala video izmērs atkarībā no norādītā CRF mainās eksponenciāli, t.i. palielinot koeficientu par 6 punktiem, izejošā video bitu pārraides ātrums tiks dubultots.
Ja izmantojat CRF, varat izvēlēties izejošā attēla “svaru”, pēc tam izmantojot iepriekšējie iestatījumi (-preset) jūs varat noteikt, cik smagi procesors tiks noslogots. Šim atribūtam ir šādi parametri:
ultrafastsuperfastveryfastfasterfastmedium- noklusējuma vērtībaslowslowerveryslow
Jo “ātrāk” tiek norādīts parametrs, jo lielāka būs procesora slodze.
Vispirms es izvēlējos sākotnējo iestatījumu, kas būtībā bija pārāk grūts manam procesoram, un pēc tam precīzāk atlasīju slodzi, izmantojot CRF. Manā gadījumā iepriekšējais iestatījums darbojās fast, un crf es izvēlējos vērtību 24.
Secinājums
Tas ir viss. Pēdējā komanda apraides sākšanai bija šāda:
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/%КЛЮЧ_ТРАНСЛЯЦИИ%Šeit ir palikuši tikai divi neaprakstīti punkti:
1) -c:v libx264 – norādot konkrētu kodeku darbam ar avota failu.
2) -g 3 – skaidra norāde par atslēgu kadru skaitu. Šajā gadījumā ir norādīts, ka katram trešajam kadram jābūt atslēgas kadram. Standarta vērtība ir 5 vai 8, bet YouTube zvēr un pieprasa vismaz 3.
Var redzēt, kāda kvalitatīva izrādījās pārraide .
Servera slodze bija šāda:
Pamatojoties uz monitoringa datiem, ir skaidrs, ka procesora noslodze svārstās no 70% līdz 95% un nedēļas laikā pārraide ne reizi nesasniedza 100%. Tas nozīmē, ka ar šiem iestatījumiem procesoram pietiek.
Ielādējot disku varu teikt, ka tas gandrīz nav ielādēts un apraidei vajadzētu pietikt ar parastu HDD.
Taču mani uztrauc izejošās satiksmes apjoms. Izrādās, ka mana izejošā straume svārstās no 450 līdz 650 KB sekundē. Mēneša laikā tas būs aptuveni 1,8 terabaiti. Jums var būt nepieciešams iegādāties papildu trafiku vai pārslēgties uz konfigurāciju ar diviem kodoliem, jo... Es negribētu samazināt attēla kvalitāti.
***
Rezultātā teikšu, ka šādas pārraides iestatīšana no nulles aizņem apmēram 1-2 stundas. Turklāt video augšupielāde serverī aizņems lielāko daļu laika.
Šādas pārraides palaišana neattaisnojās kā mārketinga instruments. Iespējams, ja palielinātu skatījumu skaitu, lai YouTube algoritmi uztvertu šo pārraidi un sāktu to aktīvi rādīt ieteikumos, kaut kas izdotos. Manā gadījumā 16 nepārtrauktas pārraides dienās tas tika noskatīts 58 reizes.
Tas ir ok. Raidījums harmoniski iederas manas mājaslapas galvenajā lapā. Tas man deva iespēju ātri izveidot savu viedokli par pasniedzēju un pašām lekcijām.
Un vienu brīdi. Ir svarīgi, lai pārraide nepārkāptu neviena autortiesības, pretējā gadījumā tā tiks bloķēta. Esmu mierīgs par savu raidījumu, jo... Es speciāli izvēlējos mūzikas ieliktņus ar brīvu lietošanu, un satura autore sēž pie blakus datora un nemaz neiebilst, ka es izmantoju viņas saturu :)
Bet, ja jūsu apraides laikā fonā skan radio vai rediģēšanas laikā izmantojāt savu iecienītāko ierakstu vai paņēmāt video secību no populāra mūzikas videoklipa, TV seriāla vai filmas, jūsu apraide ir apdraudēta. Ir arī svarīgi, lai apraide veic vismaz minimālu semantisko slodzi, pretējā gadījumā tā var tikt bloķēta kā surogātpasts.
***
Tas ir viss, kas man ir. Es ceru, ka šī rokasgrāmata kādam noderēs. Nu, ja jums ir kas piebilstams, rakstiet, ar prieku izlasīšu raksta papildinājumus un precizējumus.
Avots: www.habr.com