Videó tömörítése internetre

Van egy videód amit meg szeretnél osztani a weboldaladon közvetlenül és ehhez nem akarod használni a youtube-ot? Ez a videó viszont sok helyet foglal?

Valószínűleg azzal lesz a probléma, hogy túlságosan jó képminőséggel dolgozol – főleg ha mondjuk azt standard beállítások mellett egy Vegas Pro-val exportáltad ki.

Megoldás egy kis bash script, mely lebutítja kb a youtube szinvonalára a videó kép és hangminőségét és kicseréli az előző fájllal. Íme a bash script:

nano converter.sh
#!/bin/bash
ffmpeg -i $1 -c:v libx264 -b:v 1.7M -c:a aac -b:a 128k $1.new.mp4
rm $1
mv $1.new.mp4 $1

Így használd:

./converter.sh fájlnév.mp4

Enjoy!

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ó.

Nextcloud /data mappa adatok importálása

Tegyük fel, hogy szerver költöztetés volt és álmodban sem gondoltad volna, hogy ahhoz, hogy a nextcloud fájljaid látszódjanak az új gépen nem elég csak a data mappát másolni.

Nos, van egy jó hírem: ez nem így van.

Az adatok visszamásolása után ezt kell csak lefuttatnod:

sudo -u www-data php /var/www/nextcloud/occ files:scan --all

Nyilván a /var/www/nextcloud helyére azt a path-t írod be ahol a te nextcloud appod telepítésre került.

Ekkor “újraszámolja” az adataidat és adatbázisba felvezeti őket. Ezt persze nem kellett volna futtatnod/nom ha az adatbázist is viszem magammal… 😑

Rejtélyes tárhelyproblémák – avagy a disk és a kernel viszonya

Az utóbbi néhány napban a szerverem lévő root partíción – ami egy 60G ssd – hirtelen a foglalt terület felkúszott átlag 55%-ról fokozatosan 100%-ig, 0b szabad, a rendszer megáll és nem értem mi történt.

Az első kör

du -sh * / --exclude <azon könyvtárak, melyekbe a diskek vannak felcsatolva>

Nem találtam semmi érdekeset. De szabad hely fokozatosan elfogyott és megszűnt.

Akkor újraindítjuk a rendszert hátha egyszerűen nincs szinkronban a disk foglalt területe a rendszer által “tudottakkal”. Tehát feltételeztem azt, hogy a rendszer valamit csinált (lehet frissítés vagy programhiba), televerte a disk-et, majd leállt, a hely felszabadult (tehát nem megszámlálható, nem látható), csak erről a kernel maga már/még nem tud.

Szóval újraindítottam. Hely ugyanúgy nincs, a szolgáltatások bő fele már el sem indult.

Töröltem a logokat, még mindig ugyanaz a helyzet. Letiltottam néhány service-t amire gyanakodtam, hogy problémázhatnak, majd újraindítottam ismét a gépet. Lett hely ismét, hurrá! Nem világos miért, de hurrá. Amúgy itt követtem el már a második bakimat.

Eltelt egy nap, majd figyelem a muninon, hogy az elmúlt napokban folyamatosan egy fűrészfog mintát sikerült rajzolni a >szépen lassan megtelik a tárhely, majd törlök valamit és újra lesz hely< alapon. És meglátom, hogy ismét ugyanabban a mértékben foly a hely.

Hogy kiderítsem mi okozza a balhét kicsit utánnakutattam és láttam példát, hogy du-t hogyan lehet hatékonyabban használni – konkrétan sorbarendezés, total számítás.

Ebből megszületett ez, amit a / helyen futtatok:

 du -sch * --exclude home --exclude disks | sort -h

És itt szembesültem vele, hogy az apache2 egy nap alatt kb 11G-nyi error.log-ot termel. Botok rátévedtek a szerveremre ahol folyamatosan olyan hívást csinálnak ami php hibát okoz ezért a hibajelentés oda bekerül.

Mit rontottam el?

Először is nem sorrendeztem így elsiklott a szemem felett a du által számolt terület kb/GB eloszlása és nem vettem elsőre észre, hogy az apache2 okozza a balhét.

Második. Ha töröltem a /var/log-ot korábban miért nem szabadult fel a hely? Az alkalmazás az access.log-ot és az error.log-ot nyitva tartja. Valami rejtélyes oknál fogva engedi az OS, hogy töröljem az appendelt fájl-t, de ennek ellenére továbbra is írja azt a kernel, tehát nincs felszabadult terület. Szerinte. Mert hogy még a fájl valószínűleg nyitva marad.

Egy egyszerű

systemctl restart apache2

után újra megjelent 55% foglalt terület és mindenki boldog.

Most már csak a php hibát kell kiküszöbölni, hogy ne legyen tele az apache error log ezekkel. 🙂

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