I det siste, som en hobby, har jeg filmet forelesninger av en psykolog jeg kjenner. Jeg redigerer opptakene og publiserer det på nettstedet mitt. For en måned siden fikk jeg ideen om å organisere en 24/7-sending av disse forelesningene på YouTube. En slags tematisk "TV-kanal" dedikert til personlig vekst.
Jeg vet hvordan jeg lager en vanlig sending. Men hvordan gjøre det slik at det er en kringkasting av videofiler? Slik at den kjører 24/7, er fleksibel, så autonom som mulig, og samtidig ikke på noen måte er avhengig av hjemmedatamaskinen min. Det var dette jeg måtte finne ut.
Det tok flere dager å finne en løsning. Jeg studerte mange fora og forskjellige manualer uten hvilke sendingen min rett og slett ikke ville ha fungert. Og nå som spøken er en suksess, føler jeg et behov for å dele løsningen min. Slik så denne artikkelen ut.
Kort fortalt ble den endelige løsningen som følger: VPS + ffmeg + bash-skript. Under kuttet beskriver jeg grepene som er tatt og snakker om fallgruvene som ble oppdaget ved organisering av sendingen.
Trinn 1 – hvor kommer sendingen fra?
Helt i begynnelsen var det nødvendig å bestemme hvor sendingen skulle komme fra og hvor kilden skulle være. Det aller første som kom til tankene var fra hjemmedatamaskinen. Samle videoer i en spilleliste og begynn å spille dem i en hvilken som helst videospiller. Ta deretter skjermbildet og kringkast det til YouTube. Men jeg avviste nesten umiddelbart dette alternativet fordi... For å implementere det må du holde hjemmedatamaskinen på konstant, noe som betyr støy fra kjølere selv om natten og økt strømforbruk (+100-150 kWh hver måned). Og det viser seg at du ikke vil kunne bruke hjemmedatamaskinen din under sendingen. enhver bevegelse av musen vil være synlig i sendingen.
Så begynte jeg å se til siden skytjenester. Jeg var på utkikk etter en ferdig tjeneste hvor jeg kunne laste opp videoene mine eller for eksempel sette inn lenker til videoer fra YouTube og det hele pakkes inn i én non-stop sending. Men jeg fant ikke noe passende. Kanskje jeg ikke søkte godt. Det eneste som passer til funksjonaliteten er restream.io, en tjeneste som hjelper til med å sende samtidig til flere plattformer. De ser ut til å tillate deg å laste opp dine egne videoer. Men denne tjenesten ble laget for helt andre formål, og de forventer at sendingen vil vare bare et par timer. Jeg tror at hvis det gjennom denne tjenesten ville være mulig å organisere en døgnkontinuerlig sending, så ville det skyte opp i titalls, eller til og med hundrevis av dollar per måned. Men jeg ønsket fortsatt å organisere sendingen enten gratis eller med minimale økonomiske investeringer.
Det ble klart at for sendingen var det nødvendig eller separat enhet eller til og med en separat datamaskin. Jeg tenkte på noe som Raspberri Pi. Og hva? Han har ikke kjøler. Jeg tok opp videoen på en flash-stasjon, plugget inn Ethernet-kabelen og lot den ligge et sted på et bortgjemt sted og kringkaste den. Alternativ. Men jeg hadde verken selve styret eller erfaring med å jobbe med det, så jeg takket også nei til dette alternativet.
Som et resultat kom jeg over en viss diskusjon der de diskuterte skapelsen egen server sendinger. Det var ikke akkurat det jeg lette etter, men jeg fikk hovedideen - du kan bruke en server! I den diskusjonen ble det foreslått å bruke en kombinasjon av VPS + nginx + OBS. Det ble klart at denne kombinasjonen kunne passe meg også. Det eneste som forvirret meg var at jeg aldri hadde administrert en server, og det virket for meg at det var forvirrende og dyrt å ha min egen dedikerte server. Jeg bestemte meg for å finne ut hvor mye det ville koste å leie en server med minimumskonfigurasjon og ble positivt overrasket.
Prisene er angitt i hviterussiske rubler, og disse er bare smuler. For å forstå er 8 hviterussiske rubler omtrent 3.5 dollar eller 240 russiske rubler. For en måned med bruk av en fullverdig datamaskin som er slått på 24/7 og har rask Internett-tilgang. Av en eller annen grunn ble denne oppdagelsen veldig gledelig for meg og i flere dager gikk jeg fryktelig glad rundt, som et barn som oppdaget romraketter :)
Forresten, jeg benyttet meg av tilbudet fra det første nettstedet som Google ga meg for søket "VPS-utleie". Kanskje det er enda flere budsjettløsninger, men denne prisen passet meg og jeg så ikke lenger.
Når du oppretter en server, kan du velge hvilket operativsystem den skal kjøres under. Du kan organisere en kringkasting på alle de listede systemene og gjøre et valg basert på dine preferanser og økonomiske muligheter (for en server med Windows ber de om en ekstra avgift). Jeg valgte CentOS. Rett og slett fordi jeg hadde lite erfaring med det fra før.
Trinn 2 – serveroppsett
Det første du trenger etter å ha opprettet en server er å koble til den via SSH. Først brukte jeg PuTTy, men så begynte jeg å bruke Secure Shell-appen, som kjører i Google Chrome. Det viste seg å være mer praktisk for meg.
Så endret jeg vertsnavnet, satte opp tidssynkronisering på serveren, oppdaterte systemet, tullet med iptables... og gjorde en haug med andre ting, men ikke fordi det var nødvendig. Jeg var bare interessert i å sette opp serveren, og det fungerte for meg. Jeg elsker det når det ordner seg :)
Her er trinnene du må ta:
- Koble til EPEL-depotet.
- Sett opp en FTP-server (jeg valgte vsftp).
- Installer ffmpeg.
Jeg vil ikke gi kommandoene i detalj; disse instruksjonene er ganske konseptuelle for å formidle den generelle handlingsplanen. Hvis du har problemer med noen av trinnene, kan de raskt løses ved å bruke en søkemotorspørring som "CentOS koble til EPEL" eller "CentOS installer FTP-server". Og på de første lenkene kan du finne detaljerte trinnvise instruksjoner.
Så, som jeg skrev tidligere, trengte jeg en kombinasjon av VPS + nginx + OBS. VPS – klar. Men spørsmål begynte å dukke opp på andre punkter. OBS er et kringkastingsprogram, Open Broadcaster Software. Og det fungerer kun med strømmer dvs. for eksempel tar den et bilde fra et webkamera og kringkaster det. Eller skjermopptak. Eller en allerede pågående sending blir omdirigert til et annet nettsted. Men jeg har ikke en strøm, jeg har bare et sett med videofiler som må gjøres til en strøm.
Jeg begynte å grave i denne retningen og kom over ffmpeg. FFmpeg er et sett med gratis og åpen kildekode-biblioteker som lar deg ta opp, konvertere og streame digital lyd og video i en rekke formater.
Og jeg ble veldig overrasket over hvor mye ffmpeg kan gjøre. Hvis du vil, vil den trekke ut lyden fra videoen. Hvis du vil, vil den kutte ut et fragment av videoen uten omkoding. Hvis du vil, vil den konvertere fra ett format til et annet. Og mye, mye mer. Til det punktet at du kan spesifisere en fil til den, vil den konvertere den til en strøm og overføre den til YouTube selv. Det er det, kjeden er satt sammen. Det gjenstår bare å avslutte nyansene.
Trinn 3 – kringkastingsoppsett
Vi lager en sending på YouTube. På dette stadiet trenger vi bare lenken og kringkastingsnøkkelen. I skjermbildet nedenfor er de uthevet i rødt.
Neste last opp videofiler til serveren, som vi planlegger å kringkaste. Faktisk er FTP bare nødvendig for dette stadiet. Hvis du har en annen praktisk måte å laste opp filer til serveren på, trenger du ikke å sette opp en FTP-server.
Vi overfører strømmen til YouTube. For å starte kringkasting må du kjøre ffmpeg med flere attributter. Slik ser den korteste kommandoen jeg fikk ut:
ffmpeg -re -i lecture1.mp4 -f flv rtmp://a.rtmp.youtube.com/live2/%КЛЮЧ_ТРАНСЛЯЦИИ%
Attributtdekoding-re – indikerer at filen må konverteres til en strøm.
-i – indikerer hvilken fil som skal spilles av. Det er viktig at kommandoen startes fra samme katalog der selve videofilen er plassert. Ellers bør du spesifisere en absolutt lenke til filen, som /usr/media/lecture1.mp4.
-f – setter utdatafilformatet. I mitt tilfelle viser det seg at ffmpeg konverterer filen min fra mp4 til flv on the fly.
Og til slutt viser vi dataene vi tok fra YouTube på siden for kringkastingsinnstillinger, dvs. adressen du skal overføre data til, og kringkastingsnøkkelen, slik at sendingen vises spesifikt på kanalen din.
Hvis du gjorde alt riktig, vil YouTube se den overførte strømmen etter å ha kjørt denne kommandoen. For å starte sendingen trenger du bare å klikke på "Start kringkasting"-knappen i selve YouTube.
Trinn 4 – legg til autonomi
Gratulerer! Nå vet du hvordan du begynner å kringkaste fra en videofil. Men dette er ikke nok for XNUMX/XNUMX kringkasting. Det er viktig at etter at den første videoen er ferdig avspilt, starter den neste umiddelbart, og når alle videoene vises, starter avspillingen igjen.
Jeg kom opp med følgende alternativ: lag en .sh-fil der jeg skrev en kommando for hver videofil og helt på slutten indikerte en kommando for å kjøre det samme skriptet igjen. Resultatet er en rekursjon som dette:
Команда 1... (запуск трансляции файла lecture1.mp4)
Команда 2... (запуск трансляции файла lecture2.mp4)
Команда 3... (запуск трансляции файла lecture3.mp4)
bash start.shOg ja, det fungerte. Fornøyd med meg selv lanserte jeg en prøvesending og la meg.
Om morgenen ventet en ubehagelig overraskelse på meg. Det viste seg at sendingen bare varte i et par minutter og ble avsluttet nesten umiddelbart da jeg slo av datamaskinen. Undersøkelsen viste at kommandoer som ble lansert på denne måten, utføres mens brukeren er logget inn på serveren. Så snart jeg koblet fra, ble kommandoene jeg kjørte avbrutt. For å forhindre at dette skjer, er det nok foran laget bash legg til kommandoen nohup. Dette vil tillate kjøreprosessen å kjøre uavhengig av din tilstedeværelse.
Den endelige minimale versjonen av skriptet ser slik ut:
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 $Hvor start.sh er filen som dette skriptet er skrevet i. Og denne filen må være plassert i samme katalog som videofilene.
Hvis du legger til et dollartegn på slutten, kan prosessen kjøres i bakgrunnen, slik at du kan fortsette å bruke konsollen uten å avbryte sendingen.
Bonusene inkluderte følgende godbiter:
- Du kan bytte filavspilling manuelt. For å gjøre dette, må du "drepe" ffmpeg-prosessen som kjører for øyeblikket. Etter dette starter avspillingen av neste fil fra listen automatisk.
- Nye videoer kan legges til sendingen uten å stoppe sendingen. Bare last opp videoen til serveren, legg til en kommando for å kjøre denne filen i skriptet og lagre den. Det er alt. På neste runde med avspilling vil den nye filen bli kringkastet sammen med de gamle filene.
Trinn 5 – tilpass ffmpeg
I prinsippet kunne vi ha stoppet der. Men jeg ville gjøre sendingen litt mer vennlig for seerne.
La oss si at en person gikk til sendingen, begynte å se, likte den og ønsket å se denne forelesningen fra begynnelsen, men sendingen tillater ikke spole tilbake. For å se en forelesning fra begynnelsen, må en person gå til nettstedet mitt og få et opptak av forelesningen av interesse. Hvordan kan du fortelle hvilket foredrag som interesserer ham? Det er allerede 16 forelesninger på siden og det er bare flere av dem hver uke. Jeg tror at selv jeg, som har filmet og redigert alle disse forelesningene, ikke vil kunne fastslå ut fra et tilfeldig fragment hvilken forelesning det er. Derfor er det nødvendig at hver forelesning på en eller annen måte blir utpekt.
Muligheten for å legge til bildetekster til kildevideofilene i redigeringsprogrammet passet ikke meg. Det var nødvendig å sikre at de originale filene ble brukt. Så det å støtte sendingen krever minst mulig kroppsbevegelser av meg.
Det viste seg at ffmpeg kunne hjelpe meg med dette også. Den har en spesiell egenskap -vf, som gjør at tekst kan plasseres over video. For å legge til tekst i en video, må du legge til følgende fragment til kommandoen:
-vf drawtext="fontfile=OpenSans.ttf:text='Лекция 13: Психология эмоций. Как создавать радость?':fontsize=26:fontcolor=white:borderw=1:bordercolor=black:x=40:y=670"
Forklaring av parameterefontfile= – lenke til fontfilen. Uten dette vil ikke bildeteksten bli lagt til videoen. Den enkleste måten er å legge fontfilen i samme mappe som videoen. Eller du må spesifisere hele banen til filen.
text= – faktisk selve teksten som må plasseres på toppen av videoen.
fontsize= – skriftstørrelse i piksler.
fontcolor= - skriftfarge.
borderw= – tykkelsen på omrisset rundt teksten i piksler (jeg har hvit tekst med en svart kontur 1 piksel tykk).
bordercolor= – konturfarge.
x= и y= – tekstkoordinater. Punktum 0;0 er plassert i øvre venstre hjørne. Koordinatene mine er valgt på en slik måte at teksten plasseres i nedre venstre hjørne med en videooppløsning på 1280x720 piksler.
Det ser slik ut:
Trinn 6 – bestem kvaliteten på sendingen
Det er det, sendingen er klar. FFmpeg kringkaster, filer spilles av, min tilstedeværelse er ikke nødvendig for kringkasting. Til og med hvert foredrag er signert. Ser ut som det er det.
Men en nyanse til dukket opp - jeg valgte minimumsserverkonfigurasjonen, og den trakk ikke opp sendingen. Serverkonfigurasjon: 1 kjerne (som 2.2 GHz), 1 gigabyte RAM, 25 GB SSD. Det var nok RAM, men prosessoren var nesten fullstendig lastet på 100% (og til tider til og med 102-103% :) Dette førte til at sendingen fryste med noen sekunders mellomrom. Ikke hyggelig.
Du kan ganske enkelt ta en dyrere konfigurasjon med to kjerner, heldigvis, med skyteknologier, endres serverkonfigurasjonen ved å trykke på et par knapper. Men jeg ønsket å passe inn i minimum konfigurasjonskapasitet. Jeg begynte å studere ffmpeg-dokumentasjonen og ja, det er også innstillinger der som lar deg regulere belastningen på systemet.
Høy bildekvalitet kan oppnås på to måter: enten høy CPU-belastning eller høy utgående trafikk. Det viser seg at jo mer belastning prosessoren kan ta på seg, jo mindre kanalbåndbredde vil være nødvendig. Eller du kan ikke belaste prosessoren for mye, men da trenger du en bred kanal med stor trafikkhøyde. Hvis det er begrensninger på både prosessor og størrelsen på utgående kanal/trafikk, så må du redusere kvaliteten på bildet slik at sendingen går greit.
Serveren min har tilgang til en 10 Mbit/s bred kanal. Denne bredden er akkurat passe. Men det er en trafikkgrense - 1 TB per måned. Derfor, for å møte trafikkrestriksjoner, bør min utgående flyt ikke overstige ~300 KB per sekund, dvs. Bithastigheten til den utgående strømmen bør ikke være mer enn 2,5 Mbit/s. YouTube anbefaler forresten å kringkaste med denne bithastigheten.
For å regulere belastningen på systemet, bruker ffmpeg forskjellige tilnærminger. Godt skrevet om dette . Jeg endte opp med å bruke to attributter: -crf и -preset.
Konstant hastighetsfaktor (CRF) – dette er en koeffisient som gjør at du kan justere kvaliteten på bildet. CRF kan ha verdier fra 0 til 51, hvor 0 er kvaliteten på kildefilen, 51 er dårligst mulig kvalitet. Det anbefales å bruke verdier fra 17 til 28, standard er 23. Med en koeffisient på 17 vil videoen være visuelt identisk med originalen, men teknisk sett vil den ikke være den samme. I dokumentasjonen står det også at størrelsen på den endelige videoen, avhengig av spesifisert CRF, endres eksponentielt, dvs. å øke koeffisienten med 6 poeng vil doble bithastigheten til den utgående videoen.
Hvis du bruker CRF kan du velge "vekten" til det utgående bildet, og deretter bruke forhåndsinnstillinger (-forhåndsinnstilling) du kan bestemme hvor tungt prosessoren skal belastes. Dette attributtet har følgende parametere:
ultrafastsuperfastveryfastfasterfastmedium- standardverdislowslowerveryslow
Jo "raskere" parameteren er spesifisert, jo høyere blir belastningen på prosessoren.
Jeg valgte først en forhåndsinnstilling som i utgangspunktet var for tøff for prosessoren min, og valgte deretter belastningen mer fint ved hjelp av CRF. I mitt tilfelle fungerte forhåndsinnstillingen fast, og for crf slo jeg meg på verdien 24.
Konklusjon
Det er alt. Den siste kommandoen for å starte sendingen var denne:
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/%КЛЮЧ_ТРАНСЛЯЦИИ%Det er bare to ubeskrevne punkter igjen her:
1) -c:v libx264 – spesifisere en spesifikk kodek for arbeid med kildefilen.
2) -g 3 – eksplisitt angivelse av antall nøkkelrammer. I dette tilfellet er det spesifisert at hver tredje ramme skal være en nøkkelramme. Standardverdien er enten 5 eller 8, men YouTube sverger og ber om minst 3.
Du kan se hvilken kvalitet sendingen viste seg å være .
Belastningen på serveren var som følger:
Basert på overvåkingsdataene er det klart at prosessorbelastningen varierer fra 70 % til 95 % og i løpet av uken nådde sendingen aldri 100 %. Dette betyr at med disse innstillingene er prosessoren nok.
Ved å laste inn disken kan jeg si at den nesten ikke er lastet inn og en vanlig HDD burde være nok for kringkasting.
Men mengden utgående trafikk bekymrer meg. Det viser seg at min utgående strøm varierer fra 450 til 650 KB per sekund. Om en måned vil dette være ca 1,8 terabyte. Du må kanskje kjøpe ekstra trafikk eller bytte til en konfigurasjon med to kjerner fordi... Jeg vil ikke redusere kvaliteten på bildet.
***
Som et resultat vil jeg si at å sette opp en slik sending fra bunnen av tar omtrent 1-2 timer. Dessuten vil opplasting av videoen til serveren ta mesteparten av tiden.
Lanseringen av en slik sending rettferdiggjorde seg ikke som et markedsføringsverktøy. Kanskje, hvis vi øker visningene slik at YouTube-algoritmer fanger opp denne sendingen og begynner å aktivt vise den i anbefalinger, vil noe fungere. I mitt tilfelle ble den sett 16 ganger på 58 dager med kontinuerlig sending.
Det er ok. Sendingen passer harmonisk inn på hovedsiden på nettstedet mitt. Dette ga meg muligheten til raskt å danne meg min egen mening om foreleseren og selve forelesningene.
Og ett øyeblikk. Det er viktig at sendingen ikke bryter noens opphavsrett, ellers blir den blokkert. Jeg er rolig med sendingen min fordi... Jeg valgte spesifikt musikkinnlegg med fri bruk, og forfatteren av innholdet sitter ved en datamaskin i nærheten og er slett ikke imot at jeg bruker innholdet hennes :)
Men hvis du har en radio som spiller i bakgrunnen et sted i sendingen, eller du brukte favorittsporet ditt under redigering, eller tok en videosekvens fra en populær musikkvideo, TV-serie eller film, er sendingen i fare. Det er også viktig at sendingen har minst en minimal semantisk belastning, ellers kan den bli blokkert som spam.
***
Det er alt jeg har. Jeg håper denne manualen vil tjene noen godt. Vel, hvis du har noe å legge til, skriv, jeg vil gjerne lese tilleggene og forklaringene til artikkelen.
Kilde: www.habr.com