kohë e fundit si hobi regjistroj në video ligjeratat e një psikologu që njoh. Materialin e xhiruar e redaktoj dhe e publikoj në faqen time. Një muaj më parë u kapa me idenë për të organizuar një transmetim të përhershëm të këtyre ligjeratave në YouTube në mënyrë 24/7. Një lloj "kanali tematik", i dedikuar rritjes personale.
E di se si të bëj një transmetim të zakonshëm. Por si të bëj që kjo të jetë një transmetim i video-dosjeve? Që të jetë 24/7, fleksibël, sa më autonom dhe që të mos varet fare nga kompjuteri im shtëpiak. Kjo ishte ajo që doja të zbuloja.
Më mori disa ditë për të gjetur një zgjidhje. Studova shumë forume dhe manuale të ndryshme që pa të cilat transmitimi im thjesht nuk do të kishte funksionuar. Dhe tani, kur aventura ka arritur sukses, ndiej nevojën për të ndarë zgjidhjen time. Kështu lindi ky artikull.
Nëse flasim shkurt, zgjidhja përfundimtare doli të ishte kështu: VPS + ffmpeg + skript bash.Poshtë, përshkruaj hapat e ndjekur dhe ndajnë "shkëmbinjtë" që u shpërfaqën gjatë organizimit të transmetimit.
Hapi 1 â nga do tĂ« vijĂ« transmetimi?
Në fillim duhej të vendosja nga do të bëhej transmetimi, ku do të ishte burimi i tij. E para që më erdhi në mendje ishte nga kompjuteri shtëpiak.Të mbledh video në një playlist dhe të filloj të luaj ato në një lojtar video. Pastaj të kap imazhin nga ekrani dhe ta transmetoj atë në YouTube. Por e hodha menjëherë këtë mundësi sepse për ta realizuar duhej të mbahej kompjuteri shtëpiak gjithmonë i ndezur, dhe kjo do të thoshte zhurma nga ventilatorët edhe natën dhe rritja e konsumit të energjisë elektrike (+100-150 kWh çdo muaj). Pra, nuk do të mund të përdorja kompjuterin shtëpiak gjatë transmetimit sepse çdo lëvizje e miut do të ishte e dukshme në transmetim.
Pastaj fillova të shikoj në drejtimin e shërbimeve cloud.Kërkova një shërbim të gatshëm, ku mund të ngarkoja videot e mia ose, për shembull, të fus linke nga videot në YouTube dhe që kjo të paketonte gjithçka në një transmetim nonstop. Por nuk gjetëm asgjë të përshtatshme. Ndoshta kërkova keq. E vetmja diçka që ishte ± e përshtatshme për funksionalitetin ishte restream.io, një shërbim që ndihmon në transmetimin e përbashkët në disa platforma. Ata duket se lejojnë ngarkimin e videove. Por ky shërbim ishte krijuar për qëllime krejt të tjera dhe ata presin që transmetimi të zgjasë vetëm disa orë. Mendoj se nëse përmes këtij shërbimi do të ishte e mundur organizimi i një transmetimi të përhershëm, do të kushtonte dhjetëra, ndoshta edhe qindra dollarë në muaj. Por dëshiroja që të organizohej transmetimi ose falas, ose me investime financiare minimale.
Ishte e qartë se për transmetimin nevojitej ose një pajisje e veçantë apo madje edhe një kompjuter të veçantë. Mendova për diçka si Raspberri Pi. Pse jo? Ai nuk ka ventilator. Regjistrova videon në një USB, e futa kabllon Ethernet dhe e la të qetë diku në një vend të fshehur, duke realizuar transmetimin. Një mundësi. Por nuk kisha as bordin as eksperiencën e punës me të, kështu që e hoqa këtë mundësi po ashtu.
NĂ« fund, natĂ«n e natyrshme, pashĂ« njĂ« diskutim ku flisnin pĂ«r krijimin e njĂ« serveri pĂ«r transmetim. Kjo nuk ishte krejt ajo qĂ« po kĂ«rkoja, por e kuptova idenĂ« â mund tĂ« pĂ«rdorim njĂ« server! NĂ« atĂ« diskutim sugjerohej tĂ« pĂ«rdoret kombinimi VPS + nginx + OBS. U bĂ« e qartĂ« se ky kombinim mund tĂ« mĂ« pĂ«rfshihet edhe mua. VetĂ«m se mĂ« shqetĂ«sonte se kurrĂ« nuk kisha administruar servera dhe mĂ« dukej se njĂ« server i dedikuar ishte i komplikuar dhe i shtrenjtĂ«. Vendosa tĂ« verifikoja sa do tĂ« kushtonte tĂ« merrja me qira njĂ« server nĂ« konfigurimin minimal dhe u befasova pĂ«r mirĂ«.
Ămimet janĂ« tĂ« shĂ«nuara nĂ« rubla bjellorus dhe janĂ« thjesht fara. PĂ«r tĂ« kuptuar, 8 rubla bjellorus janĂ« rreth 3.5 dollarĂ« ose 240 rubla ruse. PĂ«r muajin e pĂ«rdorimit tĂ« njĂ« kompjuteri tĂ« plotĂ«, i cili Ă«shtĂ« i ndezur 24/7 dhe ka qasje tĂ« shpejtĂ« nĂ« Internet. PĂ«r çudi, ky zbulim ishte shumĂ« i kĂ«ndshĂ«m pĂ«r mua dhe disa ditĂ« e kalova jashtĂ«zakonisht i kĂ«naqur si njĂ« fĂ«mijĂ« qĂ« ka zbuluar raketat kozmike đ
Për më tepër, unë përdora ofertën e faqes së parë që më dha Google për pyetjen "qira VPS". Ndoshta ka ndonjë zgjidhje më të përballueshme, por kjo çmim më përkoi dhe nuk kërkova më tej.
Kur krijoni një server, mund të zgjidhni sistemin operativ nën të cilin do të punojë. Në çdo një nga sistemet e listuara mund të organizoni transmetim dhe zgjedhja duhet të bazohet në preferencat dhe mundësitë tuaja financiare (për serverin me Windows kërkohet një pagesë shtesë). Unë zgjodha CentOS. Thjesht sepse kisha një përvojë të vogël me të më parë.
Hapi 2 â konfigurimi i serverit
Gj thingi i parë që duhet bërë pas krijimit të serverit është të lidhemi me të përmes SSH. Në fillim përdorja PuTTy, por më pas fillova të përdorja aplikacionin Secure Shell App, i cili hapet në Google Chrome. Më dukej më i përshtatshëm.
Pastaj e ndryshova emrin e hostit, konfigurimin e sinkronizimit tĂ« kohĂ«s nĂ« server, pĂ«rmirĂ«sova sistemin, merrem me iptables⊠dhe bĂ«ra shumĂ« gjĂ«ra tĂ« tjera, por jo sepse ishte e domosdoshme. Thjesht mĂ« interesonte tĂ« konfigurja serverin dhe mĂ« dukej se po ia dilja mbanĂ«. MĂ« pelqen kur ia dal đ
Ja këtu janë hapat që duhet të bëhen:
- TĂ« lidhni depozitat EPEL.
- Të ngremë një server FTP (unë zgjodha vsftp).
- Të instalojmë ffmpeg.
Nuk do të përmend detaje të komandave, kjo udhëzim është më shumë konceptual, për të përcjellë planin e përgjithshëm të veprimit. Nëse hasni ndonjë vështirësi në ndonjë nga hapat, mund të zgjidhni shpejt atë me një kërkesë në motorin e kërkimit si "CentOS lidhe EPEL" ose "CentOS instalim FTP serveri". Dhe në lidhjet e para do të mund të gjeni udhëzime të detajuara hap pas hapi.
Pra, siç kam thĂ«nĂ« mĂ« parĂ«, mĂ« nevojitej njĂ« kombinim VPS + nginx + OBS. VPS â gati. Por pĂ«r pjesĂ«t e tjera filluan tĂ« lindnin pyetje. OBS â kjo Ă«shtĂ« njĂ« program pĂ«r transmetime, Open Broadcaster Software. Dhe ai punon vetĂ«m me rrjedha, domethĂ«nĂ«, merr imazhin nga njĂ« webcam dhe e transmeton. Ose regjistrimin e ekranit. Ose njĂ« transmetim qĂ« ka filluar tashmĂ« e drejton nĂ« njĂ« faqe tjetĂ«r. Por unĂ« nuk kam njĂ« rrjedhĂ«, kam vetĂ«m njĂ« grup videosh qĂ« duhen bĂ«rĂ« si njĂ« rrjedhĂ«.
KĂ«shtu fillova tĂ« hetoj nĂ« kĂ«tĂ« drejtim dhe u ndesha me ffmpeg. FFmpeg â Ă«shtĂ« njĂ« grumbull librash me burim tĂ« hapur qĂ« lejojnĂ« regjistrimin, konvertimin dhe transmetimin e audio dhe video digjitale nĂ« formate tĂ« ndryshme.
Dhe u habit shumĂ« sa shumĂ« mund tĂ« bĂ«jĂ« ffmpeg. DĂ«shiron â nxjerr zĂ«rin nga video. DĂ«shiron â prish njĂ« fragment video pa e rikoduar. DĂ«shiron â ta konvertojĂ« nga njĂ« format nĂ« njĂ« tjetĂ«r. Dhe shumĂ« e shumĂ« gjĂ«ra tĂ« tjera. Deri nĂ« atĂ« pikĂ« sa mund t'i japĂ«sh njĂ« skedar, ai e transformon atĂ« nĂ« njĂ« rrjedhĂ« dhe vetĂ« e transmeton nĂ« YouTube. Tani, zinxhiri Ă«shtĂ« ndĂ«rtuar. Ka mbetur vetĂ«m tĂ« pĂ«rfundoj detajet.
Hapi 3 â konfigurimi i transmetimit
Krijojmë një transmetim në YouTube. Në këtë hap na nevojitet vetëm lidhja dhe çelësi i transmetimit. Në ekranin e mëposhtëm ata janë theksuar me të kuqe.
Më pas ngarkojmë skedarët video në server, të cilët planifikojmë të transmetojmë. Pjesërisht, FTP është i nevojshëm vetëm për këtë fazë. Nëse keni ndonjë mënyrë tjetër të përshtatshme për ngarkim skedarësh në server, atëherë nuk është e nevojshme të ngrehim serverin FTP.
Transmetojmë rrjedhën në YouTube. Për të filluar transmetimin, duhet të startoni ffmpeg me disa atribute. Këtu është si duket komanda më e shkurtër që kam arritur:
ffmpeg -re -i lecture1.mp4 -f flv rtmp://a.rtmp.youtube.com/live2/%ĂELSI_TRANSMETIMIT% Shpjegimi i atributeve-re â tregon se skedari duhet tĂ« konvertohet nĂ« njĂ« rrjedhĂ«.
-i â tregon se cili skedar duhet tĂ« luhet. ĂshtĂ« e rĂ«ndĂ«sishme qĂ« komanda tĂ« ekzekutohet nga e njĂ«jta katalog ku ndodhet skedari video. NĂ« tĂ« kundĂ«rt, duhet tĂ« pĂ«rcaktoni lidhjen absolute te skedari, siç Ă«shtĂ« /usr/media/lecture1.mp4.
-f â pĂ«rcakton formatin e skedarit tĂ« dalĂ«. NĂ« rastin tim, kjo do tĂ« thotĂ« qĂ« ffmpeg "nĂ« flakĂ«" konverton skedarin tim nga mp4 nĂ« flv.
Dhe në fund tregojmë të dhënat që morëm në YouTube në faqen e konfigurimit të transmetimit, dmth. adresën në të cilën duhet të dërgojmë të dhënat, dhe çelësi i transmetimit, për që transmetimi të shfaqet pikërisht në kanalin tuaj.
Nëse keni bërë gjithçka siç duhet, atëherë pasi të aktivizoni këtë komandë, YouTube do të shohë rrjedhën e transmetuar. Për të nisur transmetimin, ju mbetet vetëm të klikoni butonin "Nis transmetimin" në vetë YouTube.
Hapi 4 â shtojmĂ« autonominĂ«
Urime! Tani e dini se si tĂ« filloni njĂ« transmetim nga njĂ« skedar video. Por kjo nuk Ă«shtĂ« e mjaftueshme pĂ«r njĂ« transmetim 24-orĂ«sh. ĂshtĂ« e rĂ«ndĂ«sishme qĂ« pas pĂ«rfundimit tĂ« luajtjes sĂ« videos sĂ« parĂ«, tĂ« nisĂ« menjĂ«herĂ« videoja tjetĂ«r, dhe kur tĂ« shfaqen tĂ« gjitha videot, tĂ« fillojĂ« fillimisht nga e para.
Kam menduar për një variant të tillë: të krijoj një skedar .sh, në të cilin shkruaj një komandë për çdo skedar video dhe në fund të tregoj një komandë për të nisur përsëri këtë skript. Kështu u krijua një lloj rekurence:
Komanda 1... (nisja e transmetimit të skedarit lecture1.mp4)
Komanda 2... (nisja e transmetimit të skedarit lecture2.mp4)
Komanda 3... (nisja e transmetimit të skedarit lecture3.mp4)
bash start.shPo, po, kjo funksionoi. Unë, i kënaqur me veten, nisa një transmetim provues dhe shkuam të flija.
Në mëngjes më priste një surprizë e këndshme. Doli se transmetimi ka vazhduar vetëm disa minuta dhe përfundoi pothuajse menjëherë sapo e fikja kompjuterin tim. Hetimi tregoi se komandat e nisura në atë mënyrë ekzekutohen për sa kohë që përdoruesi është i autorizuar në server. Sapo u lidh, ekzekutimi i komandave të mia u ndërpre. Për të shmangur këtë, mjafton të shtoni komandën bash për të shkruar komandën nohup. Kjo do t'i mundësojë procesit të hapur të vazhdojë të ekzistojë pavarësisht nga praninë tuaj.
Versioni minimal përfundimtar i skriptit duket kështu:
ffmpeg -re -i lecture1.mp4 -f flv rtmp://a.rtmp.youtube.com/live2/%ĂELSI_TRANSMETIMI%
ffmpeg -re -i lecture2.mp4 -f flv rtmp://a.rtmp.youtube.com/live2/%ĂELSI_TRANSMETIMI%
ffmpeg -re -i lecture3.mp4 -f flv rtmp://a.rtmp.youtube.com/live2/%ĂELSI_TRANSMETIMI%
nohup bash start.sh $Ku start.sh është skedari që përmban këtë skript. Ky skedar duhet të jetë në të njëjtin katalog me skedarët e videos.
Shtimi i shenjës së dollarit në fund lejon që procesi të startojë në mënyrë të sfondit, kështu që mund të vazhdoni të përdorni konsolën pa ndërprerë transmetimin.
Nga bonuset dolën disa përfitime:
- Mund të kaloni manualisht mes skedarëve të videos. Për këtë, duhet të "vrasni" procesin aktual të ffmpeg. Pas kësaj, do të fillojë automatikisht luajtja e skedarit të ardhshëm nga lista.
- Skedarë të rinj mund të shtohen në transmetim pa ndaluar transmetimin. Thjesht ngarkoni videon në server, shtoni komandën për të nisur këtë skedar në skript, ruani. Dhe gjithë. Në ciklin e ardhshëm të luajtjes, skedari i ri do të transmetohet së bashku me skedarët e vjetër.
Hapi 5 - përshtatni ffmpeg
Në këtë pikë, në parim mund të isha ndalur. Por më pëlqeu të bëja transmetimin pak më miqësor për shikuesit.
Supozoni se një person hyri në transmetim, filloi të shikonte, i pëlqeu dhe donte të shihte këtë ligjëratë nga fillimi, por transmetimi nuk parashikon avancimin. Për të parë ligjëratën nga fillimi, personi duhet të kalojë në faqen time dhe të marrë regjistrimin e ligjëratës që e intereson. E si mund të kuptojmë se cila ligjëratë e intereson? Në faqen e internetit tashmë ka 16 ligjërata dhe çdo javë bëhen edhe më shumë. Mendoj se edhe unë, që kam regjistruar dhe montuar të gjitha këto ligjërata, nuk do të mund të përcaktoj cila është kjo ligjëratë nga një fragment rastësor. Prandaj, duhet të bëhet që çdo ligjëratë të jetë e ndarë ndryshe.
Një mundësi për të shtuar mbishkrime në skedarët origjinalë të videos me programin e montimit nuk më kënaqte. Duhej të isha siguruar që të përdorësh skedarët origjinalë. Në mënyrë që mbështetja e transmetimit të kërkonte nga unë sa më pak lëvizje.
Doli se edhe në këtë mund të më ndihmojë ffmpeg. Ai ka një atribut të veçantë -vf, i cili lejon të shtoni tekst mbi videon. Për të shtuar tekst në video, duhet të shtoni fragmentin e mëposhtëm në komandë:
-vf drawtext="fontfile=OpenSans.ttf:text='LigjĂ«rata 13: Psikologjia e emocioneve. Si tĂ« krijoni gĂ«zim?':fontsize=26:fontcolor=white:borderw=1:bordercolor=black:x=40:y=670" Shpjegimi i parametravefontfile= â lidhja pĂ«r skedarin e shkrimit. Pa kĂ«tĂ«, mbishkrimi nĂ« video nuk shtohet. MĂ« e lehtĂ« Ă«shtĂ« tĂ« vendosni skedarin e shkrimit nĂ« tĂ« njĂ«jtĂ«n papkĂ« me videon. Ose do tĂ« duhet tĂ« tregoni rrugĂ«n e plotĂ« pĂ«r skedarin.
text= â vetĂ« teksti qĂ« duhet tĂ« vendoset mbi videon.
fontsize= â madhĂ«sia e shkrimit nĂ« piksel.
fontcolor= â ngjyra e shkrimit.
borderw= â trashĂ«sia e konturit rreth tekstit nĂ« piksel (unĂ« kam tekst tĂ« bardhĂ« me kontur tĂ« zi me trashĂ«si 1 piksel).
bordercolor= â ngjyra e konturit.
x= dhe y= â koordinatat e tekstit. Pika 0;0 gjenet nĂ« kĂ«ndin e majtĂ« tĂ« sipĂ«rm. UnĂ« kam koordinatat tĂ« vendosura nĂ« njĂ« mĂ«nyrĂ« qĂ« teksti tĂ« vendoset nĂ« kĂ«ndin e majtĂ« tĂ« poshtĂ«m pĂ«r njĂ« rezolutĂ« video 1280x720 piksel.
Kjo duket kështu:
Hapi 6 â pĂ«rcaktojmĂ« cilĂ«sinĂ« e transmetimit
Gjithçka, transmetimi është gati. FFmpeg transmeton, skedarët janë duke u luajtur, prania ime për transmetim nuk është e nevojshme. Edhe çdo ligjëratë është e shënuar. Duket gjithçka.
Por doli njĂ« tjetĂ«r nuancĂ« â unĂ« zgjodha konfigurimin minimal tĂ« serverit dhe ai nuk e mbante transmetimin. Konfigurimi i serverit: 1 bĂ«rthamĂ« (dukĂ«t 2.2 GHz), 1 gigabajt RAM, SSD me 25 GB. RAM ishte e mjaftueshme, por procesori pothuajse po ngarkohej nĂ« 100% (dhe ndonjĂ«herĂ« edhe 102-103% đ Kjo çoi nĂ« faktin qĂ« transmetimi ngec shumĂ« herĂ« çdo disa sekonda. Nuk duket mirĂ«.
Mund t'kishte marrë një konfigurim më të shtrenjtë me dy bërthama, mirë që me teknologjitë cloud, ndërrimi i konfiguracionit të serverit bëhet me klikime të pakta. Por doja të isha brenda kapaciteteve të konfiguracionit minimal. Fillova të studioj dokumentacionin e ffmpeg dhe po, atje gjithashtu ka cilësime që lejojnë rregullimin e ngarkesës në sistem.
Cilësia e lartë e imazhit mund të arrihet në dy mënyra: ose me një ngarkesë të lartë në procesor, ose me një trafik të madh në dalje. Kështu, sa më shumë ngarkesë të mund të përballojë procesori, aq më pak do të nevojitet kapaciteti i kanalit. Ose mund të mos e ngarkosh shumë procesorin, por atëherë do të nevojitej një kanal i gjerë me kapacitet të madh për trafik. Nëse ka kufizime si në procesor ashtu edhe në madhësinë e kanalit të daljes/trafikut, do të duhet të ulet cilësia e imazhit për të siguruar një transmetim pa ndërprerje.
Serveri im ka akses nĂ« njĂ« kanal me gjerĂ«si 10 Mbit/s. Kjo Ă«shtĂ« njĂ« gjerĂ«si mjaft e madhe. Por ka njĂ« kufizim nĂ« trafik â 1 TB nĂ« muaj. Prandaj, qĂ« tĂ« pĂ«rputhem me kufizimet e trafikut, rrjedha ime e daljes nuk duhet tĂ« kalojĂ« ~300 Kb nĂ« sekondĂ«, dmth, bitrate i rrjedhĂ«s sĂ« daljes duhet tĂ« jetĂ« jo mĂ« shumĂ« se 2.5 Mbit/s. YouTube, pĂ«r rastin, rekomandon pikĂ«risht tĂ« bĂ«het transmetimi nĂ« njĂ« bitrate tĂ« tillĂ«.
Për rregullimin e ngarkesës në sistem, ffmpeg përdor qasje të ndryshme. Kjo është shkruar mirë. . Unë përfundimisht përdora dy atribute: -crf dhe -preset.
Constant Rate Factor (CRF) â Ă«shtĂ« koeficienti qĂ« lejon tĂ« rregullohet cilĂ«sia e imazhit. CRF mund tĂ« ketĂ« vlera nga 0 nĂ« 51, ku 0 Ă«shtĂ« cilĂ«sia e skedhĂ«s origjinale, 51 Ă«shtĂ« cilĂ«sia mĂ« e keqe e mundshme. Rekomandohet tĂ« pĂ«rdoren vlera nga 17 nĂ« 28, me variantin e parazgjedhur 23. Me njĂ« koeficient 17, videoja do tĂ« jetĂ« vizualisht identike me origjinalin, por teknikisht nuk do tĂ« ishte. Po ashtu, nĂ« dokumentacion Ă«shtĂ« e evidentuar se madhĂ«sia e videos pĂ«rfundimtare ndryshon nĂ« varĂ«si tĂ« CRF qĂ« Ă«shtĂ« caktuar nĂ« mĂ«nyrĂ« eksponenciale, dmth rritja e koeficientit me 6 pikĂ« do tĂ« dyfishojĂ« bitrate-in e videos nĂ« dalje.
Nëse me anë të CRF mund të përcaktohet "peshë" e imazhit në dalje, me anë të preseteve (-preset) mund të përcaktohet sa shumë do të ngarkohet procesori. Parametrat e këtij atributi janë si mëposhtë:
ultrafastsuperfastveryfastfasterfastmediumâ vlera e parazgjedhurslowslowerveryslow
Sa më "të shpejtë" të jetë parametri i caktuar, aq më e lartë do të jetë ngarkesa mbi procesorin.
Fillimisht zgjodha një preset që ishte në përgjithësi "i përballueshëm" për procesorin tim, pastaj përshtata më shumë ngarkesën me anë të CRF. Në rastin tim, arrita në preset fast, dhe për crf u ndala në vlerën 24.
PĂ«rfundimi
Në këtë pikë, komanda për të filluar transmetimin përfundimisht rezultoi si e tillë:
ffmpeg -re -i lecture1.mp4 -vf drawtext="fontfile=OpenSans.ttf:text='Lezione 1: Xhonglimi i imazheve tĂ« botĂ«s':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/%KLIĂIMI_I_TRANSMETIMIT%KĂ«tu kanĂ« mbetur vetĂ«m dy pika tĂ« paartikuluara:
1) -c:v libx264 â specifikimi i kodekut konkret pĂ«r punĂ«n me skedĂ«n origjinale.
2) -g 3 â pĂ«rcaktimi i qartĂ« i numrit tĂ« çelĂ«save. NĂ« kĂ«tĂ« rast, Ă«shtĂ« pĂ«rcaktuar se çdo i tretĂ« kadĂ«r duhet tĂ« jetĂ« çelĂ«s. Vlera standarde Ă«shtĂ« ose 5 ose 8, por YouTube ankesohet, kĂ«rkon tĂ« paktĂ«n 3.
Cilësia e transmetimit mund të shikohet .
Ngarkesa mbi server rezultoi si e tillë:
Nga tĂ« dhĂ«nat e monitorimit, duket se ngarkesa mbi procesor varion nga 70% nĂ« 95% dhe pĂ«r njĂ« javĂ« transmetimi nuk arriti asnjĂ«herĂ« nĂ« 100%. KĂ«shtu, me kĂ«to паŃĐ°ĐŒĐ”ŃŃĐ° , procesori Ă«shtĂ« mjaft i mjaftueshĂ«m.
Sa për ngarkesën mbi disk, mund të them që ai është pothuajse i pakrahasueshëm dhe për transmetim do të ishte e mjaftueshme dhe një HDD i zakonshëm.
Por, sasia e trafikut në dalje më shqetëson. Del se rrjedha ime e daljes varion nga 450 në 650 Kbyte në sekondë. Për një muaj, kjo do të përbënte rreth 1.8 terabyte. Ndoshta do të ketë nevojë të blej trafik ose ende të kaloj në një konfigurim me dy bërthama, pasi nuk do të doja ta ulesha cilësinë e imazhit.
***
Si përfundim, mund të them se konfigurimi i një transmetimi të tillë nga fillimi zgjat rreth 1-2 orë. Kryesisht, pjesa më e madhe e kohës do të merret nga ngarkimi i videos në server.
Si një mjet marketingu, një nisje e tillë transmisioni nuk e arriti qëllimin e vet. Ndoshta, nëse do të stimuloja shikimet që algoritmet e YouTube të kapnin këtë transmetim dhe të fillonin ta tregonin atë në rekomandime, mund të kishte diçka që do të rezultonte. Në rastin tim, për 16 ditë transmetim të pandërprerë, ajo u pa 58 herë.
Mirë, transmetimi u integrua harmonikisht në faqen kryesore të sitit tim. E gjitha rezultoi si një mundësi për të formuar një opinion të shpejtë mbi ligjëruesin dhe vetë ligjëratat.
Dhe njĂ« moment tjetĂ«r. ĂshtĂ« e rĂ«ndĂ«sishme qĂ« transmetimi tĂ« mos shkelĂ« tĂ« drejtat e autorit tĂ« askujt, pĂ«rndryshe do tĂ« bllokohet. UnĂ« jam i qetĂ« pĂ«r transmetimin tim, pasi pjesĂ«t muzikore i kam zgjedhur me qĂ«llim pĂ«r pĂ«rdorim tĂ« lirĂ«, dhe autori i pĂ«rmbajtjes Ă«shtĂ« ulur nĂ« kompjuterin pranĂ« dhe Ă«shtĂ« mjaft dakord qĂ« tĂ« pĂ«rdor pĂ«rmbajtjen e tij đ
Por nĂ«se nĂ« transmetimin tuaj luan ndonjĂ«herĂ« radio nĂ« sfond, ose nĂ«se gjatĂ« montimit keni pĂ«rdorur njĂ« kĂ«ngĂ« tĂ« preferuar, ose keni marrĂ« njĂ« video nga njĂ« klip muzikor popullor, serial ose film â atĂ«herĂ« transmetimi juaj Ă«shtĂ« nĂ« rrezik. Po ashtu, Ă«shtĂ« e rĂ«ndĂ«sishme qĂ« transmetimi tĂ« ketĂ« tĂ« paktĂ«n njĂ« ngarkesĂ« minimale kuptimore, pĂ«rndryshe mund tĂ« bllokohet si spam.
***
KĂ«tu pĂ«rfundoj. Shpresoj qĂ« ky manual t'u vijĂ« nĂ« ndihmĂ« dikujt. Dhe nĂ«se keni diçka pĂ«r tĂ« shtuar â shkruani, do tĂ« jem i lumtur tĂ« lexoj shtesa dhe sqarime pĂ«r artikullin.
Burimi: habr.com
