Kategória: Hálózat

1 kép + 1 audio fájl = 1 videó gyorsan Youtube-ra

Mivel rádióműsorokat, podcast-et készítek gyakran szükségem van arra, hogy egyetlen borítóképpel egy hanganyagot feltöltsek Youtube-ra. Ez persze úgy nem megoldható, hogy feltöltöm Youtube-ra az mp3-at és a képet, az pedig legyártja nekem a videót – nekem kell egy videószerkesztő programmal összekattintgatni, majd lerenderelni a laptoppal az anyagot, hogy aztán tölthessem fel még a videómegosztóra.

Igazából az igényeimet az ffmpeg is ki tudja szolgálni konzolból az alábbiak szerint úgy, hogy készítesz egy makevideo.sh fájlt:

#!/bin/bash
ffmpeg -loop 1 -i $1 -i $2 -c:v libx264 -tune stillimage -c:a aac -b:a 192k -pix_fmt yuv420p -shortest $3.mp4

aztán mikor meghívod a fájlt:

./makevideo.sh image.jpg audio.mp3 output

Az eredmény az output paraméterben megadott mp4 videó lesz.

Jó munkát, jó szórakozást!

Rpi4 vs Do szerver

Elkezdett bennem érlelődni a gondolat, hogy mivel a weboldalaim jelenleg kisebb látogatottságúak simán áttehetném az épp egyik használaton kívüli rpi4-esemre.

Igazából néhány wp oldalam fut, amin tulajdonképpen cache sincs, tehát a php-nak kell eleget dolgoznia. Fogtam tehát billentyűzetet és első körben leteszteltem, hogy processzorban mekkora a különbség egy 5 dolcsis alap 1 magos Digitalocean szerver és egy Raspberry pi 4 (1G ram+ssd) között az alábbi módon:

sysbench --num-threads=4 --test=cpu --cpu-max-prime=20000 run

A Digitalocean szerver így alakított:

Threads fairness:
     events (avg/stddev):           680.7500/0.83
     execution time (avg/stddev):   9.9814/0.01

A kis bankkártya méretű számítógép:

Threads fairness:
    events (avg/stddev):           2500.0000/41.70
    execution time (avg/stddev):   65.5436/0.01

Nagyjából 6.5x az eltérés a Digitalocean javára.

Jelenleg a Digitalocean szerverem 5.8%-os átlag cpu terheltségével számolva a raspi-n ez az érték kb 40%-os átlagos cpu terhelésre emelkedne. A 40% körülbelül már az a határ amikor még éppen jók vagyunk, de azért belátható, hogy kevés tartalék marad. Viszont a WordPress oldalakat van még bőven hova optimalizálni, így a várható forgalomnövekedések során még mindig nem szalad ki a világba az rpi terheltsége.

Jelenleg a Digitalocean mellett szól a sebesség, az (elvileg) jó skálázhatóság és megbízható, stabil működés. Hátránya a magasabb üzemeltetési költség és drága/kis méretű tárhely.

A raspi mellett szól, hogy rádughatok egy 250G ssd-t usb3.0-n úgy, hogy erről bootol már eleve az alaprendszer is. Onnantól kezdve, hogy van stabil netem, helyem és megvalósításom az üzemeltetésre annyira keveset kér a raspi enni, hogy egy éven belül behozza a raspi a Do-al szemben az árát.

Elgondolkodtató.

Digionline servlet Kodi-hoz

Az ittott.tv-s servletem után itt az újabb készítmény, mellyel egyszerűvé válik a tévézés Kodin.

Tehát ez egy servlet, illetve lejátszótól független kiegészítő ami a hivatalos http://onlineplayer.digi.hu weboldalon elérhető tv csatornák megnyitását teszi lehetővé külső alkalmazások számára.

Szükséges hozzá már meglévő digionline hozzáférés, melyet abban az esetben regisztrálhatsz a digi ügyfélkapuján keresztül, ha rendelkezel kábeltévé és internet előfizetéssel is. E program működéséhez nem szükséges digi hálózat, de legjobb tudomásom szerint csak magyar ip címről működik.

 

Egy előfizetéshez jelenleg max három digionline account regisztrálható, a servlet egyszerre csak egy accountot kezel, így egyidőben egy servlet egyetlen lejátszót képes kiszolgálni.

E program indításakor legenerál egy m3u és egy xml fájlt – az előbbiben a teljes csatornalista az utóbbiban 5 napra elölre elektronikus programujság (EPG) található, melyet képes lejátszani a VLC, de teljes műsorújsággal együtt a KODI is.

Kodi-n az IPTV Simple Client-et kell beállítani, majd bekapcsolni – miután a servlet elindult a háttérben megnyithatóvá válnak a digionline rendszerében elérhető csatornák HD minőségben.

Részletek, leírás, telepítés:

https://github.com/szabbenjamin/digionline

 

SSHFS party gigabites vonalon

Damaged-Wire-FireA történet úgy folytatódik, hogy az itthoni HP microserveremből gigabites routert varázsoltam.

Szóval a gép most:

  • Storage szerver
  • Plex médiaszerver
  • Gigabites router (erről egy másik posztban írok)

 

Vettem a kütyübazár című izén…weboldalon…(ebay cache?)…webshopon egy USB 3.0 csatlakozású Gigabit ethernet adaptert ~5000 ezer pénzért. Mivel laptop az laptop és direkt is és praktikussági okokból sem tárolok rajta sok/minden adatot így érthető, hogy a storage szerverrel szoros kapcsolatba szerettem volna maradni. Azért sshfs-re esett a választásom, mert hordozható, itthon és távolról is egy háttérben futó virtuális gép segítségével el tudom hitetni a Windows-zal, hogy samba megosztáson van itt mellette egy nagy tárolókapacitású gép, még akkor is, ha csak mobilneten vagyok a világ végéről.

Tehát a usb-ethernet kártya boldogan – bár szkeptikusan – kicsomagol, bedug, a cucc működik. Nem hoz 1000 mbitet, jó az 700-800 Mbitnek is, de egyből jobb, mint 90 megabittel tötymörögni.

A pofáraesés az volt, hogy az átviteli sebesség továbbra is 9 mb/s volt átlagban. Próbáltam filezillával, belső ip címet használva, egyből hasított. Ekkor két dologra gyanakodtam: mindig a külső webcímen csatolom fel a storage szervert, így itthon is a WAN interfészen keresztül botorkáltak az adatok, az sshfs kliensem nem tudta, hogy helyben van a szerverem és maradjanak a csomagok LAN-on. Ennek érdekében beállítottam a routeremben, hogy a DNS szervere az én külső webcímemet a LAN-on csücsülő ip címre oldja fel.

Újabb teszt következett – minimális eredmény, még mindig messze az igazitól.

Ezután ránéztem a szerver és a laptop processzorterheltségeire, kiderült, hogy ami korábban preferált volt az most hátránnyá vált – a -C kapcsolóval tömörítettem az adatfolyamot és ezzel egyidőben ezzel a sávszélességgel meg is fogtam a storage szerver egyik processzormagját. Így a -C kapcsolót kivettem. A javulás jelentős volt.

De még mindig messze álltam az igazságtól. Ekkor jött gugli és egy kis unszonlás hatására választ adott. A válasz ezen az oldalon olvasható – elfelejtkeztem arról, hogy az sshfs lényege és nagyszerűsége néha pont a hátránya – az adatfolyam titkosítása (amire szükségem is van) gyakorlatilag limitálja a sávszélességet.

Megoldást a -o Ciphers=arcfour kapcsoló jelentette.

Tehát most egy sshfs kapcsolódásom:
sshfs -o allow_other,default_permissions -o IdentityFile=/home/winben/identityfájlom winben@szerverem.hu:/home/winben /home/winben/home -o reconnect -o Ciphers=arcfour;

 

Kellemes száguldozást mindenkinek!

Biztonsági öveket becsatolni 😀