DJI + Huawei P20 Pro + Sony vegas – fix

Egy ideje felfigyeltem rá, hogy a DJI go app – ami egy elég jól sikerült darab, pacsi a fejlesztőknek, elég jól lehet használni, ha van egy osmo mobile-od – hajlamos elrontani a felvételt.

Ez abban nyilvánul meg, hogy visszanézve google photos-ra felszinkronizálva minden rendben, VLC, wmplayer is rendben játsza ellenben a Sony Vegas 15 importáláskor a fájlt elrontja/rosszul olvassa be/whatever. Ekkor a kép vagy akadozik vagy hiányzik eleje vagy vége, vagy – és ami a leggyakoribb – a kép a hangtól el-el csúszik.

Ami valljuk be rendkívül bosszantó.

Viszont ahelyett, hogy tovább hőbörögnénk és követelnénk vissza a pénzünket járjunk utána, hogy mit lehet e jelenség ellen tenni.

Lényeg, hogy kell egy ffmpeg és mondjuk egy linuxos bash és az alábbi script-et a fájlok helyén lefuttatjuk:

mkdir fixed;
for i in *.mp4 ; do
    ffmpeg -i $i -preset slow -strict experimental -c:a aac -b:a 192k -codec:v libx264 -pix_fmt yuv420p -b:v 11000k -minrate 11000k -maxrate 14000k -bufsize 14000k -vf scale=-1:1080 fixed/$i.mp4
done

Ez 1080p30 esetén – 4K vagy 1080p60 esetén valszeg magasabb bitrátát kell beállítanod – a fájl tulajdonságai között megtalálod a megfelelő értékeket!

Ekkor készül egy fixed nevezetű mappa és feldolgozás után ott fognak sorakozni a tökéletesen használható nyersanyagok 🙂

Btw ha nincs bash-ed windowson varázsolj egyet rá, vagy írd meg ennek a Windowsos változatát (ami végigiterál a mappa mp4-es elemein) és küldd el nekem és update-elem a postot 🙂

HDD to SSD linuxon

A hétvégén rákényszerültem, hogy a nagyobb méretű, de már régi HDD-ről a linuxos gépemet átköltöztessem egy kisebb méretű SSD-re. A clonezilla nem segített így kézzel kellett átmigrálnom a teljes fájlrendszert.

Halál egyszerű, csak oda kell minden lépésre figyelni.

Teendők:

Rakd be a hdd-t és az ssd-t is egy számítógépbe, lehetőleg sata csatlakozóra kösd, usb-n sokáig fog másolni.

Bootolj be egy live ubuntut a számítógépen.

Ezután nyiss egy konzolt, formázd le a cél ssd-t,

fdisk /dev/sdb #sdb az SSD!
> o
> n
> enter, enter, enter...
> p (ha egy partíció látszik szuper)
> w

mkfs.ext4 /dev/sdb1 #feltéve, hogy ext4-et szeretnél

Készítsük elő a műveleteket

mkdir /mnt/{ssd,hdd}
mount /dev/sda1 /mnt/hdd #sda a HDD!

majd rsync-el másold át, illetve hozd létre a szükséges mappákat

rsync --exclude="mnt" --exclude="lost+found" --exclude="sys" --exclude="proc" --exclude="cdrom" --exclude="media" --exclude="swapfile" -aP /mnt/hdd/ /mnt/ssd/
mkdir /mnt/ssd/{mnt,proc,sys}

Majd telepíts grub-ot

mount -o bind /dev /mnt/ssd/dev
mount -o bind /sys /mnt/ssd/sys
mount -t proc /proc /mnt/ssd/proc
cp /proc/mounts /mnt/ssd/etc/mtab
chroot /mnt/ssd /bin/bash
grub-install /dev/sdb
grub-install --recheck /dev/sdb
update-grub

Majd írd át a bootolandó meghajtó uuid-ját az fstab-ban

blkid /dev/sdb1

Az itt található uuid-t vidd fel az fstab-ba

nano /mnt/ssd/etc/fstab

Ha nem kaptál sehol hibát

init 0

A gép leáll, vedd ki a hdd-t, kapcsold vissza, biosban csekkold le, hogy az ssd-ről fog-e bootolni.

Enjoy!

SSD cache linux rendszeren

Képzeld el – van egy méretes HDD-d, melyen adatbázist tárolsz, torrentezel, vagy oprendszert futtatsz. Végülis mindegy, a lényeg az, hogy néha marha lassú a rendszer, IOwait a plafonban.

Tudod jól, hogy kéne ssd-re váltani, de nincs az a pénz, hogy marha nagy HDD-k helyett SSD-kre cseréljél.

Szóval a probléma adott, HDD kéne megközelítőleg SSD tempóban – vajon mi lehet a megoldás?

Mintapélda, teljesítményben egy idális világot képez :)
Mintapélda, teljesítményben egy idális világot képez 🙂

Egy korábbi részben ecseteltem egy lehetséges megoldást erre vonatkozóan Windows rendszeren, de most nálam linux szerveren adódott a probléma és a dolog megoldásért kiáltott és végül találtam valamit.

bcache

Az elv itt is azon alapul, hogy a merevlemez írási és olvasási gyorsítótárát kiegészíti a rendszerhez illesztett plusz SSD.

Nekem egy 3T-os disk-em van és úgy alakult, hogy egy 60G SSD felhasználható a célra. Mindkét meghajtót a leggyorsabb sata portokra csatlakoztattam és az alábbiakat műveltem.

Törölnöm kellett a teljes ssd-t és a gyorsítani kívánt partíciót (sde = SSD, sdc = HDD):

wipefs -a /dev/sde

wipefs -a /dev/sdc1

Létrehoztam egy bcache partíciót:

make-bcache -C /dev/sde -B /dev/sdc1 --block 4k --discard --writeback

Írási gyorsítótártól ha tartasz ne használd a writeback paramétert, ha pedig az ssd-d nem támogatja a TRIM módot vedd ki a discard paramétert.

Ezután már csak létrehoztam az új tömbön egy fájlrendszert:

mkfs.ext4 /dev/bcache0

Majd /etc/fstab-ba felvettem a /dev/bcache0 virtuális meghajtót és voila.

Statisztikákért pedig ezekhez nyúlok:

cat /sys/block/bcache0/bcache/dirty_data

tail /sys/block/bcache0/bcache/stats_total/*

Vagy akár folyamatosan:

watch -n 5 tail /sys/block/bcache0/bcache/stats_total/*

 

Jó kísérletezést! 🙂

Ezért érdemes sshfs-t -C kapcsolóval használni

1445465012_Database-CloudVan ugye az a protokoll – remélem ismerős -, hogy “sftp”. Tegyük fel, hogy van egy linuxos adattároló szervered és egy linuxos géped. Közvetlen fel tudod csatolni sshfs-el a távoli gép valamely mappáját, ha van rajta unix felhasználói fiókod és hozzáférésed.
Namost az sshfs-nek van egy -C, mint compression kapcsolója, ami a két gép közötti átviteli sebesség növelésében játszhat szerepet, mivel a két gép közötti adatfolyamot képes tömöríteni. Ehhez persze némi processzor kell mindkét oldalon, de egy HP microservernek sem konnyan meg a dolog (nálam az érintett adattároló gép).
Tehát ha linuxot használsz az alábbi paranccsal felcsatolhatod a távoli gép könyvtárát a helyi gépedre:

 sshfs -o allow_other,default_permissions -o IdentityFile=/helyi_szerver/publikus_kulcs winben@szerverem.hu:/tavoli_szerver/csatolasi_pont /helyi_szerver/csatolasi_pont -C -o reconnect;

 

Mi az eset akkor, ha Windows használok?

Igen, sokan vagyunk így, kipróbálhatunk egy csomó sshfs-t megvalósító alkalmazást. Ilyen a fizetős expandrive, vagy az ingyenes win-sshfs.

Részemről egyik sem nyerte el a tetszésemet többek között azért, mert instabilak voltak, suttyomban a program files-ba cache-eltek és nem is a valós állapotot mutatták sokszor…és legfőbb problémám volt, hogy láthatólag egyik sem szolgált a tömörítős megoldással, ami miatt (vagy még mellett) dög lassú volt az adatátvitel.

Nos, ha van egy kis memóriád fölösen a gépben akkor van egy szuper jó hírem – a probléma baromi jól orvosolható.

  1. Készíts egy linuxos virtuális gépet localhoston, ami NATolva csatlakozik a hálózatra, tehát a te géped oszt neki IP címet.
  2. Ha megvan a telepítés csatold fel a távoli mappát a virtuális géped egy helyi mappájába.
  3. Ezután telepíts sambát a virtuális gépre és oszd meg a felcsatolt mappa tartalmát.
  4. Tallózd be Windows Intézőben a sambán megosztott tartalmat és örülj. Az adatátvitel gördülékeny lesz és megfelelő tartalom esetében gyors.

Ha olyan kontentről van szó, ami jól tömöríthető akkor sokszoros sebességet érhetsz el “logikailag”, mint egyébként “fizikailag”, tehát a fizikai vonalon.

 

Bizonyításként hadd mutassam a feladatkezelőmet:

aa99259e10b2a668d37f45b32ea9d906

Itt éppen egy lemezképfájlt másoltam. A képen az látható, hogy a Total Commander 176 Mb/s-al tölti felfelé az adatot, a VMware NAT Service pedig a virtuális gépet jelképezi és látszik, hogy 47,5 Mb/s a “fizikai” adatfolyam. Tudni kell azt is, hogy a mérés idején a laptopom céges wifi routerre volt csatlakozva vezetéknélküli hálózaton és nem egy irodában lévő másik gépre, hanem az otthoni szerveremre tolta át az adatot – ennek köszönhető, hogy csak ~50 Mbit környékén történt az adatátvitel. A másolás idején 50-70% között volt a 1.5 GHz-es HP microserverem cpu terheltsége (mivel kétmagos így 200%-ból), és 0,93-as volt a 15 perces átlag load.

 

Akik kicsi internetsebességgel rendelkeznek (100 Mbit alatt) és távoli szerverre dolgoznak bőven megfelel és tűrhetően is működik az ExpanDrive. Ha viszont helyi 100 megás hálón (vagy azzal egyenértékű neten) szeretnénk Windows-on sshfs kapcsolódást érdemesebb efféle perverzióhoz folyamodnunk.

Reklámszűrés globálisan

Noha az AdBlock plus a tökéletes megoldás, mégsem használható mindenhol (lassú gép, tablet, stb) – így én most egy tök egyszerű, mindenhol használható és jól működő megoldást hoztam nektek.

block-ads.png.pagespeed.ce.ilt7LDHC30

A látogatott weboldalak java részén a hirdetések az alábbi domain-ekről töltődik be:

ad.adverticum.net
doubleclick.net
etargetnet.com
google-analytics.com
googleadservices.com
googlesyndication.com
googletagservices.com
hit.gemius.pl

 

Tehát a siker eléréséhez nem kell más, csak ezeket az oldalakat letiltani.

Ezeket lehet a géped hosts file-jában és a router Access Control Rule Management-jében is beállítani. És szerintem érdemesebb a routerben, mert az érvényes lesz a router mögötti összes gépre is… 🙂